手動バージョン管理

まずは、バージョン管理ソフトを使わない場合、どんな感じになるかを見てみましょう。

d:\SRC\CopyTool\ と言うフォルダの下に下記の様に２つのファイルを作成したとします。 何か、ファイルをコピーするツールを作っているんだと思ってください。

d:\SRC\CopyTool\
    |-- Main.vb
    |-- Lib.vb

まだ未完成なプログラムです。でも今日はもうおしまいにして、 いったんバックアップを取ります。 フォルダ d:\SRC\CopyTool\bak\01\ を作ってその下に、Main.vbと、Lib.vb をコピーします。 そして、おうちに帰ります。（bakフォルダの位置が気に入らない、と言う人もいるかと思いますがとりあえず読んでくださいね）

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\
    |          |-- Main.vb
    |          |-- Lib.vb
    |     
    |-- Main.vb
    |-- Lib.vb

次の日、出社して、続きを作ります。 Main.vbsに追加、修正して、Lib.vbsは修正しなかったとします。

ここまで書いたところで、お昼になりましたので、またバックアップを取ります。 d:\SRC\CopyTool\bak\02\を作ってその下にコピーします。そしてご飯を食べに行きます。

するとこんな感じに。ファイル名が同じ色のファイルは内容が同じで、色が違うと内容も違うと思ってください。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

お昼から帰って、またまた作業、Main.vbsとLib.vbsの両方に修正、追加します。

ここまで書いたところで、終業時間になりましたので、またバックアップを取ります。 d:\SRC\CopyTool\bak\03\を作ってその下にコピーします。そしておうちに帰りました。

ではここまでで、どんなフォルダとファイルが出来たか整理してみましょう。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 03\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

実際は、仕事の終わったタイミングではなく、もう少しきりのいい、 たとえばある関数の中身を書き終わった後とか、コンパイルが通った後とか、 そんなタイミングでバックアップするとは思いますが、男らしくない人は大体こんな感じでバックアップしながら作業を進めていますよね。

Gitのバージョン管理と同じようなことを手動でやってみる

この「バックアップフォルダにサブフォルダを作って、そこにまるっとコピーする」 作業（と同じような作業）の事をGitではコミットと呼んでいます。（他のバージョン管理システムでも大体そうだと思います） そして、bak\フォルダに該当するものをリポジトリと呼んでいます。

また、ルートにあるファイルを（フォルダも含めて）ワーキングツリーと呼んでいます。 なんでツリーなんでしょう？たぶんフォルダによる階層をもてるので、それがツリーのイメージなんでしょうね。

Gitの場合は、「コミット」の前に、もう一つ作業があります。どんな作業かというと・・

まず下記のフォルダ階層をご覧下さい。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |
    |-- Main.vb
    |-- Lib.vb

これは、Gitの操作方法の概念を説明する為のフォルダ階層です。違いはと言うと、bak\フォルダの下に、stage\と言うフォルダが出来ていますね。 この状態は、01\と言うフォルダが無いので、まだ一度もコミットされていない状態です。

そして、コミットしたくなったとすると、コミットの前に行わなければならないのが、変更されているファイルと新規のファイルを stage\フォルダにコピーする、と言う作業です。 次の図はその作業を行った結果です。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |          |-- Main.vb
    |          |-- Lib.vb    <--+ 
    |                           |  copyする。
    |-- Main.vb    -------------+ 
    |-- Lib.vb   

この作業の事をGitでは、索引に追加するとか、コミット予定にいれるとかステージングするとか、一度もコミットしていないファイルへこの操作を行う場合は、ファイルを管理対象にするとか、はたまた、場合によっては競合の解決（競合については後で説明します）とか呼んでいます。 この操作を実行するコマンドは、そう、「はじめに」の例に出ていた「git add」です。

で、その状態で「コミット」すると、どうなるのかを示したのが次の図です。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 01\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

新しいバックアップフォルダ 01\が出来て、その中に、stage\中のファイルがコピーされました。ファイル名の色が同じものは、同じ内容である事を表します。 この状態で、Lib.vbを修正すると、次のような状態になります。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 01\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

次にこれを「索引に追加」すると、次のようになります。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 01\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

そして、コミットしないで、Main.vbsと、Lib.vbsを変更すると、次のようになります。stage\の内容とルートの内容が異なっていることに注意してください。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 01\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

ここで、コミットすると、こうなります。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 01\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

今行った変更はコミットされず、索引に追加した時点の変更がコミットされました。

これはつまり「索引に追加する」作業と、「コミット」の間に、d:\SRC\CopyTool\の直下のファイルを変更しても、それはコミットされない、と言うことなんです。 手動バックアップでは、とてもこんな事やる気にならないし、考えもつかないですよね。 ですので、たぶんGitを使ったバージョン管理をしたことが無いと知らない概念なのです。

そのうえ、コマンドはgit add、つまり追加なのに、ステージングと呼んだり、コミット予定に入れると言ったり、管理対象にすると言ったり、名前が統一されていないので、余計分かりにくいんです。 さらに、このコミット前に登録する場所の事を「索引」と呼んでいますが、索引と言うと、ファイル名のみ入るのかな？と思っちゃいますが、実際はファイルそのものがコピーされる様なイメージの場所なんです。

さて、ここまで理解したところで、「はじめに」に出ていたコマンドの説明を見てみましょう。

git add　- 索引(index)にファイルの内容を追加する

　　このコマンドは新しいファイルや修正したファイルのコンテンツを索引に追加します。 　結果としてそれらのコンテンツを stage する (次回のコミットに含めるようgitに指示する)ことになります。

いかがでしょう？だいぶ意味がわかる様になったでしょうか？たとえこの作業の意味がわかっていても、この説明はわかりにくいですね。

でも、なんでこんな面倒なことをしているのでしょうか？実はこれは「いま行われている変更の一部分のみをコミット出来る」様にする為なんです。

たとえば、Main.vbsとLib.vbsを両方変更した時に、索引にMain.vbsだけ追加してコミットすると、Main.vbsの変更だけがコミットされるんです。

そうすると何がうれしいのかと言うと、コミット時には、修正内容のコメントを付けられるので、わかりやすくてコメントしやすい単位でコミットを分けて行ったほうが、後で修正内容を把握しやすいと言うことです。 例えばフォルダにコメントを付けられるとすると、こんな風になると言うことです。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- stage\
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 03\ [Mainを実装]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 04\ [Libのfunction Openのバグを除去]
    |          |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

03\と04\を同時に変更していたとしても、上記の様に分けておいたほうが、後々やったことがわかり易くなりますよね。

もっとすごい事に、でもわかりにくい事に、Gitでは、索引に追加するときに、１つのファイル中の変更の一部だけを登録することも出来ます。 これはもっと後のほうで説明します。

ところで、このaddすることを、何故「索引に追加」、「ステージングする」、「管理対象にする」と、３通りの言い方をしているのでしょうか？

私の勝手な想像なので違うかもしれないですが、このaddは、当初、新規ファイルをGitの管理対象にするためだけに使われていたのではないかと思います。 それなら、索引に追加、とか、管理対象にする、と言う言い方で、ニュアンスが伝わりますよね。 でも途中で、コミットする時に、現在編集中の内容の一部を選択してコミット出来るようにしたくなって、「ステージング」と言う機能をこのaddコマンドに持たせちゃったのではないかと。 ちなみに「ステージ」とは、段階と言う意味ですが、なにか本番的なこと（この場合はコミット）を行う前の準備段階を表す意味で使用されています。

ここまでのまとめ

この節では、

• リポジトリ
• 索引に追加（ステージング、コミット予定、管理対象）
• コミット
• ワーキングツリー

ブランチとは？

あるプログラムの処理速度を高速化するアイデアが浮かんだのですが、ほんとにうまくいくかどうか自信が無いので、テスト的に修正してみたくなったとします。 そしてそのプログラムのリポジトリは下記のような状態だったとします。

※注意：ここからの説明ではコミットだけが重要なので、索引への追加は省略して説明します。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     　   |-- Main.vb
    |          |-- Lib.vb
    |
    |-- Main.vb
    |-- Lib.vb

テスト的に直すので、元のプログラムはそのままにしておき、もしうまくいったら入れ替えようと思い、下記の様に新しくtest\フォルダを作ります。 これがブランチです。元の編集を木の「幹」とすると、こちらは枝分かれした「枝」なので英語で枝を意味するブランチと言うのですね。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |     |-- Main.vb
    |     |     |-- Lib.vb
    |     |
    |     |-- test\  02から開始
    |           |-- bak\
    |
    |[testブランチ使用中]
    |-- Main.vb
    |-- Lib.vb

ワーキングツリーには「現在testブランチで作業中」いうマークがついていて、test\フォルダには、「02から開始」と記録されています。 testブランチは、メインの最新履歴02\から枝分かれしたということですね。

そしてtest\フォルダ直下のプログラムを修正し、コンパイルが通ったので、コミットします。するとこうなります。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |     |-- Main.vb
    |     |     |-- Lib.vb
    |     |
    |     |-- test\  02から開始
    |           |-- bak\
    |                |-- 03\ [コンパイル完了]
    |                     |-- Main.vb
    |                     |-- Lib.vb             <------ commit
    |
    |[testブランチ使用中]
    |-- Main.vb
    |-- Lib.vb

このように、test\フォルダの下のbak\の下に保存されます。バックアップフォルダの名前は、重複しないように03になっています。

テストをしたところ、バグがあったので、修正してコンパイルして、再度テストをしました。 今度はうまく動いたのですが、まだ満足いく速度ではありません。ですがいったんここでコミットします。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |     |-- Main.vb
    |     |     |-- Lib.vb
    |     |
    |     |-- test\  02から開始
    |           |-- bak\
    |                |-- 03\ [コンパイル完了]
    |                |    |-- Main.vb
    |                |    |-- Lib.vb
    |                |
    |                |-- 04\ [テストOKでもまだ遅い]
    |                     |-- Main.vb
    |                     |-- Lib.vb             <------ commit
    |
    |[testブランチ使用中]
    |-- Main.vb
    |-- Lib.vb

引き続き修正しようと、構想を練っていると、現在のリリースバージョンにバグがあると連絡がありました。実行中にエラーになって終了してしまうそうです。 まだtestブランチの修正はリリースするわけにはいきません。

そこで、メインに戻って修正することにしました。ブランチをメインに切り替えると、下記の状態になります。このブランチの切り替えをチェックアウトと言います。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |     |-- Main.vb
    |     |     |-- Lib.vb
    |     |
    |     |-- test\  02から開始
    |           |-- bak\
    |                |-- 03\ [コンパイル完了]
    |                |    |-- Main.vb
    |                |    |-- Lib.vb
    |                |
    |                |-- 04\ [テストOKでもまだ遅い]
    |                     |-- Main.vb
    |                     |-- Lib.vb
    |
    |[masterブランチ使用中]
    |-- Main.vb                      <------ 02\ フォルダからcheck out
    |-- Lib.vb

メインのことをGitではmasterブランチと呼んでいます。特別扱いされていますが、masterもブランチの一つです。 masterに切り替え、つまりmasterをチェックアウトすると、ワーキングツリーのファイルの内容はmasterの最新の02\フォルダの内容に置き換わります。 もしワーキングツリーにまだコミットされていない修正がある場合、メッセージが表示されてブランチを切り替えられません。 そうしないとコミットしていない修正が上書きされて消えてしまうからですね。

そしてバグを取って、コンパイル・テストして、OKなのでコミットします。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 05\ [エラーになるバグを修正]
    |     |    |-- Main.vb                       <--------- commit
    |     |    |-- Lib.vb
    |     |
    |     |-- test\  02から開始
    |           |-- bak\
    |                |-- 03\ [コンパイル完了]
    |                |    |-- Main.vb
    |                |    |-- Lib.vb
    |                |
    |                |-- 04\ [テストOKでもまだ遅い]
    |                     |-- Main.vb
    |                     |-- Lib.vb
    |
    |[masterブランチ使用中]
    |-- Main.vb
    |-- Lib.vb

リリースしてから、再び、testブランチをチェックアウトします。ワーキングツリーの内容は、04\フォルダの内容に置き換わります。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 05\ [エラーになるバグを修正]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- test\  02から開始
    |           |-- bak\
    |                |-- 03\ [コンパイル完了]
    |                |    |-- Main.vb
    |                |    |-- Lib.vb
    |                |
    |                |-- 04\ [テストOKでもまだ遅い]
    |                     |-- Main.vb
    |                     |-- Lib.vb
    |
    |[testブランチ使用中]
    |-- Main.vb                      <------ 04\ フォルダからcheck out
    |-- Lib.vb

