いまあなたはSubversionの管理者で、日々の開発案件で、Subversionに特に大きな不満は持っていない、上手く言っていると思っている。ただ、世間ではGitという名前が聞こえてくる、多分ソース管理の仕組みなんてそんなに変わらないし、必要になったら勉強しよう、と考えている。

そういう管理者がいざ急にGitでのソース管理になり、開発メンバーは全てGitは初めて使う、というプロジェクトは恐らく悲惨な結果を招きます。GitはSubversionとは異なることを管理者はまざまざと見せつけられ、あるものはGitを使うことを怖がり逃げてしまい、あるものは、これを期にようやく真剣に学び始めます。

学習するものはネットで検索をし、少しずつ学んでいくが実際に現場でGitに挑むと、様々な想定外の経験をすると思います。

ここでは、その初めてのGit管理者に少しでも参考になる事前実施事項を挙げています。

Pull, Fetch, Pushの概念を教える

初めてGitを使用する人が最初につまずくのが、Pull等をしないで、Pushをしようとして、Pushができないという事象です。
Gitを長く使っている人は当たり前でも初心者は最初につまずきます。

Rebase, Merge (ff, no-ff)の理解と、コンフリクト時の操作を教える

これも同様につまずくポイントで、特に初心者はRebaseのことをあまり分からず何でもMergeをする、こうなるとコミット・ツリーは意味のない枝ばかりになります。

改行コードを統一する

特にWindows環境の場合は特に重要で、改行コードはUnix系のLFに統一するような設定をすべきです。

分かりやすいブランチ・モデルを選択する

a successful git branching model (日本語訳) というブランチ・モデルが非常に有名になり、特にGitの初心者はこれをネット検索で引っかかりやすいため、まず最初に「これこそ実績のあるブランチ・モデルだ！」と盲目に受け入れてしまいます。
ところが、この有名なブランチ・モデルは初心者が始めるにはリッチすぎて、多分すぐに行き詰まると思います。Git Flowはその価値をメンバーが十分に認識できるのであれば採用すればよいと思いますが、そうでないならば、もっとシンプルな戦略を取るべきでしょう。
とにかく最初はシンプルに始め、徐々に課題が出てきたら、様々なブランチ戦略を試すのがよいです。(最初はmasterだけでもよいと思います)

良い管理ツールを使用する

あなたがGitHubを使用したことがあれば、この意味が分かるとは思うが、GitはGitHubのようなツールと一緒に使うことが望ましいです。

ブランチはいつでも作れ、いつでも消せる (もちろんちゃんとしたコントロール配下で)
Pull Request/Merge Requestのようなマージをコントロールするワークフローが備わっている
ソース等にコメントができる
チケットと連動ができる

など。
Gitを使用する場合は、ツールも一緒に検討しましょう。

EclipseのGitマージツールを使用しない

これは私が経験したことです。
Git管理者から「マージが失敗して、全ファイルに差分がでてしまいました」という悲痛な連絡がありました。
Eclipseでマージ・コミットの確認をすると、コミットしているのは、数ファイルで問題がないのに、なんとGitコマンドで確認すると、すべてのファイルが改行コードが変わってコミットされていました。
その管理者はEclipseのみで確認していたので、そのままPushをしてしまいました。
なんという恐ろしいことと思いますが、これは実際に起こったことです。ひょっとすると、いまはもうEclipse (JGit)側で修正されているかもしれないですが、もう恐ろしくてEclipseのGitツールはAddくらいしか使用しないルールにしました。

まとめ

以上が私が経験した中ので、ソース管理者へのTipsです。参考になれば。

Hirofumi Arimoto

Java, Scala, JavaScriptや、機械学習に興味あり
実際の開発での知見を可能な限り記事にしたいと思っている