私の会社では、新しいストーリーをコーディングするときに次のgitワークフローを使用しています。
- マスターからトピックブランチを作成します（本番/安定版）
- 機能を実装するために必要な数のコミットを作成します。
- そのトピックブランチのgitmerge--squashをqaブランチに実行します。
- QAの人々がレビューします。
- 良ければ、コードはuaブランチにマージされます。User Acceptanceチームがそれを祝福すると、マスターにマージされ、最終的に展開されます。
- レビューに失敗した場合、開発者は修正する必要があります。基本的に、ステップ2でプロセスを再開します。
注：ポイントコードがqaブランチにマージされ、qaがそれを拒否/受け入れるまでに最大2週間かかる場合があります。
問題がなければ、コードは最終的にそれをマスターにします。ただし、QAが問題を発見し、それを修正する必要がある場合のベストプラクティスを探しています。私が望んでいるのは、可能な限り「元の状態」に見えるqaブランチになってしまうことです。
私が見ているように、ここにオプションがあります：
- qaブランチで元の押しつぶされたコミットを元に戻し、qaからトピックブランチをリベースし、トピックブランチでコードを修正し、qaに再度マージします。問題：厄介な復帰コミットを残します。
- 既存のトピックブランチを削除し、qaブランチから再作成し、問題を修正するための簡単なコミットを作成し、qaにマージして戻します。問題：機能のコード変更を、時間と場所が異なるコミット全体に分散させます。
- qaへの押しつぶされたマージを廃止し、個々のコミットをqaから既存のトピックブランチにリベースし、別のコミットで修正し、qaにマージします。問題：複数のコミットにより、変更がuaブランチに移動してからマスターに移動するときに、変更を追跡することが困難になります。
質問：マージされたコードを修正する必要がある場合に、単一の機能の複数のコミットを複数の長期的なブランチ（マスター->トピック-> qa-> ua->マスター）に移動するためのベストプラクティスはありますか？