VSS や TFS 利用者が間違えやすい Git 用語

MS 系の開発をしているのであれば、ソース管理といえば現在は TFS が主流かもしれないが、VSS も未だに残っていたりする。そんな現場が Git を使いはじめると、たいてい失敗する。それは、仕組みそのものが全く違うにもかかわらず感覚で使おうとするからだ（Git そのものがダメなわけではない）。
Git は高度なことも可能だが、最低限以下を抑えれば、それほど問題にはならないはず。

Git のコミット

Git のイメージ

1. Git では、コミットは「ローカル」のリポジトリに対して行う。
2. 他の人が修正内容を取れるようにするためには「プッシュ」を行う。
3. 他の人のソースを取りたいときは「プル」を行う。

注意しなければならないのは、競合が発生した場合はプッシュやプルができない。ただ、ビルドエラーは起こっても大丈夫だったりするw

リベースとマージ

修正内容を反映させたいときに出てくるのが、リベースという単語。よく聞きなれたマージという言葉もあり、結果そのものは同じことになるので違いは何だろうと思ってしまうのだが、実はわりと別のことだったりする。

リベース

対象となる修正内容を飲み込んで取り込む。

マージ

対象となる修正内容の差分のみ取り込む。

わかりづらい部分だが、上記の例だと、左側の青い丸がリベースを繰り返した場合。マージを行うと、赤紫の変更分が develop に取り込まれ、新しくマージコミットが作られた後、master に統合されている。
マージを繰り返すと、マージされたそれ自体がどんどん蓄積されていくので枝が広がっていきわかりづらくなっていく（逆に細かい変更を指定しながらリリース・ブランチを作りたいときなどは便利）。
リベースを繰り返すのは、TFS などに近い動きになる。

スタッシュ

TFS でいうところのシェルブである。スタッシュを行うと変更点がすべて退避され、変更前の状態に戻る。
SourceTree だと、なぜか新しく追加したファイルが差分として残ってしまう…。

ルール作りが必要

Git のソース管理は、チーム内で一定のルール作りをしてから初めないと、失敗する気がする。ここで言う失敗というのはデグレも含まれるので注意が必要ではないかと思っている。
TFS などはそういう細かいこと（ブランチがグチャグチャになっても）はどうでもいいので、とにかくソースを安全に保管できるように設計されているのかな、という印象。