そして再び修正し、今度はうまく行き、かなり高速になったので、コミットします。

d:\SRC\CopyTool\
    |-- bak\
    |     |-- 01\ [最初のコミット]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 02\ [Libのfunction Openを実装]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- 05\ [エラーになるバグを修正]
    |     |    |-- Main.vb
    |     |    |-- Lib.vb
    |     |
    |     |-- test\  02\から開始
    |           |-- bak\
    |                |-- 03\ [コンパイル完了]
    |                |    |-- Main.vb
    |                |    |-- Lib.vb
    |                |
    |                |-- 04\ [テストOKでもまだ遅い]
    |                |    |-- Main.vb
    |                |    |-- Lib.vb
    |                |
    |                |-- 06\ [高速化完了]
    |                     |-- Main.vb                       <--------- commit
    |                     |-- Lib.vb
    |
    |[testブランチ使用中]
    |-- Main.vb
    |-- Lib.vb

さて、これでおしまい、高速版をリリース、と言うわけにはいかないですよね。 と言うのは、masterブランチにはバグの変更があり、testブランチには高速化の修正があり、二つのブランチの内容が異なっているので。

ところで、今までの図の書き方では、とっても場所を食うし、コミットが多くなってくると非常にわかりにくいので、図の描き方を変えます。 今の状態を新しい図で書くと、次のようになります。

  �@ -- �A -- �D  <-- master
         ＼
           �B -- �C -- �E <-- *test

*は、現在チェックアウトしているブランチを示します。今までのフォルダ階層と比べてみてみてください。イメージがわかりますでしょうか？ この図だと、枝と言う意味のブランチと言うイメージが伝わりますよね。

以下の節では、このブランチ間の差異をどうするのかを見ていきます。

マージ

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
    next for
    msgbox("End")
End Sub

Sub Main()
   for each d in getFiles("c:\*.*")
      open(d)
      copy()
      close(d)
    next for
 End Sub

 Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
+      copy()
+      close(d)
    next for
-   msgbox("End")
 End Sub

  �@ -- �A -- �D  <-- master
         ＼
           �B -- �C -- �E <-- *test

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
    next for
    msgbox("End")
End Sub

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
       copy()
       close(d)
    next for
    msgbox("End")
End Sub

元のソースとのdiffは、下記のとおり

 Sub Main()
     for each d in getFiles("c:\*.*")
        open(d)
+       copy()
+       close(d)
     next for
     msgbox("End")
 End Sub

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
    next for
End Sub

元のソースとのdiffは、下記のとおり

 Sub Main()
     for each d in getFiles("c:\*.*")
        open(d)
     next for
-    msgbox("End")
 End Sub

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
       copy()
       close(d)
    next for
End Sub

  �@ -- �A -- �D  <-- *master
         ＼
           �B -- �C -- �E <-- test

  �@ -- �A -- �D -------- �F <- *master
         ＼              ／
           �B -- �C -- �E <- test

  �@ -- �A -------------- �D <-- master
         ＼                 ＼
           �B -- �C -- �E -- �F <-- *test

  �@ -- �A  <-- *master
         ＼
           �B -- �C -- �D <-- test

  �@ -- �A -- �B -- �C -- �D <-- *master test

  �@ -- �A  <-- *master
         ＼
           �B -- �C -- �D <-- test

  �@ -- �A -------------- �E <-- *master
         ＼              ／
           �B -- �C -- �D <-- test

  �@ -- �A  <-- *master
         ＼
           �B -- �C -- �D <-- test

  �@ -- �A -- �D  <-- *master
         ＼
           �B -- �C -- �E <-- test

  �@ -- �A  <-- *master
         ＼
           �B -- �C -- �D <-- test

  �@ -- �A -- �E <-- *master
         ＼
           �B -- �C -- �D <-- test

  �@ -- �A -- �D  <-- *master
         ＼
           �B -- �C -- �E <-- test

  �@ -- �A -- �D  <-- *master
               ＼
                �B'-- �C'-- �E' <-- test

  �@ -- �A -- �D -- �B'-- �C'-- �E' <-- *master test

  �@ -- �A -- �D  <-- *master
         ＼    ＼
           ＼    �F -- �G -- �H <-- test
             ＼
               �B -- �C -- �E

コンフリクト（競合）

前節のマージですが、「とても便利そうだね。でも、もし同じ行に違う変更をしちゃったら、一体どうなるんだろう？」って思いませんか？例を見てみましょう。

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
    next for
    msgbox("End")
End Sub

上記のソースの修正を下記の様に２通り行ったとします。

Sub Main()
    for each d in getFiles("c:\*.*")
       open(d)
       copy()
       close(d)
    next for
    msgbox("End")
End Sub

元のソースとのdiffは、下記のとおり

 Sub Main()
     for each d in getFiles("c:\*.*")
        open(d)
+       copy()
+       close(d)
     next for
     msgbox("End")
 End Sub

上記には、copy(), close()の行が追加されています。

Sub Main()
    for each d in getFiles("c:\*.*")
       Open(d)
       Copy()
       Close(d)
    next for
End Sub

元のソースとのdiffは、下記のとおり

 Sub Main()
     for each d in getFiles("c:\*.*")
-       open(d)
+       Open(d)
+       Copy()
+       Close(d)
     next for
-    msgbox("End")
 End Sub

上記では、open(d)を、Open(d) に、そしてCopy(), Close()の行が追加されています。そしてmsgboxの行が削除されています。 この二つをマージすると下記のようなメッセージが表示され、ソースにも同様の内容が表示されます。

  Sub Main()
      for each d in getFiles("c:\*.*")
  <<<<<<< HEAD
 +       open(d)
 +       copy()
 +       close(d)
  =======
+        Open(d)
+        Copy()
+        Close(d)
  >>>>>>> testbranch
      next for
-     msgbox("End")
  End Sub

--以下ソースの内容

Sub Main()
    for each d in getFiles("c:\*.*")
<<<<<<< HEAD
       open(d)
       copy()
       close(d)
=======
       Open(d)
       Copy()
       Close(d)
>>>>>>> testbranch
    next for
End Sub

この状態が、同じ行が異なる修正をされているときに発生する、競合（コンフリクト）です。 <<<<<<< HEAD から=======までが、現在編集中（チェックアウト中と言います）のブランチの内容で、 =======から>>>>>>> testbranch までが、マージ相手のブランチの内容です。 HEADの意味は別の機会に説明します。

競合が発生した場合は、ソースを手で修正してコミットしなければなりません。下記の様に手で修正して、Addしてテストしてコミットします。

Sub Main()
    for each d in getFiles("c:\*.*")
       Open(d)
       Copy()
       Close(d)
    next for
End Sub

コンフリクトが発生して手で修正した場合は、多くの場合、修正後再度テストが必要です。なにしろ、ソースを手でいじっているのですから。

また、コンフリクトは、マージ時点で発生する可能性があるので、マージだけではなく、マージの一種であるリベースや、もっと後のほうで説明しますが、複数でリポジトリを共有している場合のプルやプッシュ（他のリポジトリへ送ったり、取ってきたり）でも発生する可能性があります。

コンフリクトって、いやな事のトップ１０には入りますよね。 だって、やっと仕事が終わったと思って喜んでマージしたら、また修正してテストしなきゃならなくなるんですよ。 え、いやな事のトップ１は何かって？ええと、第2位は仕事かな？

ここまでのまとめ

ここまでに出てきた重要な概念の一覧です。

• ブランチ
• masterブランチ
• diff
• チェックアウト
• マージ
• 単にマージ
• ファストフォワードしないでマージ
• 必ずファストフォワードでマージ
• squash（融合）でマージ
• リベースしてからファストフォワードでマージ
• コンフリクト

インストール直後の作業

git config --global core.quotepath off
git config --global gui.encoding utf-8
git config --global user.email kkoba@plowman.co.jp
git config --global user.name  kkoba

リポジトリを作ってコミットしてみる

ファイルを書いてコミットしてみる

では、d:\SRC\test　の直下に何かファイルを作ってコミットしてみましょう。次のように作ってみました。

d:\SRC\test\
    |
    |-- File1.txt >  aaa
    |                bbb
    |
    |-- File2.txt >  ccc
                     ddd

>の後ろはファイルの内容です。この２つのファイルを作ったところで、Git Guiを起動して下さい。 すると左上の「コミット予定に入っていない変更」と言うペインに、File1.txt, File2.txt と表示されていますよね。 ファイル名をクリックしてみてください。アイコンはまだクリックしたら駄目ですよ、ファイル名。

すると、右上のペインの上部に「管理外、コミット未予定」と表示され、その下にファイルの内容が表示されます。 File1.txt, File2.txtを交互にクリックして確かめて下さい。

今度は、各ファイルのアイコンをクリックしてみて下さい。すると、クリックしたファイルが左下の「ステージングされた（コミット予定の）変更」と言うペインに移動します。 右下中央の「変更をコミット予定に入れる」と言うボタンを押すとまとめて登録することも出来ます。 この状態が、stageフォルダにコピーしたのと同じ状態、つまり「索引に登録した」とか、「ステージングした」とか、「コミット予定に入れた」とか、「管理対象にした」とか言う状態です。

今度は、「ステージングされた（コミット予定の）変更」と言うペインにFile1.txt, File2.txtが表示されているので、ファイル名をクリックしてみて下さい。 右上のペインの上部に「コミット予定済み」と表示され、その下にファイルの内容がdiffで表示されます。前のファイルが無いので、全行+となっているはずです。 ここでファイルのアイコンクリックすると、ステージング前の状態に戻ります。

ではいよいよコミットしてみましょう。ファイルを2つともステージングした状態にしてコミットボタンを押してください。するとあれれ？

なんかエラーが出ました。ふむふむ、コミットメッセージは必ず入れないといけないのね。では、「最初のコミット」といれて、コミットしてみよう。

コミットボタンを押します。すると

ファイル名の表示が消えて、一番下に「コミットxxxxxを作成しました。最初のコミット」と出ています。どうやらコミットできたようです。 状態を確認してみましょう。Git Gui のメニューの、リポジトリ/すべてのブランチの履歴を見る を選んでください。

するとこんな画面が出てきます。 上段にはコミット履歴のグラフが、下段にはグラフ上で現在選択されているコミットの情報が表示されています。 コミットの情報には、コミットメッセージや、このコミットで変更されたファイルのdiff等が表示されています。

ファイルを編集してコミットしてみる

さてこれだけでは、まだ全然面白くないので、ファイルを編集してコミットしてみましょう。 File1.txtの１行目を、aaa から Aaaに書き換えて、Git Gui上で F5 を押してください。

すると、コミット予定に入っていない変更にFile1.txtが現れるので、ステージングして、コメントは「File1を修正」としてコミットしてみてください。 コミットしたら、gitk の画面で F5 を押してください。

コミット履歴が２つになりましたね。こんな感じでどんどんコミットしていって、履歴を残すんです。

ブランチとマージを使ってみる

では今度はブランチを使ってみましょう。

ブランチを２つ作ってみる

では、現在のmasterブランチから、test1ブランチを作ってみましょう。Git Gui のメニューの、ブランチ/作成… を選んで下さい。

そして上の様に、名前の欄に test1 と入力してください。 「初期リビジョン」にはどのブランチから分岐するかを指定しています。 一番したの方にある「作成してすぐチェックアウト」にチェックが入っているので、test1ブランチ作成後、すぐにtest1ブランチがチェックアウトされます。 さあ、作成ボタンを押してください。すると、

Git Gui のメニューのすぐ下の「現在のブランチ」が、test1に変わりました。 これで、現在のワーキングツリーは、test1ブランチと言うことになります。 修正してみましょう。File2.txt の一行目を、ccc から、CCC に変更して、Git Gui で F5を押して、インデックスに追加して、メッセージを「File2を修正」として、コミットしてください。 そして gitk でF5すると。。。

グラフの部分がこんな風になります。

では今度は、masterブランチから、test2と言うブランチを作りましょう。まずは、masterブランチをチェックアウトします。 それには、Git Gui のメニューの、ブランチ/チェックアウト を選びます。するとウィンドウが開くので、masterを選んでチェックアウトボタンを押します。

これでmasterがチェックアウトされた状態になりましたので、先ほどと同じ手順で、test2ブランチを作成してください。 作ったら、Gitk で見てみましょう。

