2

同僚と私は、開発グループをソース管理ツールとして git を使用するように変更するための計画とテストの段階にあります。コードの安全性とワークフローのシンプルさを重視したワークフローを確立しました。ただし、さまざまなマージ ケースをテストしたところgit merge、競合が発生した場合に自動的に相違点がマージされ、手動マージの方が安全なオプションであることがわかりました。

foo()例: ブランチ origin/master には、機能を持ちbar()、コミット C1 としての単一のスクリプト ファイルが含まれています。2 人のユーザーが各自のマシンでローカルに C1 をチェックアウトし、変更を加えます。User1 が function を追加し、 functionbaz()を削除しますfoo()。彼は早送りマージを実行し、変更をオリジン/マスターに C2 としてプッシュします。User2 が変更するbar()ため、C3 を呼び出しfoo()て変更をコミットします。彼はフェッチとマージを実行して origin/master からの変更を取り込み、git は C4 への再帰的なマージを実行します。その結果、現在は存在しない 呼び出しを行っているためbar()、and baz()whereのみを含むファイルが作成されます。bar()foo()

質問: 手動マージを強制するために、これらの状況で自動的に競合を引き起こすようにカスタム マージ ドライバをセットアップできることを認識しています (実際にそうしました)。しかし、これは git の非常に根本的な問題であるように思われるため、他の誰も議論していないことに驚いています。何か不足していますか、それともカスタム マージ ドライバがこれを処理する最善の方法ですか?

最後に、これを事後的に修正するためのツールがあることに気付きましたが、マージ中に修正するのが最もクリーンで簡単な方法のようです。

編集:gitは壊れたコードを検出できないことを認識していますが、ファイルが最も近い共通の祖先から両方のブランチで変更されたことを検出できるため、競合を生成する方が自動的にマージするよりも安全だと思います. 私のカスタム マージ ドライバはこれを実現しますが、Better Way(TM) があるかどうかを確認したかったのです。

4

1 に答える 1

4

この問題は git に固有のものではありません。私が知っているすべてのバージョン管理システムは、セマンティックの競合ではなく、テキストの競合を管理しています。つまり、git は 2 人が同じコード行を変更したかどうかを検出できます。あなたが話している種類の競合を検出する唯一の方法は、本質的に競合検出プロセスの一部としてコードをコンパイルすることです。完全に実行不可能なことではないことに注意してください。それは、まだ誰もそれに慣れていないということです。

ほとんどのチームでは、この状況はあまり発生しません。これが頻繁に発生する場合は、設計の結合、または作業の分割方法に関するチームメイトとのコミュニケーションに注目することをお勧めします。

于 2013-02-27T19:54:47.633 に答える