同僚と私は、開発グループをソース管理ツールとして 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) があるかどうかを確認したかったのです。