マージの競合を修正するのは誰の責任ですか？
Aがマスターに基づいてブランチで作業していて、Bが変更をマスターブランチにマージするとします。これにより、Aのブランチとマスター間でマージの競合が発生します。
マージの競合を修正するのは誰の責任ですか？私はささいなことをするつもりはないので、言い換えれば、Aがこれらの競合を修正したり、Bを修正したりすると、一般的に生産性が向上しますか？
人物Aは、マスターからの新しい変更をいつ組み込むかを決定する人物なので、人物Aがマージを実行します。人物Aは確かに自分でマージの競合を解決しようとする必要がありますが、質問が発生した場合は、人物Aと人物Bの両方が一緒に座って一緒に競合を解決する。
チームで作業することを忘れないでください。チームメイトは、指差ししたり「自分の仕事ではなく」と言ったりすることなく、互いに助け合う必要があります。
したがって、あなたの質問に答えるために、どちらの人もマージの競合を解決する責任はありません。あなたは両方です。
実際には、支店のオーナーである人物Aです。
実際には、ブランチC、D、E、およびFが存在し、マスターとの競合が発生します。PersonBはそれらをすべて修正することはできません。
ただし、一緒に作業している場合、マージの競合は簡単に修正できます。結局のところ、Bさんが何をしようとしているのかがわかっていて、毎日のスクラムなどで必要な変更について話し合うことになります。ですから、彼らがチェックインしても驚くことではなく、競合が発生した理由と修正方法を理解できます。
一般に、衝突に遭遇した人もそれを解決する必要があります。結局のところ、マージを発生させ、衝突を発生させるには衝突の解決が必要な人です。
サンプルでは、Aです。masterブランチでコードを必要としているのはAです。そこでそのコードを欲しがっているのは、B氏ではありません。人物Bはブランチに変更を加えただけで、明らかに競合していなかったか、変更した場合でも競合を解決しました。人物Bが自分の変更をはるかに速く追加していたとしたら、人物Aはすでに機能ブランチでそれらに対処しなければならなかったでしょうね。さて、今、人Aは後でそれらを処理する必要がありますが、これはほんの少し余分な作業になるはずです。
競合が非常に大きいために多くの余分な作業が必要な場合は、何かが完全に失敗しました。例えば。 2人が同じ機能を実装したり、矛盾する機能を実装したり、1人が機能に取り組んだり、別の人がプロジェクトを完全に再構成したりした場合、これら2つのコード変更の準備に計画/管理上の欠陥がありました。
その場合、その競合を解決することが意味があるかどうかについて話し合う必要があります。競合を解決するには少なくとも同じ量の作業が必要になるため、両方の変更の1つを完全に破棄し（1つは議論する必要があります）、新しいコードベースで作業をやり直す方が理にかなっている場合があります。別の変更によって、機能が古くなったり、設計どおりに機能するために完全に異なる機能が必要になる場合があります。その場合、マージしただけでは何もできません。マージ後も大量の追加を採用する必要があり、これらだけでも、新しいコードベースで最初からその機能を再実装する作業と同じになる可能性があります。
一般的な開発のヒントとして：
機能ブランチが長時間実行されている場合は、定期的にマスターブランチをその機能ブランチにマージしてください。これにより、2つのブランチが離れすぎて開発されるのを防ぎ、最終的なマージをはるかに簡単にします。また、その機能の実装方法と競合するマスターブランチで何かが起こっているかどうかをすぐに確認できます。次に、現在masterブランチを混乱させている人々を止めて、その状況をどのように進めるかについて話し合うか、または彼らの変更に実装戦略を採用するかはあなた次第です。
後者の場合の例：同期化することを計画していて、現在マスターブランチですべてを非同期にしている場合、使用するのと同じパターンに従って非同期にその機能を実装する必要があります。それらの変更を機能ブランチにマージすることで、masterブランチに追加された新しい便利なメソッドを利用できるようになり、計画された機能を非同期方式で実装することがはるかに容易になります。機能ブランチに焦点を当てたばかりの場合、機能は1日で完了し、同期されます。次に、それをマージして、プロジェクト内のすべてのものが変更されていることを確認し、そのマージを解決できる場合でも競合が発生した場合、機能を非同期にする必要があるため、多くのことを購入することはできません。
「マスター」ブランチを持つほとんどの開発プロセスでは、必要なマージを行うために変更を行うすべての人の責任です。
「マスター」ブランチは、ソフトウェアの「現在のベストバージョン」であるという意味で、特権ブランチです。変更がマージされると、現在のバージョンが最新であるため、変更が保持されることが期待されます。
これは、「最初の投稿後」が間違っているケースが決してないということではありません。 Aの変更がBよりも優先度が高く、ビジネスの意味でより多くの価値を提供する状況を見てきました。この状況では、Bは変更をマスターに適用することを、Aが完了するまで（Bがマージを行う責任を負うまで）許可されていませんでした。これは、Aの変更が非常に競合しているファイルに影響を与え、今後のリリースに不可欠であると見なされたために発生しました。ただし、Bは変更をマスターにコミットせず、Aの変更をマージする必要があることに注意してください。 Bは、Aが機会を持つまで、変更をマスターに適用することを禁止されていました。
もちろん、これには実際的な理由があります。多くの場合、さまざまなブランチで行われている「より重要な」変更の可能性をすべて特定することは合理的ではありません。これは、Bの変更がいつ「完了」したかに関してかなりの不確実性を生み出し、その不確実性は現代の開発環境では望ましくありません。
言われていることですが、私は確かに、Cがマージの責任者であり、Cがビルドマネージャーであるという答えがプロジェクトに取り組んできました。このような問題を解決するビルドマネージャーがいるとは思いませんが、しかし、「誰が責任を負うか」は、あなたがどのように成長するかに大きく依存していることを示しています。
合併したい人の責任です。
明らかに、競合を引き起こしたであろう変更はマージされる前にレビューされ、変更が不当な数の競合を引き起こした場合は拒否されました。
明らかに、Aはメインブランチにマージせず、競合を解決しません。マージは、メインブランチを開発ブランチにマージし、競合を解決して、ブランチが機能することを確認します。この時点で、Aにはブランチがあり、メインブランチに競合することなくマージできます。結果のコードはレビューされ、マージされます。レビューに時間がかかり、新しい競合が発生するリスクがある複雑な変更である場合、Aは、Aのマージが完了するまで変更をマージすることを同僚に依頼することができます。
ブランチ「A」と「マスター」が競合している場合は、プルリクエストを開く前に「マスター」を「A」にマージします。
このようにして、レビュープロセスが不必要に早い段階で開始されることはなく、「A」がもたらすすべての変更を、マージの競合や機能開発の解決に由来するものかどうかを明確に確認して議論できます。