test2はまだ何も修正していないので、masterと同じところを指しています。 ではここで、File1.txtの２行目を、bbb から BbBに変えて、メッセージを「File1をまた修正」としてコミットしてください。 そしてgitkでF5して見てみてください。

おお、やっとブランチと言う感じのグラフになりましたね。

でもこれでは寂しいので、test1、test2それぞれで、もう１つづつコミットを追加してみましょう。 test1の方では File1.txt の３行目に、YYYを追加して、test2の方では、File2.txt の一行目に ZZZ を追加します。

手順はもう分かりますよね。更新したいブランチをチェックアウトして、修正して、コミット。これを繰り返すんです。 気をつけないといけないのは、チェックアウトすると、ワーキングツリーの内容が書き換わるので、エディタは再起動するか再読み込みしないといけないと言う点です。 では各自やってみましょう。私の結果をGitkで見ると以下の通りです。今度はコメントに詳しい説明も入れてみました。

おお、なんかややこしいけど面白い状態になってきた！！

単にマージしてみる

ではまず、この状態で、test1をmasterに「単にマージ」してみましょう。（単にマージって言うのは、実はオプション無しのマージって言う事です） masterをチェックアウトしてから、Git Gui のメニューの　マージ/ローカル・マージ… を選んでください。 ウィンドウが開いてブランチの選択画面になるので、test1を選択して、マージボタンを押してください。すると、

こんな画面が出ます。マージ成功ですね。閉じるを押してから、gitkを見てみましょう。

ブランチの枝分れ状態は変わっていませんが、masterが、test1と同じところに移動しています。 ファストフォワードされたんですね。

ではこんどは、test2をmasterに「単にマージ」してみましょう。 現在はまだmasterをチェックアウトした状態なので、先ほどと同じ手順で今度はtest2をマージしてみます。すると。。。

おおお、File1.txt も、File2.txtも、競合（コンフリクト）した！閉じる押してから、Git Gui で見てみましょう。

エディタでファイルを開いてみると、File1.txtもFile2.txtも競合状態になっています。 どうやら、追加した行と変更した行が隣接していたので、その行が変更された様に見えているんですね。 この場合は、ファイルを正しく変更して、１ファイルづつ索引に登録して、コミットします。

File1.txt
  Aaa
  BbB
  YYY

File2.txt
  ZZZ
  CCC
  ddd

上記の様に変更して、索引へ追加してコミットします。メッセージは自動生成されたものをそのまま使いましょう。ではGitkで見てみましょう。

ええっ？なんだこりゃ？この一つ前と比べてみよう。

うーん、よく分からない。実はgitkのグラフは、複雑になると分かりにくいんです。 何か設定があるのかもしれませんが、よく分かりません。グラフ以外の表示は非常に見やすいだけに残念です。将来に期待しましょう。 ですが、TortoiseGitで見るとずっと分かりやすいんです。 右クリック/TortoiseGit/ログを表示(L) すると、こんな画面が出ます。

おお、これなら分かる。 test2のマージはファストフォワードしないで、新しいコミットが１つ出来てマージされているのが分かりますよね。 この状態を図にすると、下記の様になります。

                   test1
                    ↓
  �@ -- �A -- �B -- �C -- �F ← *master
          ＼             ／
           �D -------- �E ← test2

ここまで、理解できましたでしょうか？まずはここまでをよくかみ締めて理解してから次に進んでください。

ファストフォワードしないでマージ

では次に、「ファーストフォワードしないでマージ」をやってみましょう。masterブランチから、testNoFF というブランチを作って下さい。 NoFFは、No Fast Forwardの略ですが、分かりやすくするために付けただけで、名前に何か意味や効果があるわけではありません。 そして、testNoFFで、何か変更して２回コミットしてください。内容は何でもいいです。（もう、例をいちいち作るのが面倒になりました）

私は、下記の様に作りました。

ではこれを、masterブランチに「ファーストフォワードしないでマージ」してみましょう。どうやるかと言うと。。。

実は、Git Guiでは、デフォルトでは出来ないみたいなんです。 TortoiseGitなら出来るのですが、あっちこっち使うのも面倒です。 で、Git Guiのメニューの「ツール」には、コマンドが登録出来るので、登録してやって見ましょう。

Git Guiのメニューの　ツール/追加　と選んで、表示されたウィンドウに下記の様に入力して追加ボタンを押してください。

そしてもう一度メニューの　ツール　を選ぶと、「現在のブランチにno-ffでマージ」と言う項目が追加されました。 いまいちなのが、間違えて追加しちゃっても、ここからは修正できません。出来るのは削除だけです。 修正するには、.gitconfig と言うファイルを直接編集する必要がありますが、これは後ほどどこかで説明します。

では、masterブランチをチェックアウトしてから、今追加した「現在のブランチにno-ffでマージ」を実行してみてください。 ダイアログでは、testNoFFブランチを選んでくださいね。するとこうなりました。

ちゃんとファストフォワードしないでマージされましたね。

squashマージ

では今度は、squashでマージしてみましょう。masterから、testSquashと言うブランチを作って、２回くらいコミットしてください。 私はこうなりました。

前と同じように、Git Guiにのツールにコマンドを追加します。 ツール/追加 で作成しますが、先ほどの画面で、名前を「現在のブランチへsquashでマージ」に、コマンドを「git merge --squash $REVISION」にして追加してください。

そして、masterブランチをチェックアウトしてから、今追加した「現在のブランチへsquashでマージ」を実行してみてください。 もちろんダイアログでは、testSquashブランチを選んでくださいね。 squashの場合は、自動でコミットされません。コミットメッセージを手動で書く必要があるからです。Git Guiが、この様になりました。

変更したファイルが、索引に追加された状態で、かつ、コミットメッセージが自動で表示されています。 元のコミットメッセージが表示されているのですが、残念なことに文字化けしていますね。 これも将来のバージョンに期待しましょう。 で、ここに手動でコミットメッセージを書いてコミットします。私の場合、こうなりました。

あれ、僕（私)のと違う！僕（私)のは、testSquashが出てないぞ！と、びっくりした方は、画面の下の方にある「すべてのブランチを表示」にチェックしてみてください。 testSquashが出ましたよね？testSquashと新しく出来たコミットが繋がっていないのがわかると思います。

ところで、gitk（Git Gui から表示させた履歴表示プログラム）では、これはどんな風に見えているかな？見てみましょう。

ちょっと分かりにくいけど、見れないと言うほどでは無いですね。でも、さっきのはなんだか分からなかったなあ。

ブランチの削除

では今度は、今までのブランチを削除してみます。削除前を残したい方は、フォルダ丸ごとコピーしといてください。 （あれ？なんかへんだなあ。。。こういう事したい場合はリポジトリをバージョン管理するのかしら？）

ブランチの削除は、Git Gui のメニューの ブランチ/削除…　を選びます。 そして表示されたWindowの上のペインで削除したいブランチを選びます。男らしく全部削除しましょう。 masterは削除しては駄目ですが、ここでは削除できなくなっていると思います。

たぶん、testSquashは、エラーが出て削除できなかったですよね。 これはtestSquashブランチが、どこにもつながっていないので、つまりマージされて無い変更があるので、ブランチ消すとその変更も（すぐではないけれど）消えちゃうよ、って警告です。 でも下の方の「無条件（マージ検査をしない）」にチェックを入れて削除しちゃいましょう。 するとこうなりました。

squash以外は、枝分れした状態が残っているのが分かります。

リベース

リベースの練習もしておきましょうね。まずはmasterからtestRebaseと言うブランチを作って、２回コミットしてください。 その後で（ブランチ作った後なら、コミットの前でもいいですが）masterブランチも２回コミットしてください。 競合すると分かりにくくなるので、競合しないように気をつけて。こんな感じになります。

今度はリベースのコマンドをツールに作ります。

こんな感じで追加してください。

そして、testRebaseをチェックアウトして、今追加した「現在のブランチをmasterへリベース」を起動してください。 すると、こうなります。

masterから枝分れした状態になっています。 testRebaseのワーキングツリーの内容を確認してください。masterへの変更と、testRebaseへの変更がマージされているはずです。

最後に「単にマージ」しちゃいましょう。masterをチェックアウトして、メニューの　マージ/ローカル・マージ　でマージすると・・

こうなりました。ファストフォワードされていますね。

リベースでは、もっとややこしいことも出来ます。 例えば、コミットの順序を変えたり、複数のコミットを１つにまとめたり。そのあたりは、忘れなければもう少し後で説明します。

タグ付け

タグとは、コミットに名札を付けるようなものです。よく使うのが、V1.0とか、V2.3とかのバージョンを付ける事ですね。 と言うか、それ以外にはあまり使い道を考え付きません。 これは簡単で、グラフ上で右クリックして、「このバージョンでタグを作成」を選んで、「名前」を入れるだけです。 ためしに最新バージョンに「v1.0.1」と付けるとこうなります。

タグは特定のコミット（バージョン）にくっついているので、ブランチが伸びても位置は移動しません。

  �C ファイル検索機能を追加(merge branch addfilesearch)
  ｜＼
  ｜  �B メインのＧＵＩにファイル検索機能を追加
  ｜  ｜
  ｜  �A ライブラリに検索関数 function searchFile, searchDirを追加
  ｜／
  �@ 前のバージョン

  �@ -- �A -- �D  <-- *master
         ＼
           �B -- �C -- �E <-- test

リポジトリを作成

２人で利用する最小限の構成には、リポジトリが３つ必要です。 １つは共用のリポジトリ、あとの2つは、２人がそれぞれ自分のパソコンの中にもつ、自分の作業に使用するリポジトリです。 共用リポジトリは、何らかの方法で二人から見える場所に存在する必要がありますが、自分用リポジトリは、相手に見えなくて大丈夫です。

とはいっても、これを読みながら勉強している方は、一人で勉強している場合が多いかと思うので、自分のパソコンの中にこの３つのリポジトリを作成して練習して見ましょう。 私もそのほうが、原稿書きやすいので。。。。

さて、ではまずリポジトリを作ります。d:\reposiories と言うフォルダを作って、その下に１つ share.git と言うフォルダを作ってください。 そしてそこをエクスプローラで開いて右クリックして、「Git ここにリポジトリを作成(Y)…」を選ぶと、次のウィンドウが表示されます。

上記の様に、Bareを生成（作業ディレクトリを作りません）を入れて、ＯＫを押してください。

すると、share.gitの下に、hooks, info, objects, refsと言うフォルダーと, config, description,HEADというファイルが出来ます。 .gitと言うフォルダは出来ませんね。 そう、bareなリポジトリとは、ルートがリポジトリとなっていて、ワーキングツリーを持たない、共有専用（ここで作業できない、が正しいですが、普通は共有用なので）のリポジトリなんです。 フォルダ名に拡張子「.git」を付けるのは、ベアリポジトリの慣例だそうです。

さて、次に２人が使うリポジトリを作るんですが、まず二人の名前を決めましょう。 太郎さんと花子さん（ダサっ）にしましょう。 それぞの用のリポジトリを作りますが、今回は新たに作るのではなく、共有リポジトリをクローンして作ります。 クローン人間とか言うときのクローンです。 クーロン（1秒間に1アンペアの電流によって運ばれる電荷）じゃなくて、クローンですよ。（あ、学がにじみ出てしまった） まあ、コピーみたいなものですが、もう少し高級なものです。

どうするかと言うと、まず、d:\reposiories　の直下(つまりshare.gitの一つ上)に移動して、Taroと言うフォルダを作成して、エクスプローラでそこを開いて下さい。 空っぽですよね。そこで右クリックして「Git クローン...」を選んでください。すると…

こんな画面が出るので、URLの所に上記の様に入力するか、フォルダーボタンでshare.gitを選んでください。 ディレクトリのところは自動でフォルダ名から.gitを取り除いた名前になります。 そしてＯＫ押しちゃってください。 すると、taroの下にshareと言うフォルダが出来て、その下には.gitが出来ます。

引き続き、d:\reposiories　の直下にhanakoと言うフォルダを作成して同じようにクローンして下さい。 すると…

d:\repositories\
    |
    |-- share.git
    |     |-- hooks\
    |     |-- info\
    |           :
    |-- taro\
    |     |-- share\
    |           |-- .git\
    |
    |-- hanako\
          |-- share\
                |-- .git\

こんな感じになりました。share.gitが共有リポジトリで、各名前のフォルダの下の share と言うフォルダがそれぞれのリポジトリです。 これで準備完了！

