0

3 つの主要なブランチを持つ単純なワークフローがあります。

stagingつまり、テスト環境

masterつまり、本番環境

dev/XXXXXX はチケット番号です。

  • クライアントはチケットをログに記録します
  • ブランチを作成します。dev/2332
  • 作業 + コミット + プッシュ
  • 準備ができたら作業をマージしますstaging
  • クライアントが作業を承認するstaging
  • 作業をマージしmaster、チケットを本番環境にデプロイします

問題：

複数の開発者がそれぞれdev/XXXのブランチで作業している場合。にマージするstagingと、競合が発生することがあります。ステージングとプッシュでこれらの競合を修正します。

問題は、クライアントがそれらの特定のチケットを承認し、作業を にマージするときにmaster、競合を再度修正する必要があることです。

重要：

  • 未承認のチケットのため、ステージングをマスターにマージできません
  • デフォルトではすべてのブランチが最新のマスターから作成されます
  • 複数のチケットが同時に開発されていますが、承認されたときに展開されます
  • 競合を回避するためのマスターからのリベースは、作業が承認されて既に展開されている場合にのみオプションです
  • 未承認のチケットがあるため、ステージングからのリベースはオプションではありません

この問題を解決する方法についてのアイデアはありますか? 私たちのワークフローに欠陥はありますか? いくつかの git ハックがありませんか?

基本的に同じことは二度と繰り返したくない

ありがとうございました

4

2 に答える 2

2

branch per featureを見てください。あなたはまさにこの主題についての私の投稿を受け取るべきです. また、 rerere キャッシュの共有に関する質問にここで回答しました

于 2012-10-03T23:54:28.067 に答える
0

あなたはできるだけお互いに近づける必要がありmasterます。ブランチstaging自体をgitする方法で処理してみてください。puつまり、新しいタスクが完了し、ブランチが削除され、そこから再作成され、master承認待ちのすべての機能がマージされたときです。その利点は、ブランチが分岐しないことと、拒否された機能のマージを解除するための問題がないことです。欠点は、それに基づいて作業を行うことができないことですが、とにかくそうではありません。

競合が発生した場合は、開発ブランチを微調整してきれいにマージし、「タコ」マージ (2 つ以上の親とのマージ) を実行してstaging再度作成するか、依存関係または競合する機能が承認されるのを待ってから依存関係をステージングします。 .

masterいずれにせよ、機能ブランチは、それらをステージングしようとする直前に最新のものにリベース (またはマージ) する必要があります。それらは作成時に master から作成されたものであるため、後の master にリベースすることは、それらが後で開始され、より速く開発されたように見えますが、明らかに間違っているわけではありません。

于 2012-10-03T17:57:51.080 に答える