本記事は、「パッケージソフトウェア開発 Advent Calendar」6日目の記事です。
以前、Git を用いてチーム開発をするにあたって、トピックブランチを切ることの理由を問われたことがありました。
そのとき、うまく答えられなかったので整理してみます。
なお、GitHub などの Pull request を使用していない Git を利用した開発の話を想定した内容です。
1人でトピックブランチを切る運用をした場合
1人でトピックブランチを切る運用をした場合の内容をコミットツリーの図で表現してみます。
まず修正を開始するためにブランチを作成し HEAD をそれに切り替えるため、git checkout -b <トピックブランチ名>を実行します。
次にトピックブランチでローカルで実施した修正をgit commitなどでコミットします。
トピックブランチの内容をmasterに反映するため、一旦 HEAD を master に移動させます。
git merge --no-ff <トピックブランチ名>でトピックブランチを master にマージします。
不要になったトピックブランチをgit delete -d <トピックブランチ名>で削除します。
正直面倒な感じです。
ただ、コミットツリーが枝分かれしていることで、master ブランチに修正を取り込んだということが伝わりやすい利点もあります。
1人でトピックブランチを切らない運用をした場合
次に1人でトピックブランチを切らない運用をした場合の内容をコミットツリーの図で表現してみます。
ローカルで実施した修正をgit commitなどでコミットします。
とても簡単に終わります。
コミットツリーが一直線になっていきます。
複数人でトピックブランチを切る運用をした場合
今度はチームで開発する場合の場合について述べていきます。
では、複数人でトピックブランチを切る運用をした場合の内容をコミットツリーの図で表現してみます。
まず、Aさんが「1人でトピックブランチを切る運用をした場合」でやったようにトピックブランチを切って master にマージします。
そして、A さんが git push origin master でリモートに反映します。
さて、B さんが別の修正を実施していて、トピックブランチにコミットしました。
B さんは master にマージする前に master ブランチが他の誰かの修正を取り込んでいるかもしれないので、git pull origin master で master を最新にします。
この際の pull では master に対して何も修正していないため、Fast-forward マージとなります。
B さんは、最新にした master をチェックアウト後、master にトピックブランチをマージします。
この際、master との内容によってはコンフリクトがこのタイミングで発生します。
最後に B さんが git push origin master でリモートに反映します。
この方法とった場合の利点はリモートにあるブランチである master に対しては、push する直前以外には修正をしないことです。
これにより、B さんが master を pull するタイミングでは Fast-forward マージになるのが保証されているので、そのタイミングでコンフリクトが起こることがありません。
また、このコミットツリーの構成は Pull request 運用した場合と同様の形になります。
複数人でトピックブランチを切らない運用をした場合
最後に複数人でトピックブランチを切らない運用をした場合の内容をコミットツリーの図で表現してみます。
A さんがローカルでコミットをします。
A さんは git push origin master でリモートに反映します。
B さんが別の修正を実施していて、ローカルでコミットしました。
B さんは master にマージする前に master ブランチが他の誰かの修正を取り込んでいるかもしれないので、git pull origin master で master を最新にします。
そうした場合、Fast-forward マージはできません。
そのため、場合によってはコンフリクトがこのタイミングで起きます。
B さんはgit push origin master でリモートに反映します。
個々の作業自体は簡単です。
ですが、1人でやった場合と異なって、コミットツリーが一直線にはならなくなります。
また、pull のタイミングでコンフリクトが発生する可能性があるので、個人的にはあまり直観的ではない気がしています。
まとめ
コミットツリーの図を用いて、トピックブランチを切った場合と切らなかった場合、どのようになるかを述べました。
ちなみに自分の場合、個人ではトピックブランチを切らない形で、社内などのチームでやる場合はトピックブランチを切る形で運用しています。
実際にどう運用するかは上記 4 パターンの挙動を理解した上で、好みで決めればよいと思っています。