頻繁に複雑なマージの競合は問題の兆候ですか？
私たちのチームでは、ソース管理としてGitを使用しています。ほとんど独立しているが重複しているコード領域がいくつかあります。最近、ソース管理を使用するためのワークフローとアプローチについて議論しています。 機能ブランチワークフロー を使用してプロモートしたときに発生する不満の1つは、人々がしばしば間違って解決する複雑なマージの競合に遭遇することです。複雑に言うと、「解決方法がはっきりしない」という意味です。これに照らして、「プルリベース」ベースのワークフローなど、他のワークフローがより積極的に使用されています。
機能分岐アプローチの擁護者として、私は実際には不満を感じていません。はい、ローカル機能のブランチをマスターまたはどこからでも最新の状態に保つ必要がありますが、それが私が目にする唯一の実際の問題です。あなたのマージが常に複雑で二次的な影響を与える可能性がある場合、それはGitの問題よりもチームワークの問題のほうが多いと思います。
私はこれを正しいと思いますか？複雑なマージの競合は、何か良いことか悪いことの兆候ですか？
問題があなたのコードであることは不可能ではありません。コードベースにモジュール間の相互関係が多数ある場合、すべての変更はどこにでも蔓延し、開発者は他の誰かのコードと相互作用するため、悪夢になります。
最初は他の方法でこれに気づくと思う傾向がありますが、慣れすぎて見えなくなっている可能性があります。
「fetch-rebase-Push」ワークフローに慣れています。これは実際には、チュートリアルで説明されている最初の、最も原始的なワークフローです。利点は次のとおりです。
- 真の継続的統合
- 初期の競合管理-コードを記述してテストした直後
- 迅速な対応-「ねえ、ボブ、あなたが書いた3次補間はおかしい出力を出しています。昼食時にそれを見ることができますか？」
- マージコミットなし-1つの開発者がeverithyngを作成したかのようにタイムラインをクリーンアップ
さて、複雑なマージの競合について。 andの複雑なマージを両方とも頻繁に経験する方法がわかりません。 1か月間その唯一の機能に取り組んでいたため、長期間リベースやチェリーピックを行わなかったことが原因で問題が発生しています。
私は個人的に、まれですべてを網羅するマージの恐怖ではなく、頻繁で簡単なマージ（実際にはリベース）の競合に対処したいと考えています。
マージとリベースは、人間が解決しなければならない固有の競合（つまり、2人の開発者が同じコード行を変更する）のために、まったく同じ競合を引き起こすはずです。他の競合については、コミットはすべての場所でSHA-1を変更しないため、マージは実際にはよりクリーンになる傾向があります。マージがリベースよりも多くの競合を引き起こす状態にどのように対処しているのかはわかりませんが、一部の人々のワークフローがめちゃくちゃになっていることは確かです。彼らは彼らがローカルのリベースをするときに他の人のマージコミットを削除していますか、それともそのようなものですか？
プルリベース方式のメリットとデメリットは、多くの人が慣れている集中型ワークフローと非常に似ていることです。ブランチを使用するためにブランチを理解する必要はありません。
とにかく、他の人にサインオンしてもらうことができない場合は、ローカルでのみ機能ブランチワークフローを実行することは完全に実現可能です。
私が取り組んでいるプロジェクトには、この種の問題がときどきあり、いくつかの要因が原因であるようです。
- 私たちはVisual Studioを使用しており、Visual Studioの.slnのようなファイルは単なるXMLドキュメント（テキストのマージにうまく応答しない）であり、Guids（Gitは他の人よりよく理解できません）で一杯です。不適切にマージされ、ファイルが失われる原因となります。
- 一部の人々は、コードの同様の領域で作業しているため、プッシュされる変更がクラス内で互いに隣り合っている可能性があります。この状況では避けられませんが、このタイプの構成は、どのソース管理システムにとっても非常に困難な作業になります。チーム内で優れたコミュニケーションを行っていても、他の人のコードにぶつかったことに気づかず、競合が発生する場合があります。
私は Semantic Merge がこれらの問題のいくつかを解決する可能性に興味がありますが、それは、解析できる言語で作業していて、まだ実行していない場合にのみ使用できます私がそれを使用しているときに重要な課題に直面するので、その有効性を保証することはできません。
開発者が（純粋なマージの代わりに）履歴コミットを変更していない限り、機能ワークフロータイプのgitモデルの競合は、緊密に結合されたコードベース（/ brandnewコードベース）または機能割り当ての重複の兆候です。
あなたはメイン（マスター）ブランチを持っており、誰もが彼らの機能ブランチで働いています。
機能ブランチでの作業には、数時間から数か月かかることがあります。
時々、誰かが変更セットをメインブランチにリバースマージします。チームリーダーは、一度に1人だけがリバースマージを実行するようにする必要があります。これが完了したら、Mainブランチから機能ブランチにマージを転送する必要があります。誰もが前方マージを行うと、別の人がメインブランチにリバースマージできるようになります。そうしないと、あまりに多くの変更がリバースマージされ、フォワードマージで大量のマージ競合が発生します。
用語を明確にするために、「リバースマージ」とはフィーチャーブランチからメインブランチにマージすることを意味し、「フォワードマージ」とはメインブランチからフィーチャーブランチにマージすることを意味します。私が以前に経験したことに基づいて、フォワードマージではなく、リバースマージでより多くのマージ競合が発生する可能性があります。
役立つ2つのこと：1つは、自分で変更を加えるツールを使用しないことです。異なるタブ設定を使用する2人の開発者は、災害のレシピです。 2つ目は、別の場所で変更を加えることです。たとえば、3人の開発者が同じファイルの最後にコードを追加すると、問題が発生します。別の場所にコードを追加した方がはるかに優れています。