太郎がコミットして共有リポジトリへ送ってみる

じゃあ、まず今は、あなたは太郎です。そして何かファイルを作ってコミットしてみましょう。 面倒なのでとりあえず１ファイルだけ作ってコミットしましょう。 d:\repositories\taro\share の下に作るんですよ。 私はこうしました。

コミットしちゃいますね。。。しちゃいました。 では、この状態で、共有リポジトリと花子さんのリポジトリはどうなっているでしょうか？ 確かめてみましょう。

まず共有リポジトリをエクスプローラで開いて右クリックでGit Guiを起動してみてください。 「裸のリポジトリは使えません」って怒られたでしょう（笑）。風呂上りに裸で操作していた人は、「裸でリポジトリは使えません」かと思って驚いたことでしょう。

でも、「裸の」っていうのはベアの直訳です。ベアリポジトリーではGit Guiは使えないんです。 それに、Git History が右クリックメニューに表示されていないですよね。 実はこれ、まだ何にもコミットが無いので、Git Historyが表示されてないんです。 コミットされると表示されます。

でも何とか中を見たいので、Git Bash で、git log って入れてみてください。

$ git log
fatal: bad default revision 'HEAD'

って出ましたか？何かエラーになってますね。これはまだコミット履歴が一件も無いからです。'HEAD'についてはまだ説明していません。後でどこかで説明します。 花子さんのリポジトリも同じ状態なのを確認してください。（花子さんは残念ながら裸ではないので、Git Guiが動きます。）

という事で、太郎さんのリポジトリにコミットしても、花子さんのリポジトリにも、共有リポジトリにも何も起こっていません。空っぽのままでした。

実はこれ、とても重要なことで、しかもある意味Gitのすばらしいところの一つでもあります。 私たちのネットワークとかクライアントサーバーとかになれちゃった頭だと、なんとなく、関係あるリポジトリはコミットするとお互いになんらかの連携があるんじゃないかと思っちゃいますよね。 しかしGitでは連携させるコマンドを実行しない限り、一切何も全くぜんぜん連携しません。 ブランチ作ろうがコミットしようがマージしようがリベースしようが、完全にローカルなリポジトリの中だけの事なんです。

という事は、あなたがノートＰＣで開発しているのなら、共有リポジトリにネットワークでつながっていない場所でも普通に作業が可能だという事です。 開発者が共有リポジトリが見える場所で作業しない（出来ない）場合、これは非常に便利なことです。 共有リポジトリが見えなくても、ローカルでコミットしながら作業が進められるからです。

ところで、今後、「○○リポジトリをエクスプローラで開いて右クリックで××を起動して下さい」って言うのを、「○○リポジトリで××を起動して下さい」って言いますね。

ここでHEADの意味を説明することにしました

唐突ですが、ここでHEADの説明をしてみたくなりました。なんかずっと保留していたら、気持ち悪くなってきたので。それに、自分も良くわかっていないので、書くとなればちゃんと調べなくちゃならなくなるんでね。

簡単に言うとHEADと言うのは、現在チェックアウトしているコミットを指す代名詞です。普通はあるブランチのコミットをチェックアウトしているので、「現在チェックアウトしているブランチを指す」といっても、間違いでは無いですが、厳密に言うと違います。あくまで、「現在チェックアウトしているコミット」の事を指しているのです。（もしかしてもっと厳密に言うと違うのかもしれないですが、少なくとも今は私はそう思っています）

何が違うのかと言うと、チェックアウトする時に、コミットのリビジョン（コミットに付けられているながーい１６進数で、コミットを全世界で一意に識別する番号）を指定してチェックアウトすると、必ずしもあるブランチの指すコミットがチェックアウトされるとは限らないからです。

そしてブランチやタグと関係ないコミットを指している状態を「切り離されたHEAD」とか「無名ブランチ」とかいう事があります。

コミットを指定する方法はたくさんあります。ブランチ名はブランチの指すコミットを意味しますし、タグ名の時はそのタグが付けられたコミットになります。またHEAD^と指定すると、現在のHEADの一つ前、HEAD^^は２つ前となります。 無名ブランチをチェックアウトする簡単な方法は、HEAD^を指定してチェックアウトすることです。 何も破壊されないので、どうなるかためしにやってみて下さい。でもその後で元に戻しておいてくださいね。

そのほかにコミットを指定する代名詞に、ORIG_HEADと、FETCH_HEADというのがあります。（もっとあるのかもしれないですが、今私が知っているのはこの３つです。）

ORIG_HEADには、現在のHEADに対して何らかの危険な操作が行われてHEADが移動する場合に、移動前のHEADが保存されます。主にその操作の前の状態に戻す為に使われます。危険な操作とは、プルとか、コミットとかマージとかリベースなんかだと思いますが、これが全部なのかどうか分かりません。何見ればわかるのかなあ。

FETCH_HEAD は、フェッチと言うコマンドを練習した後にまた説明しますね。

Git Bash で、cat .git\HEAD と入力すると、現在のHEADコミットのを示す情報やリビジョン番号（ハッシュ値）が表示されます。catは猫で、ファイルの内容を出力するコマンドでもあります。Windows だと確かtypeだったかな？忘れちゃった。。今やってみたら、そうでした！

$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/ORIG_HEAD
86cd8f4bc863bc5ec955feb9ef5bc7979449d896

ファイルとして保存されているのですね。 HEADの内容は、masterの指すコミットを指している、と言う意味です。この意味はまたどこかで説明しますね。ORIG_HEADのほうは、コミットのハッシュ値です。長すぎ。。。でもGuiで操作していると普段はあまり使うことはありません。 万が一このハッシュ値を入力しなくてはならなくなっても、前の方の一意に識別できる確か７桁くらいでＯＫみたいですよ、詳しくは書きませんが。。。。

共有リポジトリに送る

では、太郎のコミットを共有リポジトリに送りましょう。送るには、プッシュします。太郎のリポジトリでGit Guiを開いて、「プッシュ」と言うボタンを押してください。するとこんな画面が出ます。

このまま、この画面のプッシュを押せばいいだけなんですが、プッシュについて理解する為に、画面について簡単に説明します。

まず、「元のブランチ」のところは、送信元、この場合は太郎さんのリポジトリ中のブランチの一覧が表示され、現在チェックアウトしているブランチが選択されています。今はmasterしなかくて、それが選択されていますね。プッシュするのはブランチであって、リポジトリ全体では無いんだなあ、って事が予想つきますよね。

送り先リポジトリは、リモートが選択されていて、コンボボックスにoriginが選択されていますね。このコンボボックスの▼を押しても、origin以外に選択肢はありません。これは何だろう？実はこれ、クローンして作られたリポジトリから見た、元のリポジトリのことを指しています。オリジナルって事でしょうね。

このoriginの設定は、.git\config の中にこんな風に書かれています。

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = D:\\repositories\\share.git

fetchのほうは後で説明するとして、urlの方が、originの示すリポジトリだという事がわかりますよね。でも、フルパスで書かれているので、移動しちゃうと見つけられずにエラーになってしまいますので気をつけましょう。.git\configファイルは手動で編集しても大丈夫ですから、移動した場合、ここを修正するだけでＯＫです。相対パスも使えます。

では、プッシュを押しちゃって下さい。すると。。。

こんな画面が出ました。プッシュ成功です！そこで、今度は共有リポジトリで、Git Historyを起動してみて下さい。（TortoiseGitの「ログを表示」のメニューは、ベアリポジトリではなぜか表示されません。なにか設定がいるのかな？）こんな感じになります。

おお、プッシュされたみたいだ。

花子さんが共有リポジトリから取得する

では今度は、あなたが花子さんになって、共有リポジトリから取得してみましょう。 花子さんのリポジトリで、Git Guiを動かしてください。 ほらほらあなた、Hanakoの直下じゃなくて、Hanako\share の下ですよ。

そして、メニューの　リモート/取得元/origin を選んでください。 なんかウィンドウが出ましたね。 ではそれを閉じて、同じくGit Guiのメニューの、リポジトリ/すべてのブランチの履歴を見る　を選んでください。

取得できてる！あれ、でもなんか見慣れない感じですね。ブランチ名が「remotes/origin/master」になっている。

ところで、今実行した「リモート/取得元/origin」とは一体何をしたのでしょうか？Git GuiはGuiで分かりやすく実行できるのはいいんですが、どのコマンドをどんなオプションで実行したのかが分かりにくくて困ります。 Gitのヘルプやネットでの情報は、みんなコマンドで説明しているので、メニューの項目がどのコマンドに相当するのか分からないと、あることをしたい時にメニューのどのれを選べばいいのか分からないんです。TortoiseGitの方はもっと色々と機能があって細かなオプションが指定できますが、やはり同じようにコマンドとの関係が分かりにくいですね。

どうやら、「リモート/取得元/origin」は、フェッチ(fetch)と言うコマンドを実行しているようです。フェッチすると先ほどのgitkの画面の様に、フェッチ元（この場合はorigin)中にあるmasterブランチの内容が、remotes/origin/master ブランチとしてローカルに作成されました。これはちょっと特殊なブランチで、通常はチェックアウトして使う事はなく、マージ元やブランチの作成元としてのみ使います。

もしGitを少しでも勉強したことがあれば、「あれ？ここはプルじゃあないの？」と思いますよね。 しかし、「プルによって共有リポジトリの情報を取得するんだ」と単純に思うことは、実はあまりよろしくないことなのです。なぜかは、後ほど説明します。 とはいえ、とりあえずプルもしてみましょうか？ 実はGit Gui には、プルのメニューはありません。調べたところ、どうやらこれは「プルはプルについて良く知らない人は使うな！」と言う作者様のメッセージの様です。

でも使っちゃいましょう。Git Bashでやるか、Git Gui のツールに追加してもいいのですが、今回は、TortoiseGitの 「プル」を使ってみましょう。選ぶとこんな画面が出ます。

なんかマージっぽいオプションがありますが、気にせずＯＫを押してください。 そしてGitkを見てみると。。。

あ、masterブランチが出てきた。でも remotes/origin/master もあります。

実はここの辺りのブランチの関係が、Gitをグループで使用する場合に一番ややこしくて理解しにくい部分なんです。

今の状態について整理して考えてみよう

ここでちょっとこんがらがってきたと思うので、じっくり腰をすえて、整理してみましょう。 そうしないと、この後どんどん分からなくなっていきます。

フェッチ、ローカルブランチ、リモートリポジトリ上のブランチ

では、今の３つのリポジトリの状態はどうなっているのか見てみましょう。 太郎さんのリポジトリはと言うと、

あ、花子さんのと全く同じですね。共有リポジトリは前にもありましたが再掲すると、

こうなっています。 では、この状態から、花子さんのmasterリポジトリで、ちょっと修正してコミットして、プッシュしたらどうなるのかみてみましょう。下記のような変更をしました。

そして、花子さんのリポジトリは下記の様になりました。

この時点では、花子さんはコミットしただけなので、共有リポジトリも、太郎さんのリポジトリも、変化はありません。 では、花子さんのリポジトリを共有リポジトリにプッシュしてみましょう。 プッシュ後の太郎さんと花子さんと共有リポジトリの状態は下記の通りです。

太郎さん�@

花子さん

共有

共有リポジトリと花子さんのリポジトリは、remotes/origin/master があるか無いか以外は同じです。

では今度は太郎さんのリポジトリで、フェッチ（メニューから、リモート/取得元/origin）を実行してから状態を見てみると、

太郎さん�A

太郎さん�@と太郎さん�Aを比べてみて下さい。master の位置は変わっていませんが、remotes/origin/masterの位置が新しいコミットを指しています。これはどういう事でしょうか？

ところで、今後、リポジトリの状態を確認する作業を大量に行わなくてはなりません。 そのたびに画像をキャプチャして貼り付けるのがとても大変になってきたので、申し訳ありませんが、下記のコマンドを使った、Git Bashによる確認に変えさせていただきます。

git log --graph --all --format=format:'%C(bold yellow)%d%C(reset) %s'

これだと、テキストの貼り付けですむので。 でもコマンドを毎回入力するのは流石にいやなので、下記の内容を、.gitconfigに追加しましょう。Git Bashで下記のコマンドを入力してください。

$ git config --global alias.lg "log --graph --all --format=format:'%C(bold yellow)%d%C(reset) %s'"

