-
1. 使い始める
- 1.1 バージョン管理に関して
- 1.2 Git略史
- 1.3 Gitの基本
- 1.4 コマンドライン
- 1.5 Gitのインストール
- 1.6 最初のGitの構成
- 1.7 ヘルプを見る
- 1.8 まとめ
-
2. Git の基本
- 2.1 Git リポジトリの取得
- 2.2 変更内容のリポジトリへの記録
- 2.3 コミット履歴の閲覧
- 2.4 作業のやり直し
- 2.5 リモートでの作業
- 2.6 タグ
- 2.7 Git エイリアス
- 2.8 まとめ
-
3. Git のブランチ機能
- 3.1 ブランチとは
- 3.2 ブランチとマージの基本
- 3.3 ブランチの管理
- 3.4 ブランチでの作業の流れ
- 3.5 リモートブランチ
- 3.6 リベース
- 3.7 まとめ
-
4. Gitサーバー
- 4.1 プロトコル
- 4.2 サーバー用の Git の取得
- 4.3 SSH 公開鍵の作成
- 4.4 サーバーのセットアップ
- 4.5 Git デーモン
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 サードパーティによる Git ホスティング
- 4.10 まとめ
-
5. Git での分散作業
- 5.1 分散作業の流れ
- 5.2 プロジェクトへの貢献
- 5.3 プロジェクトの運営
- 5.4 まとめ
-
6. GitHub
- 6.1 アカウントの準備と設定
- 6.2 プロジェクトへの貢献
- 6.3 プロジェクトのメンテナンス
- 6.4 組織の管理
- 6.5 スクリプトによる GitHub の操作
- 6.6 まとめ
-
7. Git のさまざまなツール
- 7.1 リビジョンの選択
- 7.2 対話的なステージング
- 7.3 作業の隠しかたと消しかた
- 7.4 作業内容への署名
- 7.5 検索
- 7.6 歴史の書き換え
- 7.7 リセットコマンド詳説
- 7.8 高度なマージ手法
- 7.9 Rerere
- 7.10 Git によるデバッグ
- 7.11 サブモジュール
- 7.12 バンドルファイルの作成
- 7.13 Git オブジェクトの置き換え
- 7.14 認証情報の保存
- 7.15 まとめ
-
8. Git のカスタマイズ
- 8.1 Git の設定
- 8.2 Git の属性
- 8.3 Git フック
- 8.4 Git ポリシーの実施例
- 8.5 まとめ
-
9. Gitとその他のシステムの連携
- 9.1 Git をクライアントとして使用する
- 9.2 Git へ移行する
- 9.3 まとめ
-
10. Gitの内側
- 10.1 配管(Plumbing)と磁器(Porcelain)
- 10.2 Gitオブジェクト
- 10.3 Gitの参照
- 10.4 Packfile
- 10.5 Refspec
- 10.6 転送プロトコル
- 10.7 メンテナンスとデータリカバリ
- 10.8 環境変数
- 10.9 まとめ
-
A1. 付録 A: その他の環境でのGit
- A1.1 グラフィカルインタフェース
- A1.2 Visual StudioでGitを使う
- A1.3 EclipseでGitを使う
- A1.4 BashでGitを使う
- A1.5 ZshでGitを使う
- A1.6 PowershellでGitを使う
- A1.7 まとめ
-
A2. 付録 B: Gitをあなたのアプリケーションに組み込む
- A2.1 Gitのコマンドラインツールを使う方法
- A2.2 Libgit2を使う方法
- A2.3 JGit
-
A3. 付録 C: Gitのコマンド
- A3.1 セットアップと設定
- A3.2 プロジェクトの取得と作成
- A3.3 基本的なスナップショット
- A3.4 ブランチとマージ
- A3.5 プロジェクトの共有とアップデート
- A3.6 検査と比較
- A3.7 デバッグ
- A3.8 パッチの適用
- A3.9 メール
- A3.10 外部システム
- A3.11 システム管理
- A3.12 配管コマンド
3.2 Git のブランチ機能 - ブランチとマージの基本
ブランチとマージの基本
実際の作業に使うであろう流れを例にとって、ブランチとマージの処理を見てみましょう。 次の手順で進めます。
-
ウェブサイトに関する作業を行っている
-
新たな作業用にブランチを作成する
-
そのブランチで作業を行う
ここで、別の重大な問題が発生したので至急対応してほしいという連絡を受けました。 その後の流れは次のようになります。
-
実運用環境用のブランチに戻る
-
修正を適用するためのブランチを作成する
-
テストをした後で修正用ブランチをマージし、実運用環境用のブランチにプッシュする
-
元の作業用ブランチに戻り、作業を続ける
ブランチの基本
まず、すでに数回のコミットを済ませた状態のプロジェクトで作業をしているものと仮定します。
![単純なコミットの歴史](png/basic-branching-1.png)
ここで、あなたの勤務先で使っている何らかの問題追跡システムに登録されている問題番号 53 への対応を始めることにしました。
ブランチの作成と新しいブランチへの切り替えを同時に行うには、git checkout
コマンドに -b
スイッチをつけて実行します。
$ git checkout -b iss53
Switched to a new branch "iss53"
これは、次のコマンドのショートカットです。
$ git branch iss53
$ git checkout iss53
![新たなブランチポインタの作成](png/basic-branching-2.png)
ウェブサイト上で何らかの作業をしてコミットします。
そうすると iss53
ブランチが先に進みます。このブランチをチェックアウトしているからです (つまり、HEAD
がそこを指しているということです)。
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
![作業した結果、iss53 ブランチが移動した](png/basic-branching-3.png)
ここで、ウェブサイトに別の問題が発生したという連絡を受けました。
そっちのほうを優先して対応する必要があるとのことです。
Git を使っていれば、ここで iss53
に関する変更をリリースしてしまう必要はありません。
また、これまでの作業をいったん元に戻してから改めて優先度の高い作業にとりかかるなどという大変な作業も不要です。
ただ単に、master
ブランチに戻るだけでよいのです。
しかしその前に注意すべき点があります。 作業ディレクトリやステージングエリアに未コミットの変更が残っている場合、それがもしチェックアウト先のブランチと衝突する内容ならブランチの切り替えはできません。 ブランチを切り替える際には、クリーンな状態にしておくのが一番です。 これを回避する方法もあります (stash およびコミットの amend という処理です) が、後ほど 作業の隠しかたと消しかた で説明します。 今回はすべての変更をコミットし終えているので、master ブランチに戻ることができます。
$ git checkout master
Switched to branch 'master'
作業ディレクトリは問題番号 53 の対応を始める前とまったく同じ状態に戻りました。 これで、緊急の問題対応に集中できます。 ここで覚えておくべき重要な点は、ブランチを切り替えたときには、Git が作業ディレクトリの状態をリセットし、チェックアウトしたブランチが指すコミットの時と同じ状態にするということです。 そのブランチにおける直近のコミットと同じ状態にするため、ファイルの追加・削除・変更を自動的に行います。
次に、緊急の問題対応を行います。 緊急作業用に hotfix ブランチを作成し、作業をそこで進めるようにしましょう。
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix 1fb7853] fixed the broken email address
1 file changed, 2 insertions(+)
![`master` から新たに作成した hotfix ブランチ](png/basic-branching-4.png)
master
から新たに作成した hotfix ブランチテストをすませて修正がうまくいったことを確認したら、master ブランチにそれをマージしてリリースします。
ここで使うのが git merge
コマンドです。
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
このマージ処理で “fast-forward” というフレーズが登場したのにお気づきでしょうか。 マージ先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に進めたのです。 言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットをマージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。 マージ対象が分岐しているわけではないからです。 この処理のことを “fast-forward” と言います。
変更した内容が、これで master
ブランチの指すスナップショットに反映されました。これで変更をリリースできます。
![`master`が`hotfix`にfast-forwardされた](png/basic-branching-5.png)
超重要な修正作業が終わったので、横やりが入る前にしていた作業に戻ることができます。
しかしその前に、まずは hotfix
ブランチを削除しておきましょう。
master
ブランチが同じ場所を指しているので、もはやこのブランチは不要だからです。
削除するには git branch
で -d
オプションを指定します。
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
では、先ほどまで問題番号 53 の対応をしていたブランチに戻り、作業を続けましょう。
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53 ad82d7a] finished the new footer [issue 53]
1 file changed, 1 insertion(+)
![`iss53` の作業を続ける](png/basic-branching-6.png)
iss53
の作業を続けるここで、hotfix
ブランチ上で行った作業は iss53
ブランチには含まれていないことに注意しましょう。
もしそれを取得する必要があるのなら、方法はふたつあります。
ひとつは git merge master
で master
ブランチの内容を iss53
ブランチにマージすること。
そしてもうひとつはそのまま作業を続け、いつか iss53
ブランチの内容を master
に適用することになった時点で統合することです。
マージの基本
問題番号 53 の対応を終え、master
ブランチにマージする準備ができたとしましょう。
iss53
ブランチのマージは、先ほど hotfix
ブランチをマージしたときとまったく同じような手順でできます。
つまり、マージ先のブランチに切り替えてから git merge
コマンドを実行するだけです。
$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html | 1 +
1 file changed, 1 insertion(+)
先ほどの hotfix
のマージとはちょっとちがう感じですね。
今回の場合、開発の歴史が過去のとある時点で分岐しています。
マージ先のコミットがマージ元のコミットの直系の先祖ではないため、Git 側でちょっとした処理が必要だったのです。
ここでは、各ブランチが指すふたつのスナップショットとそれらの共通の先祖との間で三方向のマージを行いました。
![三つのスナップショットを使ったマージ](png/basic-merging-1.png)
単にブランチのポインタを先に進めるのではなく、Git はこの三方向のマージ結果から新たなスナップショットを作成し、それを指す新しいコミットを自動作成します。 これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。
![マージコミット](png/basic-merging-2.png)
マージの基点として使用する共通の先祖を Git が自動的に判別するというのが特筆すべき点です。 CVS や Subversion (バージョン 1.5 より前のもの) は、マージの基点となるポイントを自分で見つける必要があります。 これにより、他のシステムに比べて Git のマージが非常に簡単なものとなっているのです。
これで、今までの作業がマージできました。
もはや iss53
ブランチは不要です。
削除してしまい、問題追跡システムのチケットもクローズしておきましょう。
$ git branch -d iss53
マージ時のコンフリクト
物事は常にうまくいくとは限りません。
同じファイルの同じ部分をふたつのブランチで別々に変更してそれをマージしようとすると、Git はそれをうまくマージする方法を見つけられないでしょう。
問題番号 53 の変更が仮に hotfix
ブランチと同じところを扱っていたとすると、このようなコンフリクトが発生します。
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Git は新たなマージコミットを自動的には作成しませんでした。
コンフリクトを解決するまで、処理は中断されます。
コンフリクトが発生してマージできなかったのがどのファイルなのかを知るには git status
を実行します。
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
コンフリクトが発生してまだ解決されていないものについては unmerged として表示されます。 Git は、標準的なコンフリクトマーカーをファイルに追加するので、ファイルを開いてそれを解決することにします。 コンフリクトが発生したファイルの中には、このような部分が含まれています。
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
これは、HEAD
(merge コマンドを実行したときにチェックアウトしていたブランチなので、ここでは master
となります) の内容が上の部分 (=======
の上にある内容)、そして iss53
ブランチの内容が下の部分であるということです。
コンフリクトを解決するには、どちらを採用するかをあなたが判断することになります。
たとえば、ひとつの解決法としてブロック全体を次のように書き換えます。
<div id="footer">
please contact us at email.support@github.com
</div>
このような解決を各部分に対して行い、>>>>>
の行をすべて除去します。
そしてすべてのコンフリクトを解決したら、各ファイルに対して git add
を実行して解決済みであることを通知します。
ファイルをステージすると、Git はコンフリクトが解決されたと見なします。
コンフリクトの解決をグラフィカルに行いたい場合は git mergetool
を実行します。
これは、適切なビジュアルマージツールを立ち上げてコンフリクトの解消を行います。
$ git mergetool
This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html
Normal merge conflict for 'index.html':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (opendiff):
デフォルトのツール (Git は opendiff
を選びました。私がこのコマンドを Mac で実行したからです) 以外のマージツールを使いたい場合は、“… one of the following tools:”にあるツール一覧を見ましょう。
そして、使いたいツールの名前を打ち込みます。
注記
|
もっと難しいコンフリクトを解消するための方法を知りたい場合は、高度なマージ手法 を参照ください。 |
マージツールを終了させると、マージに成功したかどうかを Git が尋ねてきます。
成功したと伝えると、そのファイルを解決済みとマークします。
もう一度 git status
を実行すれば、すべてのコンフリクトが解消済みであることを確認できます。
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: index.html
結果に満足し、すべてのコンフリクトがステージされていることが確認できたら、git commit
を実行してマージコミットを完了させます。
デフォルトのコミットメッセージは、このようになります。
Merge branch 'iss53'
Conflicts:
index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
# modified: index.html
#
このメッセージを変更して、どのようにして衝突を解決したのかを詳しく説明しておくのもよいでしょう。 後から他の人がそのマージを見たときに、あなたがなぜそのようにしたのかがわかりやすくなります。