クライアントごとにカスタマイズされた基本システムがあります。ベースは独自のリポジトリに存在し、各クライアントは独自のリポジトリに存在します (元はベースからクローンされています)。
目標は、必要に応じてクライアントに伝播できるバグ修正/機能をベースに追加できるようにすることです。
これまでのワークフローは次のとおりです。
- ベースの修正/機能のコミット/トピック ブランチを作成します: (ベース、マスター)
git commit -m "Fix admin typo" - これらの変更をクライアントにマージします: (on client, master)
git merge base/master。明らかに、これにはベースとクライアントのカスタマイズ間の競合の修正が含まれます。 - マージをクライアントのオリジンにプッシュします: (クライアント、マスター上)
git push origin master - 私たちの慣例は、rebase でプルすることです (履歴を読みやすくするため)。そのため、クライアント プロジェクトで作業している別の開発者が (クライアント、マスターで)
git pull --rebase origin master
この時点で、そのプル/リベースで重大な問題が発生します。開発者は、ベースからクライアントへのマージ後に実行されるプル/リベースで競合を取得します。そして、それはほんの少しの競合ではなく、多くの競合であり (多くのコミットがリプレイされていますか?)、特定の開発者がまったく触れていないコードが頻繁に発生します。これは理不尽で持続不可能だと思います。
ここで最善の解決策は何ですか？
私の唯一の考えは、プルするときにリベースの使用をやめ、ずさんで読みにくいログに対処することですが、これを行う必要はありません。これらのクライアント プロジェクトは何年も存続する可能性があり、今後も基本システムのマージをある程度理解できるようにしたいと考えています。