Using branches


This tutorial is a comprehensive introduction to Git branches. First, we'll take a look at creating branches, which is like requesting a new project history. Then, we'll see how git checkout can be used to select a branch. Finally, we'll learn how git merge can integrate the history of independent branches.

読み進むに従い、Git ブランチは SVN ブランチとは異なるものであることが理解できると思います。SVN ブランチが作業成果を時折大規模にまとめるためのものであるのに対し、Git ブランチは日常的ワークフローにおける不可欠な要素です。

git ブランチ

A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process discussed in Git Basics, the first module of this series. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.

The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.


git ブランチ


git branch <branch>

Create a new branch called <branch>. This does not check out the new branch.

git branch -d <branch>

指定したブランチを削除します。ブランチにマージされていない変更が残っている場合は Git が削除を拒否するため、このコマンドは「安全な」操作です。

git branch -D <branch>


git branch -m <branch>

Rename the current branch to <branch>.


Git ではブランチは日常の開発プロセスの要素です。新たなフィーチャー開発やバグフィックスを行う場合、その規模の大小を問わず、変更をカプセル化するためにブランチを作成します。これにより、不安定なコードがメインコードベースにコミットされることを防止し、また master ブランチにマージする前にフィーチャーの履歴を整理することも可能になります。

Git チュートリアル: git branch

For example, the diagram above visualizes a repository with two isolated lines of development, one for a little feature, and one for a longer-running feature. By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the main master branch free from questionable code.


The implementation behind Git branches is much more lightweight than SVN’s model. Instead of copying files from directory to directory, Git stores a branch as a reference to a commit. In this sense, a branch represents the tip of a series of commits—it's not a container for commits. The history for a branch is extrapolated through the commit relationships.

このことは Gitのマージモデルに極めて大きな影響を与えます。SVN におけるマージはファイルベースで行われるのに対し、Git ではコミットを抽象化したレベルで作業を行います。実際には、プロジェクト履歴のマージとは、独立なコミット履歴の結合であると考えることができます。


It's important to understand that branches are just pointers to commits. When you create a branch, all Git needs to do is create a new pointer—it doesn’t change the repository in any other way. So, if you start with a repository that looks like this:

Git チュートリアル: ブランチのないリポジトリ


git branch crazy-experiment


Git チュートリアル: ブランチの作成

Note that this only creates the new branch. To start adding commits to it, you need to select it with git checkout, and then use the standard git add and git commit commands. Please see the git checkout section of this module for more information.


ブランチでの作業が終了し master ブランチへのマージが完了すると、ブランチを削除しても履歴を失うことはありません:

git branch -d crazy-experiment


error: The branch 'crazy-experiment' is not fully merged. If you are sure you want to delete it, run 'git branch -D crazy-experiment'.

This protects you from losing your reference to those commits, which means you would effectively lose access to that entire line of development. If you really want to delete the branch (e.g., it’s a failed experiment), you can use the capital -D flag:

git branch -D crazy-experiment


git checkout

The git checkout command lets you navigate between the branches created by git branch. Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. Think of it as a way to select which line of development you’re working on.

In the previous module, we saw how git checkout can be used to view old commits. Checking out branches is similar in that the working directory is updated to match the selected branch/revision; however, new changes are saved in the project history—that is, it’s not a read-only operation.


git checkout <existing-branch>

Check out the specified branch, which should have already been created with git branch. This makes <existing-branch> the current branch, and updates the working directory to match.

git checkout -b <new-branch>

Create and check out <new-branch>. The -b option is a convenience flag that tells Git to run git branch <new-branch> before running git checkout <new-branch>. git checkout -b <new-branch> <existing-branch>

Same as the above invocation, but base the new branch off of <existing-branch> instead of the current branch.


git checkout works hand-in-hand with git branch. When you want to start a new feature, you create a branch with git branch, then check it out with git checkout. You can work on multiple features in a single repository by switching between them with git checkout.

Git チュートリアル: git checkout を使用して 1 つのリポジトリで複数のフィーチャーを切り替える

個々のフィーチャーに対してそれぞれ専用のブランチを設けることにより、SVN に基づく従来のワークフローとは大きく異なる手法が実現できます。これによって既存の機能を損なう懸念を生ずることなく新しい実験的開発を行うことが容易に可能となり、また関連のない複数のフィーチャー開発を同時に行うことも可能となりました。加えてブランチの導入によりいくつかのコラボレーション型ワークフローも容易に採用できるようになりました。

Detached HEADs

Now that we’ve seen the three main uses of git checkout we can talk about that “detached HEAD” we encountered in the previous module.

Remember that the HEAD is Git’s way of referring to the current snapshot. Internally, the git checkout command simply updates the HEAD to point to either the specified branch or commit. When it points to a branch, Git doesn't complain, but when you check out a commit, it switches into a “detached HEAD” state.

Git チュートリアル: ”Attached Head” と ”Detached Head”

This is a warning telling you that everything you’re doing is “detached” from the rest of your project’s development. If you were to start developing a feature while in a detached HEAD state, there would be no branch allowing you to get back to it. When you inevitably check out another branch (e.g., to merge your feature in), there would be no way to reference your feature:

Git チュートリアル: ”Detached Head” 状態

The point is, your development should always take place on a branch—never on a detached HEAD. This makes sure you always have a reference to your new commits. However, if you’re just looking at an old commit, it doesn’t really matter if you’re in a detached HEAD state or not.

次の例は Git におけるブランチの基本的な使用法を示したものです。新しいフィーチャー開発作業を開始する場合に、専用のブランチを作成しそれに切り替えます:

git branch new-feature git checkout new-feature


# Edit some files git add <file> git commit -m "Started work on a new feature" # Repeat

All of these are recorded in new-feature, which is completely isolated from master. You can add as many commits here as necessary without worrying about what’s going on in the rest of your branches. When it’s time to get back to “official” code base, simply check out the master branch:

git checkout master


Ready to learn Git?

Try this interactive tutorial.