導入
Gitはとても便利なツールです。ですが、「これをやったら無意味だろ」「せっかくのGitが台無し」「むしろ開発の妨げ」的なこともいくつか存在します。ここではそんな「べからず」集の一部をご紹介します。
ケース１：ブランチを使わない
- 深刻度：論外
- 修正難易度：とても易しい
- それ、SVNでやりなよ度：最大
- コメント：トップバッターがいきなりアレですが、要はブランチを使いましょうということです。Gitの特徴としてマージが比較的容易であるという点が挙げられます。じゃんじゃんブランチを作り、マージしましょう。
ケース２：ブランチ名がhogeやBug fixだらけ
- 深刻度：中
- 修正難易度：易しい
- 身にしみる度：中
- コメント：ブランチを作るのはいいのですが、ブランチ名にも変数名と同じく気を遣いましょう（変数名、気をつけてますよね？）。当たり前ですが、同じ名前のブランチを複数作ることはできません。まあ、
hogeなんていうブランチを作る人はさすがにいないと思いますが（いないよね？）、Bug fixやFix bug、Fixあたりをブランチ名にしてる人は気をつけてください。他の人も同じようにした場合、中央レポジトリ上で問題が発生する可能性が高いです。ブランチの内容をより詳細に説明するようなブランチ名にしましょう（例：fix_user_migration）。
ケース３：プッシュ済みコミットをrebaseする
- 深刻度：高
- 修正難易度：高（
reflogを使うとrebaseをやり直せるが面倒） - みんなに嫌われる度：高
- コメント：これはやりがちです。Gitにおける
rebaseは、mergeと違ってコミットのハッシュ値を変更してしまいます。そのため、全く同じ内容のコミットが、プッシュ先とローカルで異なるものとみなされてしまうのです。その結果、一度プルしたにもかかわらず新規コミットが大量にあると思ったらハッシュ値が変わっただけだった、という事態が発生します。他の開発者は余計なマージを行わなくてはなりません。
ケース４：masterブランチにフォースプッシュ
- 深刻度：最大
- 修正難易度：最大
- 二日酔いもぶっ飛ぶ度：最大
- コメント：
git push --forceコマンドを使うと、リモートのコミットを上書きできます。トピックブランチの場合はそれでもいいのですが、前述の例のようにした場合、設定によっては全ブランチがフォースプッシュされます。たまたまその時、masterブランチを手元でgit commit --amendしていたら…さらに自動デプロイがされていたら…恐ろしいですね。Git2.0からはデフォルト設定が変更され、上記のようなことは起こりにくくなっていますが、それでも十分に気をつけましょう。
ケース５：多すぎるマージコミット
- 深刻度：低
- 修正難易度：中
- 綺麗好きにはつらい度：高
- コメント：トピックブランチをつくったあと、本流のブランチとコンフリクトが発生してしまうことがあります。そうなると
rebaseかmergeをするのですが、すでに共有済みのブランチではrebaseはできないので（ケース３参照）、mergeをすることになります。マージコミットは通常のコミットと同様にlogに現れるので（一応git log --no-mergeで回避可能だが、GitHub等では回避不能）、あまりたくさんやると肝心のブランチの内容が見えづらくなることがあります。本流にマージする前に、トピックブランチのマージコミットをrebaseで削除してから（どうせマージしてから削除するので問題ない）最後に一つだけマージコミットを作成すると上手に決まります。そのためのrerereというツールもあります（詳しくはgit rerereで検索）。
まとめ
ここに挙げたのはべからず集のほんの一部に過ぎません。現場でここに書かれていないとんでもないGitの使い方に出会った人がいましたら、コメントで教えてください。