とりあえず、コマンドのオプションの意味はわからなくてもいいですが、これで、Git Bashで「git lg」と入力すると、上記のオプションを設定したことになります。

では、新しい確認方法で、３つのリポジトリの内容を確認してみます。

$git lg

共有リポジトリ
*  (HEAD, master) 花子の最初のコミット
*  太郎の最初のコミット

花子のリポジトリ
*  (HEAD, origin/master, master) 花子の最初のコミット
*  太郎の最初のコミット

太郎のリポジトリ�@　フェッチ前
*  (HEAD, origin/master, master) 太郎の最初のコミット

太郎のリポジトリ�A　フェッチ後
*  (origin/master) 花子の最初のコミット
*  (HEAD, master) 太郎の最初のコミット

ああ、楽ちんだ！git lg コマンドは一々書くと見にくいので省略しました。

では、それぞれ、どういう状態なのか見ていきましょう。

まず、共有リポジトリには、太郎の最初のコミットと、花子の最初のコミットが反映されており、HEAD, masterともに、花子の最初のコミットを指しています。（共有リポジトリにはワーキングツリーが無いのに、HEADはあるんですね。）

次に花子さんですが、太郎の最初のコミットと、花子の最初のコミットが反映されており、HEAD, origin/master, master が花子の最初のコミットを指しています。 そのうちのorigin/masterと masterが「ブランチ」です。

次にフェッチ前の太郎�@ですが、共有リポジトリと花子さんのリポジトリには、花子の最初のコミットが反映されていますが、まだ太郎には反映されておらず、太郎の最初のコミットしかありません。そして、HEAD, origin/master, masterは、その太郎の最初のコミットを指しています。

最後のフェッチ後の太郎�Aは、一番複雑ですね。太郎の最初のコミットと、花子の最初のコミットが反映されていますが、HEAD, masterは、太郎の最初のコミットを指しているけれど、origin/masterは花子の最初のコミットを指しています。

全部を図にするとこんな感じですね。

コミット�@ : 太郎の最初のコミット
コミット�A : 花子の最初のコミット

共有リポジトリ

  �@ -- �A ← HEAD, master

花子のリポジトリ

  �@ -- �A ← HEAD, origin/master, master

太郎のリポジトリ�@　フェッチ前

  �@ ← HEAD, origin/master, master

太郎のリポジトリ�A　フェッチ後

  �@ -- �A ← origin/master
  ↑
  HEAD, master

太郎のリポジトリでのフェッチで起きたことは、

1. 共有リポジトリからコミット�Aを取得
2. origin/masterがコミット�Aに移動

の２つです。

でもorigin/masterって何でしょう？ origin/masterは、originからの情報取得(クローン、フェッチ、プッシュ、プル等）を行った時点のoriginのmasterの内容を保持しているローカルなブランチです。

言っていることが分からないでしょう。 ええ、私も上の文を読み返しても自分でもなんだか分からないですから。 ここは、たぶんGitを理解する上でのポイントです。 次の節で詳しく説明します。

その前に、太郎さんのリポジトリのmasterを最新の位置に移動させるにはどうするかを見てみましょう。方法は２つ、カレントがmasterの状態で（他にブランチが無いんでそれしか無いですけどね）プルするか、origin/masterをマージするか、です。 前にも説明しましたが、プルはフェッチしてからマージを実行していますので、フェッチで最新情報が取得されていれば、結果はどちらも同じです。今回はマージをGit Bash上でやって見ましょう。

username@pcname /D/repositories/taro/share (master)
$ git merge origin/master
Updating 61a35d6..60b5d4f
Fast-forward
 Hanako001.txt | 4 ++++
 1 file changed, 4 insertions(+)
 create mode 100644 Hanako001.txt

username@pcname /D/repositories/taro/share (master)
$ git lg
*  (HEAD, origin/master, master) 花子の最初のコミット
*  太郎の最初のコミット

$で始まる行が私が入力したコマンドです。花子さんと同じになりましたね。

ddf87e3491904d31c41a3fcaab11373d39058958	not-for-merge	branch 'TB_SpeedUp' of D:\Git_repositories\Test\RenkeiTest\Center
050c4f66b1898e1cd55cdcf16fba0b3828f6d392	not-for-merge	branch 'TESTBR' of D:\Git_repositories\Test\RenkeiTest\Center
a79238a88e50087a3f44c79010ee5441bd2aa195	not-for-merge	branch 'develop' of D:\Git_repositories\Test\RenkeiTest\Center
b484c1a0931f6a3bebc56c61c4e5d6e39e9c0689	not-for-merge	branch 'master' of D:\Git_repositories\Test\RenkeiTest\Center
f8481a53f3d10e384837bfd2549fc727a92fe2d2	not-for-merge	branch 'testconfilict1' of D:\Git_repositories\Test\RenkeiTest\Center

$ git show FETCH_HEAD
commit ddf87e3491904d31c41a3fcaab11373d39058958
Merge: a370a8d 0ef36fd
Author: kkoba 
Date:   Fri Aug 31 09:24:32 2012 +0900

    Merge branch 'TB_SpeedUp' of D:\Git_repositories\Test\RenkeiTest\Center into TB_SpeedUp

XSystem.git リポジトリ

                 �F <-- develop
               ／
  �@ -- �A -- �D  <-- *master
         ＼
           �B -- �C -- �E <-- test

Ichiro/XSystem リポジトリ   remotes/origin -> XSystem.git

                 �F <-- origin/develop
               ／
  �@ -- �A -- �D  <-- *master origin/master
         ＼
           �B -- �C -- �E <-- origin/test

XSystem.git リポジトリ

                 �F <-- develop
               ／
  �@ -- �A -- �D ― �G <-- *master
         ＼
           �B -- �C -- �E <-- test

Ichiro/XSystem リポジトリ

                 �F <-- origin/develop
               ／
  �@ -- �A -- �D <-- *master  origin/master
         ＼
           �B -- �C -- �E <-- origin/test

Ichiro/XSystem リポジトリ

                 �F <-- origin/develop
               ／
  �@ -- �A -- �D  <-- *master
         ＼    ＼
           ＼    �G <-- origin/master
             ＼
               �B -- �C -- �E <-- origin/test

Ichiro/XSystem リポジトリ

                 �F <-- origin/develop
               ／
  �@ -- �A -- �D -- �G <-- *master  origin/master
          ＼
            �B -- �C -- �E <-- origin/test

Ichiro/XSystem リポジトリ

                 �F <-- *develop  origin/develop
               ／
  �@ -- �A -- �D -- �G <-- master  origin/master
          ＼
            �B -- �C -- �E <-- origin/test

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = 共用リポジトリへのパス
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "develop"]
	remote = origin
	merge = refs/heads/develop

XSystem.git リポジトリ

                 �F <-- develop
               ／
  �@ -- �A -- �D ― �G <-- *master
         ＼
           �B -- �C -- �E <-- test

Ichiro/XSystem リポジトリ

                     �H -- �I <-- *develop
                   ／
                 �F <-- origin/develop
               ／
  �@ -- �A -- �D -- �G <-- master  origin/master
          ＼
            �B -- �C -- �E <-- origin/test

XSystem.git リポジトリ

                 �F ― �H -- �I <-- develop
               ／
  �@ -- �A -- �D ― �G <-- *master
         ＼
           �B -- �C -- �E <-- test

Ichiro/XSystem リポジトリ

                 �F -- �H -- �I <-- *develop origin/develop
               ／
  �@ -- �A -- �D -- �G <-- master  origin/master
          ＼
            �B -- �C -- �E <-- origin/test

プルをみだりに利用するのが良くない理由

以前、”「プルによって共有リポジトリの情報を取得するんだ」と単純に思うことは、実はあまりよろしくないことなのです”。と言いましたが、その理由を簡単に説明します。

プルを使うときには、「リモートリポジトリと同じ状態にする」つまり、最新をローカルに同期する的な動作を期待していますよね。 しかし、プルは、フェッチとマージの２つのコマンドを連続して実行しているだけなんです。

masterリモートリポジトリ上のブランチと連携しているブランチ上でプルをオプション無しで実行した場合、フェッチしてから、対応するトラッキング・ブランチと現在のブランチを（オプションを指定していないと）「単にマージ」します。つまり、ファストフォワードできないときは、マージコミットが出来るという事です。 しかもこのブランチを次にプッシュしたときには、当たり前ですがこのマージコミットも共有リポジトリ上に送られちゃいます。 これはたぶん期待している動作では無いでしょう。リモートの最新情報の取得がマージコミットを作るなんて。

意図しないマージコミットを作らない為には、プルではなくて、一度フェッチしてから、状態を確認して、どうマージしたいかを決めてから、ローカルで正しくマージしたほうがいいですよ、っていう事です。 プルする時は、いっそいつも--ff-only オプションを付けたほうがいいかもしれません。 そうすれば、マージコミット作らないとマージできないときは、エラーになりますから。

プルでマージコミットが出来ちゃう状態とはどんな状態なのでしょう？ それは、ローカルにだけしかない変更とリモートにだしかない変更があった場合です。 でもmasterブランチでそんなことが起こるというのは、運用ルール違反になるべきことです。 masterで作業しちゃったか、間違ってマージしちゃったか、マージしてまだプルしないでしばらく置いておいたか、のどれかではないかと思います。

Gitの最初の練習では、みんなmasterブランチを使うので、masterで作業するのが当たり前な感じがしますが、 もしみんなmasterで作業して、プッシュして、プルしていたら、プル時のマージコミットが出来まくりますよね。 だからmasterブランチでは作業してはだめで、トピックブランチで作業しましょうと言う事なんです。 masterブランチに限らず、永続ブランチは、基本的にみんなこの様な考えで運用すべきです。

masterの様な永続ブランチは、いっそのことローカルでは作業できないようにしちゃえばいいんですけどね。 masterをチエックアウトしてマージした後に、忘れてそのまま作業しちゃったりする事があるので。 そして、プルは--ff-only をデフォルトにする。 あと、masterにトピックブランチをマージして、まだプルしていない状態の時は警告が出るとかね。 hookを使えば、なにかそれに近いことが出来るかもしれませんので、研究してみましょう。

連携していないローカルブランチ上でのオプションなしのプルは、「連携して無いよ」って言われてエラーになります。ネット上の情報では、違う動作になるような事が書いてあるところもあるので、Gitのバージョンによって動作が違うのかもしれません。

コミットは、整理できるんです

前も話しましたが、コミットは整理できます。 整理って言うのは、順番を入れ替えたり、複数のコミットを１つにまとめたり、逆に分けたり、っていう事です。 どうして整理するかと言うと、開発中のコミットと、履歴として公開したいコミットは意味や目的が違うので、公開前にコミットを履歴としてきれいにするのが目的です。 それだけじゃあなくって、同じミスを何度も繰り返しているような恥ずかしいコミットを人に見られたくない、って言う理由もあります。 逆に整理できるので、開発中はあまり気にせずにチョコチョコとコミットしておけるので気が楽ですねえ。でもある程度は考えてコミットしていないと後で整理に苦労することになります。この辺は経験が必要ですね、私も無いけど。

整理するには、リベースに -i オプションを付けて、「対話型の編集」と言うのを行います。対話型の編集って言うのは、Gitがコミット整理用のコマンドリストをエディタに表示してくれるので、それを修正してから保存してエディタを終了すると、その通りに整理してくれるって言うやり方です。 言葉だとわかりにくいんで、実際やって見ましょう。

使用するエディタを登録

でもやる前に、Gitに、使用するエディタを設定しないといけません。 Gitにはvi や vimと言ったunix系で使うエディタが同梱されていますが、慣れていないとそれを覚えるのが大変なので、秀丸を設定してみましょう。 あなたが良く使っているエディタがあればそれでもいいですが、文字コードをutf-8に指定できるエディタじゃないと駄目ですよ。

秀丸を使用するには、下記の内容を、ユーザーフォルダ\.gitconfigに追加してください。 このファイルも漢字はutf-8になっているので注意してください。多分フォント名が漢字で登録されていると思います。

[core]
	editor = 'c:/program files (x86)/hidemaru/hidemaru.exe' //fu8 //i

秀丸へのパスは、私のとあなたのが同じとは限らないので、あなたのパスに変更してくださいね。 [core] が既に存在している場合は、そのセクションの一番下に editor = の行を追加してください。 /fu8 は、漢字をutf-8 として扱う、/i は、タブモードの時タブを分離して起動する、と言うどちらも秀丸の起動時のオプションです。 /iを指定しないと、既に秀丸が動いている場合、一緒のWindowで表示されてしまうので、それを避ける為です。 //と二つ書いている点に注意してください。

