「gitでconflict対応時のデファクトスタンダード」に関しての考えをまとめました。

目次

僕たちの開発ではgit flowをベースに開発している。作業していたfeatureブランチをdevelopにmergeするタイミングで、conflictが発生した。このタイミングでふとコンフリクトの解消の流れに関して疑問が生じた。

「developに作業ブランチをMergeしたタイミングでコンフリクトを解消する」

「作業ブランチにdevelopをMergeしたタイミングでコンフリクトを解消すする。その後絶対にコンフリクトが起こらないため、再度作業ブランチをdevelopにMergeする」

‌

要するに、「どっちのブランチでコンフリクトを解消するのか」と気になった。まあおおむね作業ブランチに対して最新のdevelopを取り込んで対応するのが筋だと思っているが念のため、ChatGPTにベストプラクティスについて尋ねてみた

‌

Conflict対応は作業ブランチで

‌

Gitでのブランチのマージに関するベストプラクティスは、一般的に以下のような流れです。

作業ブランチにdevelopをマージ: まず、作業ブランチに対してdevelopブランチをマージします。これにより、作業ブランチでの変更とdevelopブランチの変更が結合されます。

コンフリクトの解消: 作業ブランチにdevelopをマージした際にコンフリクトが発生する可能性があります。この際に、作業ブランチ内でコンフリクトを解消します。これは、作業ブランチ内での変更とdevelopブランチ内での変更が競合している場合に行います。

テストと確認: コンフリクトが解消されたら、作業ブランチ内の変更が正しく反映されていることを確認するためにテストを行います。必要に応じて、他のチームメンバーやコードレビュワーにも確認してもらいます。

developブランチにマージ: 作業ブランチに対するマージが成功していることを確認したら、今度は作業ブランチをdevelopブランチにマージします。このとき、作業ブランチには既にコンフリクトが解消された状態であるため、developブランチへのマージはスムーズに進むはずです。

この流れを守ることで、コンフリクトの解消がより効率的に行えます。なお、一般的な原則として、マージの前には常に作業ブランチの最新の状態を保つことも大切です。これにより、意図しない競合を最小限に抑えることができます。

しかし、プロジェクトやチームの運用方法によっては、少し異なるアプローチが適している場合もあります。特定のケースにおいては、直接作業ブランチからdevelopブランチにマージしてコンフリクトを解消する方法も選択肢となるかもしれません。最適な方法は、チームやプロジェクトの状況に合わせて選択することが重要です。

‌

ふむ、やはり「Conflict対応は作業ブランチで」が鉄則のようだった。またGitHubを使っているケースではpullRrequestでも作業ブランチで対応してから、再度申請するイメージがある。それに近しいものだろう。