現在、Git 統合の概要と準備を進めており、次のリンクと同様の設計を実装しています。
http://nvie.com/posts/a-successful-git-branching-model/
私たちが直面している問題は、'develop' ブランチまたは継続的インテグレーション ブランチにコミットしてプッシュするときです。異なるブランチで作業している複数のチームがあるため、'develop' ブランチからプルダウンすることは決してないため、マージの競合に遭遇することになります。 ' プッシュする前に。チームがあまり知識がないことを解決しようとするのは、ベスト プラクティスとは思えません。
私たちが持っていたアイデアの 1 つは、'develop' ブランチでプル リクエストを行い、それらの解決に専念するチームを作ることでした。
私たちが見逃しているオプションはありますか？
機能ブランチの背後にある考え方は、小さなアトミックな変更のみを含める必要があるということです。この変更は、その性質上、理論的にはマージの競合を引き起こさないはずです。
機能がマージの競合を引き起こしている場合、あなたが「機能」と見なすものを調べる傾向があります。
これが導入されたのを私が経験した方法は、機能が（時間の観点から）1日か2日以内に持続する特定のタスクに関連しているということです.
この短いタイムスケールを考えると、サイクル中にマージの競合が発生する可能性は低いですが、発生した場合、たとえば、コードベースの同じ領域で複数のチームが作業している場合など、競合は正しい方法で解決されます。
競合の解決を管理するために適用できるさまざまなモデルがあります。複数のチームがコードベースの特定の領域に変更を加える必要がある場合、そのプロジェクトがその特定のモジュール全体を網羅するチームに割り当てられる、水平スライシング モデルに取り組んでいます。あなたの会社は、チーム間でマージの競合に遭遇する可能性が低い場合、垂直スライス モデルに関心があるかもしれません。
紛争解決のための会話に勝るツールはありません。自分の変更が他の誰かが作業しているファイルに影響を与えることがわかっている場合、従うべき最良のモデルは対話です。
状況によっては、これは理想的ではありません。ビジネスでは、誰の変更がいつ公開されるかについて別のアイデアを持っているかもしれませんが、すべての開発者が自分の機能ブランチを開発で最新の状態に保つ限り、競合の傾向は大幅に減少します。