2

最近、私が作業する機能ブランチ(SVNを使用)の概念を導入しましたが、それを処理する方法がわからない状況に遭遇しました。

これが私の状況の図です: 粘着性のある状況

グラフィックの内容は次のとおりです。トランクからブランチ(feature_phase_1)を作成し、作業に満足するまでそのブランチで作業しました。次に、コードをトランクに戻す前にレビューする必要があり、機能を継続するにはfeature_phase_1のコードが必要だったため、最初のブランチ(feature_phase_1)から新しいブランチ(feature_phase_2)を作成しました。最初のブランチでコードレビューが完了するまでそのブランチで作業し、feature_phase_2に変更をコミットし、feature_phase_1に切り替え、要求された変更を行い、ブランチにコミットしてから、トランクに再統合しました。

それから私は頭痛がしました。

再統合されたブランチでは作業を続けないことが提案されているので、2つのブランチ間の差分を使用してパッチを作成し、それを新しいブランチに適用すると思いました(feature_phase_1ブランチを再統合した後、トランクから) 、および現在のfeature_phase_2を削除します。しかし、それは私に予想以上に多くの対立を与えました。

ブランチからブランチを作成することも提案されていないことをどこかで読みました。そこに何が入っているのかわからなかったので、なぜ今なのかわかります。パッチを適用して競合を編集することができましたが、それは面倒で、プロセスをすり抜けてしまいました。

競合のリスクとマージプロセスの手動処理を最小限に抑える、この種の状況に対して推奨されるアプローチは何ですか?これが私が見るものです:

  • ブランチからではなくトランクからfeature_phase_2を作成し、feature_phase_1からfeature_phase_2に変更をマージしてから、状況が進むにつれてトランクからマージを続けます(feature_phase_1を再統合した後、競合が発生することが予想されます)。例
  • feature_phase_2の動作を継続し、feature_phase_1が再統合されたらトランクからマージしてから、feature_phase_2をトランクに再統合します(ここで説明する内容と少し似ています)。ただし、ブランチから分岐してから2つのレベルを再統合する必要があるため、この手法は少し汚れているように見えます。
  • ??

ありがとう

4

1 に答える 1

1

あなたの写真のために。1 (元のワークフロー) より良い (私が思うに) 選択肢は次のとおりです。

トランクを Phase_2 にマージする代わりに、feature_phase_1 を feature_phase_2 にマージし (phase_1-239 は、trunk-240 ではなく、phase_2-241 の親になります)、その後、phase_2 をトランクにマージします。

于 2013-01-08T20:02:57.703 に答える