ちょっと話は変わりますが、スカッシュや競合時に、Git Guiに自動で表示されるコミットメッセージの漢字が化けていましたよね。 CommitをGit Bash で操作すると、ここで設定したエディタが起動して化けずに表示されます。 やっぱりGitはまだまだCUIなプログラムなんですね。

やって見ましょう

では、早速練習してみましょう。適当なリポジトリを作ってコミットを６つほど作ります。 最初から競合すると話がややこしくなるので、各コミットでは違うファイルを追加するなどして、競合が起きないようにしてください。私は各コミットごとに、test1.txt, test2.txtとファイルを１つづつ追加していきました。（同じファイルを修正すると、コミットの順番を変えても競合しないようにするっていうのは、至難の業です。）私のはこんな感じです。 (git lg のlg は、前に登録したエイリアスです。)

kazukoba@KAZUKOBA-PC /D/repositories/rebaseRenshu (master)
$ git lg
*  (HEAD, master) コミット６
*  コミット５
*  コミット４
*  コミット３
*  コミット２
*  最初のコミット

$ git rebase -i HEAD~5

[guitool "リベース/コミットの対話型編集..."]
	cmd = git rebase -i HEAD~$ARGS
	title = コミットの対話型編集
	prompt = 現在のブランチのコミットを対話型編集します。エディタの設定が必須です。
	argprompt = 何回前まで？

pick 793858f コミット２
pick fe66212 コミット３
pick 0bda379 コミット４
pick f357427 コミット５
pick b77dbf0 コミット６

# Rebase 88be8fc..b77dbf0 onto 88be8fc
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

# コマンド:
#  p, pick = このコミットを使用する
#  r, reword = このコミットを使用するが、コミットメッセージを編集する
#  e, edit = このコミットを使用するが、内容を変更する為に停止する
#  s, squash = このコミットを使用するが、前（上の行）のコミットに融合させる
#  f, fixup = "squash"と同じだが、 このコミットのメッセージは捨てる
#  x, exec = （行の以降の部分を）コマンドとしてシェルで起動する
#
# 行は順番を入れ替えられます。コマンドは上から順に実行されます。
#
# もし行を削除すると、その行のコミットは失われます。
# しかし、全部のコマンド行を削除すると、リベースは中断されます。
#
# 「空のコミット」はコメントアウトされています。
# (「空のコミット」とは、--allow-emptyでコミットされた変更の無いコミット)

pick b77dbf0 コミット６
pick 793858f コミット２
pick 0bda379 コミット４
pick fe66212 コミット３
pick f357427 コミット５

$ git rebase -i HEAD~5
Successfully rebased and updated refs/heads/master.

kazukoba@KAZUKOBA-PC /D/repositories/rebaseRenshu (master)
$ git lg
*  (HEAD, master) コミット５
*  コミット３
*  コミット４
*  コミット２
*  コミット６
*  最初のコミット

$ git rebase -i HEAD~5

r 8606e6d コミット６
pick 8d516bf コミット２
r 22ce065 コミット４
pick 3e0d15a コミット３
pick 53ed75f コミット５

コミット６

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD^1 ..." to unstage)
#
#	new file:   test6.txt
#

$ git rebase -i HEAD~5
[detached HEAD ce66768] ええと、コミット６だったかな？
 0 files changed
 create mode 100644 test6.txt
[detached HEAD 80155b2] ああ、コミット４だった
 0 files changed
 create mode 100644 test4.txt
Successfully rebased and updated refs/heads/master.

kazukoba@KAZUKOBA-PC /D/repositories/rebaseRenshu (master)
$ git lg
*  (HEAD, master) コミット５
*  コミット３
*  ああ、コミット４だった
*  コミット２
*  ええと、コミット６だったかな？
*  最初のコミット

pick ce66768 ええと、コミット６だったかな？
s 229b58a コミット２
s 80155b2 ああ、コミット４だった
pick 30c30b0 コミット３
f d70be8b コミット５

# This is a combination of 3 commits.
# The first commit's message is:
ええと、コミット６だったかな？

# This is the 2nd commit message:

コミット２

# This is the 3rd commit message:

ああ、コミット４だった

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#	new file:   test2.txt
#	new file:   test4.txt
#	new file:   test6.txt
#

コミット２と４と６をスカッシュ！

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#	new file:   test2.txt
#	new file:   test4.txt
#	new file:   test6.txt
#

$ git rebase -i HEAD~5
[detached HEAD 3c25653] コミット２と４と６をスカッシュ！
 0 files changed
 create mode 100644 test2.txt
 create mode 100644 test4.txt
 create mode 100644 test6.txt
[detached HEAD 713ac69] コミット３
 0 files changed
 create mode 100644 test3.txt
 create mode 100644 test5.txt
Successfully rebased and updated refs/heads/master.

kazukoba@KAZUKOBA-PC /D/repositories/rebaseRenshu (master)
$ git lg
*  (HEAD, master) コミット３
*  コミット２と４と６をスカッシュ！
*  最初のコミット

$ git rebase --onto develop master recover
First, rewinding head to replay your work on top of it...
Applying: 関数一部実装
Using index info to reconstruct a base tree...
M       Main.txt
Falling back to patching base and 3-way merge...
Auto-merging Main.txt
CONFLICT (content): Merge conflict in Main.txt
Failed to merge in the changes.
Patch failed at 0001 関数一部実装

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

pick 793858f コミット２
pick fe66212 コミット３
pick 0bda379 コミット４
pick f357427 コミット５
pick b77dbf0 コミット６

git tag tagname ハッシュ値(たいていは最初の7桁入れれば良いです）

$ git lg
*  (HEAD, master) コミット３
*  コミット２と４と６をスカッシュ！
| *  (old3) コミット５
| *  コミット３
| *  ああ、コミット４だった
| *  コミット２
| *  ええと、コミット６だったかな？
|/
| *  (old2) コミット５
| *  コミット３
| *  コミット４
| *  コミット２
| *  コミット６
|/
| *  (old) コミット６
| *  コミット５
| *  コミット４
| *  コミット３
| *  コミット２
|/
*  最初のコミット

マージを事前に検証したい場合

マージするとどうなるかを確認するには、コミットしない、と言うオプションを指定してマージ（squashではデフォルト）しましょう。 そうすると、マージした結果がワーキングツリーに反映された状態で一時停止するので、そこでdiffをみたり、ソースを確認したり、修正したりします。 コンフリクトの時と同じような感じになります。 ＯＫになったらコミットすればよいし、駄目なら、マージを中止します。 しかしファストフォワード出来る場合、コミットしない、と指定してもファストフォワードされてしまいます。 その場合は次に説明する「コミットの取消し」を行うと元に戻せます。

コミットの取消し

コミット後に取り消すのに一番簡単なのは、gitkのツリーで１つ前のコミットメッセージを選択して右クリックして「xxブランチをここにリセットする」を選ぶ。 コマンドでの実行は、

git reset --hard ORIG_HEAD

元の場所がどこだか分からなくなったら、こちらのコマンドでどうぞ。でも直後じゃないとまずいですよ。 これもリベースと同じで、公開する前のローカルコミットに対してだけにしてくださいね。

競合作業中にこのマージを取り消したくなったら

競合作業中にこのマージを取り消したくなったら、Git Gui で、マージ/マージ中止を選択。 コマンドなら、

git reset --hard HEAD

ORIG_HEADではない点に注意。

普通の使い方

stashは、普通は現在のワーキングツリーとインデックス（ステージング）の状態を一時的に保存しておき、あとで元に戻すときに使います。

例えば、testブランチでの修正がまだ書きかけでコミットできない状態だったとします。そこにリリースバージョンへの緊急の修正依頼が来たとしましょう。もしstashを知らないなら、多分「とりあえずコミット、要修正」の様なメッセージを付けて一旦コミット。 そして別のブランチで作業。 作業終了後、testブランチをチェックアウトしてから元の作業を再開。 きりがいいところでGit Guiの「最新のコミットを訂正」をチェックして、メッセージを修正してからコミットする、といった手順になりますね。 あとでリベースでコミットを整理してもいいですし。

この場合は、別にstashが無くてもなんとかなりますね。これでもいいと思います。 でももし、testの状態が、"一部の修正はaddされていて、もう少し修正してからaddしたい修正があるけど、一緒にコミットしたくない修正もある"、といった場合はどうでしょう？

そんなややこしいことしねえ、もっとスパッといけよ、うじうじするな！という男らしい方には必要ないかもしれませんが、この場合は、次のようにすると、インデックスも復元されるんです。

$ git checkout test
    :
  修正作業や、git add を色々と実施　でもコミットはしない
    :
$ git stash save    -> WorkとIndexがセーブされ、Workの内容はtestの状態になる
$ git checkout 別のブランチ
    :
  修正作業を色々と行ってコミット
    :
$ git checkout test       -> testをチェックアウト
$ git stash pop --index   -> 保存してあった内容をWorkとIndexに戻す

上図中の Work とは、分かっていると思うけど、ワーキングツリーの事です。 長くなるので省略しただけです。 注意点は、--index を指定しないと、インデックスは復元されないと言う点です。つまり、インデックスになにもaddされていない状態で復元されちゃうという事です。 saveのほうには、インデックスを保存するしないのオプションは無い（それともデフォルトでありになっている？）ので、いつでも保存されるみたい。

デフォルトでインデックスが復元されたほうがいい様な気がするけど、いろいろとややこしい大人の事情でインデックスを復元しないのがデフォルトになっているんだと思います。

ワーキングツリーの変更を別のブランチに移動

ところで、Gitを使っててよくやる失敗に、違うブランチをチェックアウトしたまま作業しちゃった、というのがあります。 私もこれ書いてて良くやりました。例えば、こんな感じです。

$ git checkout develop <- 新規開発開始！
   :
新機能開発中　修正、コミット繰り返す
   :
緊急事態発生！リリースへのバグ修正依頼が来たげげげっ！

$ git commit           <-  一旦コミットして作業中断
$ git checkout master  <-  リリースブランチへ移動
   :
緊急対応の修正
   :
$ git commit           <-  終了したのでコミット

ユーザーにいやみを言われつつ、修正版リリース

ふう、ちょっと休憩、コーヒー飲んだり、一服したり

よし、開発再開　ゴリゴリゴリ…

あれれ、何か変だなあ？さっき追加した関数が無い。。。

あっ、やばっ、masterブランチのまま修正しちゃったあ！

正しくは、developをチェックアウトしてから修正しなくてはならなかったんですね。 修正した内容が少ない場合は、手作業でもなんとかなりますが、あっちこっち沢山直した後だと、ちょっとなきたくなりますよね私は泣きました。

ここで登場するのが、stashなんです。 これから説明する事は、よく考えないとこんがらがりますので覚悟してください。

この場合、どう言う操作をすればいいかと言うと、この様にします。

$ git stash save          <- 現在のWorkが保存され、Workはmasterの状態に戻る
$ git checkout develop    <- developをcheckout
$ git stash pop           <- 保存したWorkを戻す

え、こんなに簡単なの！そう、操作は簡単なんですが、実は実際に起きている事は奥が深いのです。例で考えて見ましょう。例えば、修正前のmasterとdevelopの内容が下記の様になっていたとします。

masterブランチ
  lib.bvs
      AAA
      BBB
      CCC
      DDD
  main.vbs
      111
      222
  subA.vbs
      aaa
  subC.vbs
      ccc
  subD.vbs
      ddd
developブランチ
  lib.bvs
      XXX
      BBB
      CCC
      DDD
  main.vbs
      111
      222
  subA.vbs
      aaa
  subB.vbs
      bbb

比較してみると、�@lib.vbsの１行目が違う、�Amain.vbs, subA.vbsは両方にあり、かつ同じ内容、�BmasterにだけsubC.vbs, subD.vbsがある、�CdevelopにだけsubB.vbsがある、と言う状態です。この状態でmasterをチェックアウトして下記の様に修正したとします。

masterをチェックアウトしてワーキングツリー修正
  lib.bvs
      AAA
      BBB
      CCC
      DDD
      abc
  main.vbs
      111
      222
      333
  subA.vbs
      aaa
  subC.vbs
      ccc
      def
  subD.vbs
      ddd

この状態で先ほど説明したとおり（再掲下記）にstasを実行するとどうなるのでしょう？

$ git stash save          <- 現在のWorkが保存され、Workはmasterの状態に戻る
$ git checkout develop    <- developをcheckout
$ git stash pop           <- 保存したWorkを戻す

こうなります。

上記コマンド実行後のワーキングツリーの内容
  lib.bvs
      XXX
      BBB
      CCC
      DDD
      abc
  main.vbs
      111
      222
      333
  subA.vbs
      aaa
  subB.vbs
      bbb
  subC.vbs
      ccc
      def

驚くべき事に、masterブランチのlib.vbsに行ったはずの変更が、developブランチの lib.vbs に反映しているのです！ lib.vbsの一行目をご覧下さい、"XXX"ですよね。 つまりこれは、developブランチにあった方の lib.vbs だと言う事です。 git stash pop は、退避したときの「変更した部分のみ」を、現在のワーキングツリー中のファイルに適用しているって事ですね。 すげえ！しかもこれこそが、今回の、違うブランチで作業してしまったという事態を修復する為に望んでいた動作ですよね？？

次に注目すべき点は、masterブランチには有ってdevelopブランチには無いファイル、subC.vbs と subD.vbs についてです。 subC.vbs はmasterで変更した時の状態で追加されていますが、何も修正していない subD.vbs の方は、developには存在していません。 そして、両方同じ内容だったmasterに行った変更は、そのまま取り込まれています。 最後に、developにしかないファイル subB.vbs はそのまま存在しています。 つまりは、develop上にmasterの内容が上書きされるのではなくて、master上で行った「修正」のみ抽出されて、developに適用されているって事です。

ややこしいですねえ。でも、これで間違って違うブランチで修正してしまった変更を、正しいブランチに適用する事が出来ました。 実際にやってみると、競合が出たりしてもう少しややこしい事が起こるかもしれないですが、git stash popが「修正だけ」を取り込んでくれるので、この様な事が出来るのです。マージともちょっと違いますよね。分かりましたか？

でもただでさえ、こんな具合にややこしいので、インデックスの状態が絡んだりすると、もっとややこしい事になります。 なので、インデックスも含めて別ブランチに復元するなんて事は、私は一生しないと誓います。

新規のファイルを別のブランチに移動

ところで、masterをチェックアウトした状態で新規に作成して、まだインデックスに追加していないファイルはどうなるのでしょう？実は、バージョン管理されていない新規のファイルは、git stashでは（デフォルトでは）セーブされません。また、チェックアウトで消去されるわけでもないので、先ほどの操作をすると、masterからdevelopに移動したのと同じ事になります。しかし、同じ名前のファイルが既にdevelopに有るときは、チェックアウト時にエラーになるので気がつきますね。その場合は、勝手にどうにかしてください。

git show

コミットの情報を取得する、git show コマンドを見てみましょう。 git showとは、gitk のツリーの下に出ている情報を表示するコマンドです。 今私、テスト用リポジトリを作りました。そしてそこに、file1.txt と file2.txt を作り一旦コミットし、file1.txt を lib/file1.txt に移動し、file2.txt を file3.txt に改名してコミットしました。ここでgit showすると、

$ git show
commit 8e4f8dd1b35081fd3c4cfe4318c755571005399d
Author: kkoba 
Date:   Thu Sep 13 14:27:10 2012 +0900

    移動と改名

diff --git a/file1.txt b/file1.txt
deleted file mode 100644
index 88654a7..0000000
--- a/file1.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-AA
-BB
-CC
diff --git a/file2.txt b/file2.txt
deleted file mode 100644
index 7dd152a..0000000
--- a/file2.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-aa
-bb
-cc
diff --git a/file3.txt b/file3.txt
new file mode 100644
index 0000000..7dd152a
--- /dev/null
+++ b/file3.txt
@@ -0,0 +1,9 @@
+aa
+bb
+cc
diff --git a/lib/file1.txt b/lib/file1.txt
new file mode 100644
index 0000000..88654a7
--- /dev/null
+++ b/lib/file1.txt
@@ -0,0 +1,8 @@
+AA
+BB
+CC

ちょっと見にくいかもしれないですが、要するに、file1.txtとfile2.txtが無くなって、file3.txtとlib/file1.txtが新規に出来ました、って言っているんです。

git show の -M オプション

で、これに -M オプションを付けて実行します。すると、

$ git show -M
commit 8e4f8dd1b35081fd3c4cfe4318c755571005399d
Author: kkoba 
Date:   Thu Sep 13 14:27:10 2012 +0900

    移動と改名

diff --git a/file2.txt b/file3.txt
similarity index 100%
rename from file2.txt
rename to file3.txt
diff --git a/file1.txt b/lib/file1.txt
similarity index 100%
rename from file1.txt
rename to lib/file1.txt

おお、なんと、改名も移動も見つけてくれています。すごいですね。 ファイル名変えただけで何も修正していないので、diff にはなにも出力されていません。 TortowiseGitの、「以前のバージョンとの差分」が、この git show -M を実行しているみたいです。 でもこの -M オプション、なんでgit showのヘルプに無いんだろう？ 探し方が悪いのかな？ 私はこれを「入門Git」で知りました。

-M オプションは、git diff にも使えます。 git diff HEAD~ -M とすると、先ほどのgit show -M のdiffの部分が表示されます。

blame

まずは、blameについて説明します。 blameとは、ある行の変更がどのコミットで行われているかを教えてくれるコマンドです。 今私が説明用に作ったリポジトリのコミット履歴を見てください。

$ git log --oneline
25996de コメント入れて、一部修正
d62efd9 改行減らした
a8d9f9b メインの記述追加、メソッド名修正
38958a1 メソッド追加
2a51f24 Main.bvs 追加

で、Main.vbsをblameしてみます。

$ git blame Main.vbs
25996de6 (kkoba 2012-09-14 10:43:03 +0900  1) ' ファイルコピーツール
2a51f244 (kkoba 2012-09-14 10:17:05 +0900  2) public sub Main
2a51f244 (kkoba 2012-09-14 10:17:05 +0900  3)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900  4)   OpenFile
25996de6 (kkoba 2012-09-14 10:43:03 +0900  5)
25996de6 (kkoba 2012-09-14 10:43:03 +0900  6)   Do Until eof
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900  7)           ReadLine
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900  8)           WriteLine
25996de6 (kkoba 2012-09-14 10:43:03 +0900  9)     Loop
25996de6 (kkoba 2012-09-14 10:43:03 +0900 10)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 11)   CloseFile
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 12)
38958a18 (kkoba 2012-09-14 10:18:04 +0900 13) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 14)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 15) public sub ReadLine
38958a18 (kkoba 2012-09-14 10:18:04 +0900 16) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 17)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 18) public sub OpenFile
38958a18 (kkoba 2012-09-14 10:18:04 +0900 19) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 20)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 21) public sub CloseFile
38958a18 (kkoba 2012-09-14 10:18:04 +0900 22) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 23)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 24) public sub WriteLine
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 25) end sub

