私は Git を初めて使用し、同じファイルを使用する複数のブランチを処理する場合に最適なワークフローを見つけようとしています。オフィスでのワークフローは、入ってくるチケットごとに新しいブランチを作成することです。私の最大の懸念は、これらのブランチがステージングとプロダクションにマージされるときに、すべての変更が実装されることです。
例
本番環境から branchA を作成するとします。次に、app.js を変更し、プル リクエストを QA ブランチに送信します。
ここで、branchB というプロダクションから新しいブランチを作成します。次に、app.js を変更し、プル リクエストを QA ブランチに送信します。
branchB には、branchA で行われた変更がありません。
このワークフローを続けていくと、いつも葛藤状態に陥ってしまう気がします。
多くの同じファイルを変更する別々のブランチで作業し、それらが QA にマージされたときに最新のコードが含まれていることを確認するための最良の方法は何ですか?
助けてくれてありがとう。
チケットごとに別々のブランチを作成する理由は何ですか? - 通常、1 つのブランチのソリューションをマージするオプションが提供されますが、他のブランチのソリューションは拒否されます。両方に対してプルリクエストを行い、メンテナーはそれらをマージするかどうかを決定できます。
この場合、ブランチは独立している必要があります。1 つのブランチがソリューション A を挿入し、もう 1 つのブランチが競合するソリューション B を挿入する場合、メンテナーは、そのうちの 1 つだけを選択するか、両方のソリューションを手動で結合する必要があります。
これらのチケットに取り組んでいるのがほぼあなただけで、通常はすべての解決策が受け入れられる場合は、最初の解決策に基づいて 2 番目の解決策を作成できます。（これは基本的に、何git rebaseをしているのかです。）
欠点は次のとおりです。このようにすると、最初のソリューションがなければ 2 番目のソリューションを使用できなくなります。
=> 最適な解決策は、具体的な状況によって異なります。
さまざまな機能を明確に分離するようにコードを構造化することで、競合を回避できる場合があります。- しかし、2 つのソリューションが同じ機能を別の方法で変更するとすぐに。その対立を解決する方法を誰かが決めなければなりません。