ブランチを使用する

ブランチを使用する

このチュートリアルは、Git ブランチに関する包括的な概要です。最初にブランチの作成について概観します。これは新しいプロジェクト履歴をリクエストすることに似ています。次にブランチを選択する際の git checkout コマンドの使い方を説明します。最後に、独立したブランチの履歴を統合するための git merge コマンドの使い方を学びます。

読み進むに従い、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 Head とは

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

これを行うことにより、前の章で説明したような新しいスナップショットのコミットが可能となります:

# 一部のファイルの編集
git add <file>
git commit -m "Started work on a new feature"
# 繰り返し

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 try branching?

この対話式チュートリアルを利用しましょう。

今すぐ始める