一番左の１６進がコミットのＩＤです。 コミットした人の ID も出ていますね、これなら、誰が変更したのかはすぐ分かる。 例えば１行目の「’ファイルコピーツール」と言う行は、kkobaが直していて、先ほどのログと比べると、「コメント入れて、一部修正」と言うコミットで修正された、と言う事が分かります。 その他の行も見てみてください。 どのコミットで修正されたのかが分かりますよね。 でも、こんなふうに目視では調べたくないなあ。

どんなときに使うのかと言うと、あるバグの原因が特定の行だったとします。 blameを使うと、その行を今の状態にしたのはどのコミットで、誰なのかがわかるんです。 犯人探しの為のコマンド？確かに blame の意味は、「過失を非難し、責任を問う」と言う意味ですから。

Git Gui上では「リポジトリ/ブランチXXXのファイルを見る」で、ファイルの一覧を表示させて、それをダブルクリックすると blame が GUI で表示されます。 でも、いまいちどころか、なんか作りかけみたいで、使う気になりません。 将来に期待、していいのでしょうか？ このコマンドはとてもすばらしいと思うので、だれかいいＧＵＩ作りません？え、お前がやれって！考えて見ますね。

ところで、一行目の「’ファイルコピーツール」と言う全角がちゃんと表示されているのは、utf-8で保存したからです。shift-jisだと、変な表示になりますよ。

blameのオプション -M

この節の本来の目的は、ファイル内の一部を移動した場合の追跡でしたね。 では、ちょっとサブルーチンの順番を変えてみますね。

$ git log --oneline
b9a36e2 サブルーチンの位置を移動
25996de コメント入れて、一部修正
d62efd9 改行減らした
a8d9f9b メインの記述追加、メソッド名修正
38958a1 メソッド追加
2a51f24 Main.bvs 追加

$ git blame Main.vbs
25996de6 (kkoba 2012-09-14 10:43:03 +0900  1) ' ファイルコピーツール
2a51f244 (kkoba 2012-09-14 10:17:05 +0900  2) public sub Main
2a51f244 (kkoba 2012-09-14 10:17:05 +0900  3)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900  4)   OpenFile
25996de6 (kkoba 2012-09-14 10:43:03 +0900  5)
25996de6 (kkoba 2012-09-14 10:43:03 +0900  6)   Do Until eof
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900  7)           ReadLine
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900  8)           WriteLine
25996de6 (kkoba 2012-09-14 10:43:03 +0900  9)     Loop
25996de6 (kkoba 2012-09-14 10:43:03 +0900 10)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 11)   CloseFile
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 12)
38958a18 (kkoba 2012-09-14 10:18:04 +0900 13) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 14)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 15) public sub OpenFile
38958a18 (kkoba 2012-09-14 10:18:04 +0900 16) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 17)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 18) public sub CloseFile
38958a18 (kkoba 2012-09-14 10:18:04 +0900 19) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 20)
b9a36e2e (kkoba 2012-09-14 11:55:48 +0900 21) public sub ReadLine
b9a36e2e (kkoba 2012-09-14 11:55:48 +0900 22) end sub
b9a36e2e (kkoba 2012-09-14 11:55:48 +0900 23)
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 24) public sub WriteLine
a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 25) end sub

ReadLineをCloseFileの下に移動しました。 移動したReadLineの行のＩＤは、b9a36e2e と、最新のコミット「サブルーチンの位置を移動」となっています。 では今度は -M オプションを付けて実行してみます。

$ git blame -M Main.vbs

   :  -M 無しと同じなので省略

a8d9f9b1 (kkoba 2012-09-14 10:20:24 +0900 21) public sub ReadLine
38958a18 (kkoba 2012-09-14 10:18:04 +0900 22) end sub
38958a18 (kkoba 2012-09-14 10:18:04 +0900 23)

   :  -M 無しと同じなので省略

-M 無しの場合と違うところだけ表示しました。 おお！21行目の、public sub ReadLine の行は、「メインの記述追加、メソッド名修正」で修正されたと言っています！ 移動前にblameしたときと比べて下さい。同じコミットを指しています。 つまり、移動は無視して、本当に変更されたコミットを見つけてくれたって事ですね。 すごくないですか？

-M とは、同じファイル内の移動を検出してくれるオプションでした。

blameのオプション -C

ではもう一つのすごいオプション、-C を説明しますね。 これはとても奥が深い、と言うか、ややこしいオプションです。 -M はファイル内の移動を検出してくれますが、-C は、違うファイルからの移動も検出してくれるオプションです。

今の状態で git blame -C Main.vbs とすると、-M オプションと同じ結果が出力されます。 では、Main 以外のメソッドを、Lib.vbs に移動してみます。

$ git log --oneline
3b2f30b サブメソッドをLibに移動
b9a36e2 サブルーチンの位置を移動
25996de コメント入れて、一部修正
d62efd9 改行減らした
a8d9f9b メインの記述追加、メソッド名修正
38958a1 メソッド追加
2a51f24 Main.bvs 追加

$ git blame -C Lib.vbs
3b2f30b2 Lib.vbs  (kkoba 2012-09-14 12:30:02 +0900  1) 'ライブラリ
a8d9f9b1 Main.vbs (kkoba 2012-09-14 10:20:24 +0900  2) public sub OpenFile
38958a18 Main.vbs (kkoba 2012-09-14 10:18:04 +0900  3) end sub
38958a18 Main.vbs (kkoba 2012-09-14 10:18:04 +0900  4)
a8d9f9b1 Main.vbs (kkoba 2012-09-14 10:20:24 +0900  5) public sub CloseFile
38958a18 Main.vbs (kkoba 2012-09-14 10:18:04 +0900  6) end sub
38958a18 Main.vbs (kkoba 2012-09-14 10:18:04 +0900  7)
a8d9f9b1 Main.vbs (kkoba 2012-09-14 10:20:24 +0900  8) public sub ReadLine
38958a18 Main.vbs (kkoba 2012-09-14 10:18:04 +0900  9) end sub
38958a18 Main.vbs (kkoba 2012-09-14 10:18:04 +0900 10)
a8d9f9b1 Main.vbs (kkoba 2012-09-14 10:20:24 +0900 11) public sub WriteLine
a8d9f9b1 Main.vbs (kkoba 2012-09-14 10:20:24 +0900 12) end sub

