質問: 例えば、複数のアクションから成る1つのコントローラを、アクションごとに複数の担当者で作成する場合、 どのようにすればできるだけ衝突を起こさず作成ができるでしょうか。 コントローラはファイルが無い状態から作り始めます。
回答: > > 1つのコントローラを、アクションごとに複数の担当者で作成する場合、 > > どのようにすればできるだけ衝突を起こさず作成ができるでしょうか。 > > > * コントローラー層を 業務ロジックライブラリを呼び出すだけの軽い実装とする * 業務ロジックのライブラリは UNIT テストを必ず書く * 他の人の開発資産をマージした時には 必ず UNIT テストが OK となることを確認する。 をするだけで、`git` は 同一行を 複数の人が修正しない限り 自動的マージが 衝突せず、かなり うまくマージしてくれます。 ごくまれに、変なマージをすることがあるので、それを UNIT テストで 検出できるようにしておきます。 あとは * git の コミットの粒度に気を付ける も 大事だと思います。 初版の コードがどんどん追加されている時にはあまり衝突が発生せず 自動マージで結構 自動で解決 する事が多いのですが、 開発が 中盤から終盤に差し掛かった時に リファクタリングが 機能修正、機能追加が発生します。 このタイミングでの衝突は 解決の難易度が上がります。 この時に役立つのは `わかりやすいコミットメッセージ`と `1つのコミットに いろいろ詰め込まない事` です。 よくあることなのですが、 バグ修正していたら、他のバグを見つけたので一緒に修正したとか バグ修正中に コメントのタイプミスを見つけたので 他の場所も一緒に修正した とかやってしまいがちですが ここは 我慢して 修正のコミットと タイプミスのコミットは 分けるべきだと思います。 Git によるデバッグ にある `二分探索` の部分の例のように 何かがおかしくなった時に 『問題が混入した コミットを 特定する』 という事ができるので、読んでおいていざというときに試してみてください。 他のブランチ戦略について git の場合には `git flow` とか `pull リクエスト` 等の 開発ワークフローに 沿って開発するという 戦略もあります。 機能単位に独立した物を ブランチ間で マージしたり、 バグの修正依頼を pull リクエストでマージしたりする方法ですが 複数の開発者で同じようなコードを同時に開発する場合には、むいていないような気がします。 それぞれの開発者は 同じブランチで こまめに commit と pull と push を行って ソースコードの 差分が小さい状態で開発した方がいいと思います。 チームが大きくなって全然別の機能を作っているチームが別にあるならそのチームは別ブランチで開発 定期的にブランチ間のマージを行う方がいいと思います。 細かな運用は そのチームによってさまざまなのでしょうが、参考までに・・。