<?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/en/tags/version-control/</link><description>Recent content in Version-Control on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sat, 13 Jun 2026 23:11:50 +0900</lastBuildDate><atom:link href="https://takao.blog/en/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/en/web/git-lfs/</link><pubDate>Tue, 26 Nov 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-lfs/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" 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 server.&lt;/p&gt;
&lt;p&gt;A pointer file is a small text file that maps to content on the LFS server:&lt;/p&gt;</description></item><item><title>Git Squash Merge: Clean History Strategies for Teams</title><link>https://takao.blog/en/web/git-squash-merge/</link><pubDate>Tue, 21 May 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-squash-merge/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" 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 guide to squash merge strategies for teams.&lt;/p&gt;
&lt;h2 id="squash-merge-mechanics"&gt;Squash Merge Mechanics
&lt;/h2&gt;&lt;p&gt;A squash merge combines all commits from a feature branch into a single commit on the target branch. Consider a feature branch with commits C, D, and E that need to be merged into main:&lt;/p&gt;</description></item><item><title>Git Submodules: Managing Nested Repositories Effectively</title><link>https://takao.blog/en/web/git-submodules/</link><pubDate>Mon, 22 Jan 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-submodules/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" 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 version 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>