おおお、すごい！ちゃんと最後に編集されたコミットを指している！ しかもその時にどのファイルに書かれていたかも分かります。

このオプションは１回、２回、もしくは３回指定する事が出来ます。git blame -C -C Lib.vbs とか、git blame -C -C -C Lib.vbsとか。 １回の時は、「同じコミット内での変更の中から検索」、つまり、同じコミットで削除して追加した場合ですね。 ２回の時は、「同じコミット内での他のファイルの中からも検索」、つまり、多分ですが、コピーして追加したけど、削除していなくても見つけてくれる、って事だと思います。 そして３回の時は、全部のコミットから探してくれる、見たいな事が書いてありますが、正直よく分からん。 誰か教えて。

ところで、この -C も -M も、-C5 -M4 の様に、数字を付けて指定できます。 この数字の意味が良くわからないんですが、何か検索するときの文字数の制約みたいです。 なんだろう？ この数字を -C を複数つけるときは、最後のに付けてね、って書いてありました。

今やったコミットを修正したい

これは簡単、Git Gui で、「最新コミットを訂正」をチェックすると、インデックスとメッセージがコミット前の状態で表示されます。それからは、いつもと一緒で、ファイルを修正するらな修正して、メッセージ直すなら直して、今度は慎重にコミットすればいいんです。 この操作は、前のコミットを修正するわけではなくて、新しいコミットを作るので、公開した後でやったら駄目ですよ。 リベースと同じですね。どんな場合にもGitは一度作ったコミットを絶対変更したりはしません。新たに作るだけです。

違うブランチで沢山作業しちゃった

よくある事です。 もしコミットしていないなら、ワーキングツリーの変更を別のブランチに移動を見てください。

もし何回かコミットしてしまっていたら、一旦今の位置に、'recover' みたいなブランチを作っておいて、gitk か、コマンドなら

git reset --hard 元の位置

とやって、間違えてコミットしちゃったブランチを元の位置に戻す。 もともと、そこからブランチ作って作業しようとしていたなら、そのまま作業続行でＯＫです。 別のブランチにいくのなら、リベースに　--onto オプション付けて実行。え、わかんない？じゃあちょっと詳しく説明しますね。 たとえば、

  �@ -- �A -- �C  <-- *master
         ＼
           �B -- �D <-- develop

この状態で、ほんとはdevelopチェックアウトしてから
開発しようと思っていたのに、間違って

  �@ -- �A -- �C -- �E -- �F <-- *master
         ＼
           �B -- �D <-- develop

としちゃった！

こんな状態に陥ったとします。 このとき、まず recover ブランチ(何でもいいですよ)を作って、次のような状態にします。

  �@ -- �A -- �C -- �E -- �F <-- *master recover
         ＼
           �B -- �D <-- develop

コマンドなら、git branch recover です。 recoverはチェックアウトしません。 もししちゃったら、masterをチェックアウトし直して下さい。

それから、masterの位置を、元に戻します。 どこが元のマスタだったかは、コミットメッセージを眺めれば分かりますよね。 落ち着いて調べてください。 masterの位置を元に戻す操作で一番簡単なのは、gitkを使う方法です。 グラフ上で、そこに戻したいコミットのメッセージのところをクリックしてから、右クリックして「masterブランチをここにリセットする」を選んでください。 ダイアログが出て、soft , mixed , hard を選択するのですが、これは、ワーキングツリーとインデックスをどうするかの指定です。 ワーキングツリーにまだコミットしていない変更があるときは、soft にすると、そのままにしてくれますが、hard にすると、リセット先のコミットの内容に置き換えられます。 mixed は、インデックスのみリセットされます。 でもこの操作する時はややこしいから、全部コミットしておいたほうがいいんじゃあないかなあ（私がまだ soft と mixed の動作を完全に把握していないから自信が無いんです。）

masterを�Cにリセットしたとするとこうなります。

                 �E -- �F  <-- recover
               ／
  �@ -- �A -- �C  <-- *master
         ＼
           �B -- �D <-- develop

そして次がややこしいのですが、

$ git rebase --onto develop master recover

とします。すると、こうなります。

  �@ -- �A -- �C  <-- *master
         ＼
           �B -- �D <-- develop
                  ＼
                   �E -- �F  <-- recover

なんだなんだ？ このコマンドの意味は、recover ブランチを、 --onto の次に書いてあるdevelopブランチから分岐するように変更しなさい。 recoverの今の分岐場所は、masterとの共通の祖先（この場合は�C）です。という指示です。 ややこしいので、1回練習しておくといいでしょう。 このコマンドは、下記の状態の場合にも使えます。

                 �E -- �F  <-- recover
               ／
  �@ -- �A -- �C -- �G  <-- *master
         ＼
           �B -- �D <-- develop

前と比べて、コミット�Gが増えています。この場合も前と全く同じ

$ git rebase --onto develop master recover

で、こうなります。

  �@ -- �A -- �C -- �G <-- *master
         ＼
           �B -- �D <-- develop
                  ＼
                   �E -- �F  <-- recover

「recoverの今の分岐場所は、masterとの共通の祖先だ」とはそういう意味です。 で、この後、recoverを、developにFast-forwardでマージして、recover を削除すれば一丁上がり！

へんなコミットが出来ちゃった、人に見せたくないなあ

コミットの整理を見てください。

stash save したんだけど、pop しないで消しちゃった！

stash save は、ワーキングツリーとインデックスを保存する仕組みですが、実はこれも内部的にはコミットとして保存されています。 stash save した後に、gitk で見てみると良くわかりますよ、グラフ上に表示されますから。 インデックスと、ワーキングツリー(コミットメッセージではWIP(Work in process)と言ってますね。もう、いろいろな言い方やめようよぉ）がコミットとして保存されているのが分かります。

もし git stash save した変更を、git sash pop しないで git stash clear しちゃうと、ワーキングツリーに今までやった変更がどこにもなくなったように見えます。

でも大丈夫、git gc さえしていなければ、コミット自体は残っているのです。 ただ stash は使い終わるとどこからも参照されていないので見えなくなっちゃうんです。 そんなときに活躍するのが、git fsck。fsck は、file system consistency check の略らしいです。 git fsck すると、どこからも参照されていないオブジェクトの一覧が表示されます。 その中からそれらしい commit オブジェクトを見つけて、それをチェックアウトして、とりあえずブランチ付けちゃいましょう。 コミットメッセージに、ワーキングツリーがあったブランチの直前のコミット名がついてますから、git show で内容見ながら探せば、割と簡単に見つかるでしょう。

そうしておいて、中身を確認して、「あ、これだ！」となったら、適用したいブランチをチェックアウトしてから、そいつをチェリーピックすればいいんです。

masterブランチ

今度はブランチです。 最低限必要なのは、masterブランチ一つですね。これは絶対に必要です。 別に名前はmasterでなくてもいいのですが、みんなmasterにしているし、Gitでも特別扱いされているので、masterでいいでしょう。 masterブランチは、ずっと存在し続ける（途中で削除されない）、「永続ブランチ」のひとつです。

次に、このmasterブランチをどんなふうに使うのかを決めましょう。 masterは、このプロジェクトの安定版を、きれいなコミット履歴とともに記録するブランチと決めましょう。 バージョン番号のタグをつけるときは、このブランチにつけることになります。

開発の開始から、masterブランチへのマージまでの流れ

次に、プログラムを修正するときに、どのようにブランチを作って、どのようにテストして、最終的にどのようにmasterにマージするのかと言う流れを考えて見ましょう。

リモートリポジトリ
   �@ -- �A -- �B  <- master

ローカルリポジトリ
   �@ -- �A -- �C  <- master

上記の状態で普通にプルすると
            ------�B        <- origin/master
          ／        ＼
   �@ -- �A -- �C -- �D     <- master

と、�Dのマージコミットが出来てしまう。
なので、いったん

ローカルリポジトリ
   �@ -- �A        <- master
          ＼
            �C     <- test

としてからプルすると、

ローカルリポジトリ
   �@ -- �A -- �B  <- master  origin/master
          ＼
            �C     <- test

となるので、それから適切な処理を行う

マージ後の状態と再テスト

マージの結果の状態と、マージ後に再テストが必要かどうかについて考えて見ます。 この件に関してなぜかネット上にはあまり情報が無いですねえ。 何か私が勘違いしていなければいいのですが。。。

トピックブランチをmasterブランチにマージするとして、その結果は下記パターンが考えられます。

1. トピックブランチとmasterブランチが同じ（ファストフォワードされた）
2. トピックブランチとmasterブランチが異なる
   1. 異なるファイルの変更がった（同じファイルの変更は無い）
   2. 同じファイルの変更があった
   3. 競合があり修正した

この中で、マージ後に再テストしなくていいのはどれでしょう？ 正解は「1.トピックブランチとmasterブランチが同じ（ファストフォワードされた）」だけですよね。 プッシュする時に（デフォルトでは）ファストフォワードしか許可していないのは、再テストが必要になるマージを別のリポジトリ上に対して行うとまずいからですね。テストが必要なマージは、ローカル側でテストまで済ましてから送れって事ですね。

2.2 と、2.3は、ソースが変更されちゃうのですから、もう完全にテストが必要なのがわかりますが、2.1は状況によりますね。 同じコンパイル単位でなく、お互いに参照していないものであれば、もう１回テストする必要は無いですよね、多分。 2.1の場合は、明らかにテストが不要だと分かる場合は省略できる、と言うルールでいいかもしれないですね、ただし、状態が「2.1」だ、って事が分かれば、ですが。

で、マージ後に結果が上記のどれに当たるのか、どうやって確認したら良いのでしょう？ マージ後にトピックブランチとmasterを git diff で比較して相違が無ければ「1.」にあたるのは分かります。 でもそれ以外の場合どれに当たるのかを簡単には識別できなそうです。 masterとmaster~を比較したdiffと、トピックブランチとmasterを比較したdiffを取って、変更があったファイルを比較する、とかすれば出来そうですが、 凝ったスクリプトを作らないと駄目かなあ、だれか教えて下さい。

どちらにしても、テストは出来るかぎり自動化しておいた方がいいですね。 例えば上記の「1.」以外では、master側の修正に関するテストと、トピックブランチ側の修正に関するテストを両方やらないといけないですよね。 前と同じテストをまた手動でやるっていうのは、うんざりです。

業務アプリケーションについて考えてみる

  root\
    |-- Lib\
    |     |-- Common
    |     |      |-- DB.vb
    |     |      |-- Login.vb
    |     |             :
    |     |-- Masters
    |            |-- MasterA.vb
    |            |-- MasterB.vb
    |                    :
    |-- Main
    |     |--Project1
    |     |     |-- Main.vb
    |     |     |-- Form1.vb
    |     |            :
    |     |--Project2
    |     |     |-- Main.vb
    |     |     |-- Form1.vb
    |     |            :
    |     |--Project3
    |     |     |-- Main.vb
    |     |     |-- Form1.vb
    |     |            :
    |       :
    |-- sql
    |     |--CreateTableA.sql
    |     |--CreateTableB.sql
    |     |--AlterTableA.sql
    |         :
    |-- release
           |--Common.dll
           |--Masters.dll
           |--Project1.exe
           |--Project2.exe
           |--Project3.exe
             :

ブランチ名の付け方

ブランチ名は、分かりやすい名前を付けましょう。 また、複数の人の間でブランチをやり取りする場合は、kkoba/AddSearchFunc の様に、先頭に自分のＩＤを付けておくと、分かりやすいですね。 "/"で区切っておくと、それは名前空間となり、あとで kkoba/* と言った形式で検索できます。 ブランチ情報（と言ってもコミットの参照ですが）を記録するファイルは、ブランチ名を"/"で区切ると、refs/heads/kkoba/AddSearchFunc　の様にkkobaと言うフォルダが出来て、その下に保存されます。