<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Version-Control on Commentary of Takao</title><link>https://takao.blog/ko/tags/version-control/</link><description>Recent content in Version-Control on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>ko</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sun, 12 Jul 2026 04:12:51 +0900</lastBuildDate><atom:link href="https://takao.blog/ko/tags/version-control/index.xml" rel="self" type="application/rss+xml"/><item><title>Git LFS: Managing Large Files in Your Repository</title><link>https://takao.blog/ko/web/git-lfs/</link><pubDate>Tue, 26 Nov 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/ko/web/git-lfs/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-lfs-ko.png" alt="Featured image of post Git LFS: Managing Large Files in Your Repository" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Git was designed for text files, not large binaries. When large files enter a Git repository, clone times increase, repository size balloons, and operations like &lt;code&gt;git log&lt;/code&gt; slow down. Git LFS (Large File Storage) solves this by replacing large files with text pointer files in the repository while storing the actual content on a remote 서버.&lt;/p&gt;
&lt;p&gt;A pointer file is a small text file that maps to content on the LFS 서버:&lt;/p&gt;</description></item><item><title>Git Squash Merge: Clean History Strategies for Teams</title><link>https://takao.blog/ko/web/git-squash-merge/</link><pubDate>Tue, 21 May 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/ko/web/git-squash-merge/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-squash-merge-ko.png" alt="Featured image of post Git Squash Merge: Clean History Strategies for Teams" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Git history is a communication tool for your team and your future self. A clean, readable history makes debugging, code review, and release management significantly easier. Squash merge is one of the primary strategies for maintaining a clean history, but knowing when and how to use it—and when to choose alternatives—requires understanding the trade-offs involved. This article provides a comprehensive 가이드 to squash merge strategies for teams.&lt;/p&gt;</description></item><item><title>Git Submodules: Managing Nested Repositories Effectively</title><link>https://takao.blog/ko/web/git-submodules/</link><pubDate>Mon, 22 Jan 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/ko/web/git-submodules/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-submodules-ko.png" alt="Featured image of post Git Submodules: Managing Nested Repositories Effectively" /&gt;&lt;p&gt;Git submodules allow you to nest one Git repository inside another while maintaining independent 버전 control for each. They are useful for managing shared libraries, third-party dependencies, or configuration collections where you need precise commit-level control. However, submodules come with complexity that requires understanding their underlying mechanics.&lt;/p&gt;
&lt;h2 id="understanding-git-submodules"&gt;Understanding Git Submodules
&lt;/h2&gt;&lt;p&gt;A submodule is a reference from your parent repository to a specific commit in another repository. Git stores this as a tree object in the parent&amp;rsquo;s index, and the mapping of submodule paths to repository URLs lives in a &lt;code&gt;.gitmodules&lt;/code&gt; file at the root of the parent repository.&lt;/p&gt;</description></item></channel></rss>