バージョン管理
コンパイルエラーコミット
基本的にコンパイルエラーが出た状態でコミットすることはしてはいけない。
機能が分化されていたとしても、コンパイルエラーが出ていると他のメンバーの作業に影響がでるからです。
意識して、あるいは、無意識にコンパイルエラーをコミットするケースがあります。
意識してコミットしなければいけない場合は、必ずメンバーに周知しましょう。この際は、理由や完了予定時刻も周知しましょう。
意識的なコンパイルエラーコミット
- 影響範囲が広い機能を修正した。
- O/Rマッパーの使用時に影響範囲の広いエンティティの変更をした。
無意識のコンパイルエラーコミット
- コミット漏れがあった。自身の環境ではコンパイルが通っているので、気づかなかった。
- subversionのexternalsを使用していて、内包されているパッケージから内包している側のクラス呼び出しをしてしまった。
- ソースコードの修正を行ったが、別プロジェクトとなっているtestパッケージに修正を行わなかった。
上記のような理由でコンパイルエラーコミットがなされる場合があるが、気がついたら互いに教え合える環境を作ることも重要である。
また、HudsonなどContinuous Integrationを使用し、エラーに目を光らせておくことは効果的である。
コミットコメント
TracやRedmineなどBTSとチケット連携しているような場合も含め、コミットコメントの重要性をきちんとメンバーが認識し、プロジェクト内に一定のルールを作るべきです。
コミットコメントをつけることにより、誰がどういう意図でソースコードを編集したかがわかり、コンフリクトの発生時やタグを切る際に非常に有用な情報となります。
コミットコメントがかかれていない場合、変更の意図をソースの差分から追わなければいけなくなります。
コミットコメントで書くべきこと
- なぜその問題の解決が必要だったのかの簡単な説明
- 影響範囲
- 削除したものがあれば、その説明
- 他の関連するリビジョンやタグへの参照
- TracやRedmineを連携している場合、チケット番号
- 簡潔に書くこと
コンフリクト(競合)
同一ファイルの同一箇所で競合が発生する例として下記が考えられる。
競合の例
- 2人の開発者が同時にバグを発見し、両者がともに修正を行った。
- 2人が追加しようとしている機能で共通のクラスが使われていて、両者がともにフィールドを追加した。
競合による弊害として、手動のマージ作業が発生し開発効率は悪くなること、手動マージのミスによるデグレがある。
また、バージョン管理ツールの知識が低いメンバーがいる場合、競合について教育しておかないとオーバーライドしてしまう可能性もある。
上記の問題の根本的な要因は、コミュニケーションの問題であることが多い。
プロジェクトの立ち上げ時に、競合についてのプロジェクトルールを策定することは重要である。
競合発生時のルールの例
- オーバーライドしてコミットは絶対しない
- 必ず当事者同士でマージ確認を行う。
- 次回のチーム会議(振り返り)で競合の原因を議論しコミュニケーションの改善方法を話し合う。
参考文献
Subversion実践入門—達人プログラマに学ぶバージョン管理
達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化