担当者用ブランチを master にマージする 
マージとは
マージとは、枝分かれした二つのコミット(バージョン)を一つに統合することである。
担当者用ブランチを選択した状態で master とマージすることと、
master ブランチを選択した状態で担当者用ブランチとマージすることとは、
少し結果が違う。
ここでは担当者用ブランチを選択した状態で master ブランチとマージする。
樹形図で、レ点が付いてるアイコンが、現在選択しているブランチを表している。
suzuki ブランチ以外のブランチを削除したのであれば、常に suzuki ブランチにレ点が付いているはずである。
（過去のバージョンに戻したりした場合を除く）
マージの種類
マージするとき、競合が起きる場合と、競合がない場合の区別を意識すること。
競合とは、同じファイルに同時に変更が加えられたため、一つに統合できない状態を指す。以下、suzuki ブランチ（origin/suzukiではなく）と origin/master ブランチの関係に注目。
以下は suzuki と origin/master とが分岐していて、どちらも変更されているので競合が起こりうる。樹形図が Y 字に分岐した形になっている。
以下は Y字になっていない。origin/master よりも suzuki が先行しているだけである。言い換えると、前回マージしてから、origin/master は変更されていない。
以下は一度もマージしていない場合で、競合が起きる可能性がある。これもY字と同様と考えると良い。
マージの実行
master ブランチとマージするには、以下の操作をする。
- 樹形図で「origin/master」と示されている行を右クリックする。
- ポップアップメニューから「マージ...」を選択する。
- 「OK」をクリックする。
樹形図がY字になっていなければ、実はマージは必要ない。
既にマージされている状態であり、何も起きないが、念のため確認することができる。
樹形図がY字になっていても、GIT が自動的にマージを行い、競合が解決されることがある。
以下の様に Merge remote-tracking branch 'origin/master' into suzuki と表示されるとマージ成功である。
競合が解決できないと、以下のポップアップが表示される。
競合の解決方法は別ページで解説する。競合の解決を参照。
なおマージ操作の途中で、まだマージ中なのにあたかもマージが完了したようになってしまったら、
マージのリセットを参考にマージをリセットしよう。
マージ結果の確認
競合した状態でマージしても、GITが自動的にマージして競合が解決されることがある。
例えば master で新しいファイルが追加され、suzuki ブランチでも別の新しいファイルが追加された場合。
このようにファイルが異なれば、単に両方のファイルが追加された状態になるだけで、競合しない。
さらに、同じファイルを同時に変更した場合ですら、変更箇所が離れていれば GIT が自動的に混ぜ合わせてしまう。
プログラムやテキストファイルなら、これで期待通りにうまくマージされることもある。
しかしバイナリファイルや、それに近い性格のファイルだと、自動的にマージされるとかえって無茶苦茶になる場合もある。
ワープロのファイルなどでは、自動的なマージはあまり期待できない。
SourceTree の画面で、変更されたファイルを選択すると、前のバージョンとの差異が表示されるので、参考にしよう。
ワープロのファイルなどは開いて確認が必要な場合もあるだろう。
マージ結果のプッシュ
マージしたら、忘れずにすぐにリモートリポジトリにプッシュしよう。
リモートリポジトリにプッシュしないと、鈴木さんがmasterとマージしようとしていることが他の人から見えない。
マージした後にプッシュすると「いま、やってるよ〜」的な主張にもなる。
先ほどマージ作業をしたのはあくまで suzuki ブランチであることに注意しよう。
master ブランチは何ら変更を加えていない。
suzuki ブランチを変更していいのは鈴木さんだけである（※）から、
suzuki ブランチの変更をプッシュしても競合は起きないはずである。
※：想定シナリオの運用ルール参照
コメントをかく