32

これが私のシナリオです：

  • 私のプロジェクトは、トピック分岐パターンに従っています。

  • いくつかの問題を修正するためにブランチを作成します。このブランチを problem_fixes と呼びましょう。変更を加えて、プル リクエストを送信します。

  • 新しい機能の作業を開始する必要があるため、my_feature という名前の 2 つ目のブランチを作成し、一連の変更をコミットします。

  • ある時点で、my_feature がまだ受け入れられてマージされていない problem_fixes に依存していることに気付きました (my_feature ブランチは最初のブランチからの修正の一部に依存しており、それらなしでは先に進むことができません)。

最初のブランチをより迅速に受け入れてマージするようにプロジェクト リーダーにバッジを付ける以外に、ここに従うべき最善のプロセスは何ですか?

problem_fixes (master ではなく) に基づいて新しい 3 番目のブランチを開始し、コミットを my_feature にマージする必要があるかどうか疑問に思っています。または、problem_fixes を my_feature にマージして作業を続行しても問題ありませんか? problem_fixes が最初に master にマージされると仮定すると、my_feature がマージされると、理論的には問題ないはずです (?)。

4

3 に答える 3

20

最初のブランチからトピックブランチを作成します。最初のものがマスターにマージされるとすぐに、その上にリベースすることができ、あまり変更されていないと仮定すると、問題にはならないはずです。

最初のブランチのコミットが変更されていない場合、新しいブランチはその上にきちんとスタックされます。コミットが変更された場合（押しつぶされたり、編集されたりするなど）、いつでも2番目のブランチのインタラクティブなリベースを実行して編集できます。最初のブランチがマージされると、見栄えが良くなります。

于 2012-01-22T18:26:10.123 に答える
12

はい、あなたは正しい軌道に乗っていると思います。私がすることは、新しいmy_featureブランチを作成することです。おそらく少し作業します。にmy_feature依存していることにproblem_fixes気付いたら、そのブランチをマージします。必要になることがわかっている場合、これはすぐに発生する可能性があります。次に、my_featureが master にマージされると、必要な変更が既に行われています。

堅牢なコード レビュー手順がある限り、 のmy_feature前に master にマージしようとするproblem_fixesと、その時点で気付くことに注意してください。

于 2012-01-22T18:23:57.840 に答える
0

私が作業を開始masterした後、別のブランチからいくつかの変更が必要であることに気付きましたが、それにはまだいくつかの破壊的なものが含まれているため(ただし、必要なものは完了しています)、何をするかがわかりました。その場合はあり得る

  • 彼らのブランチを私のものにマージする

  • 機能を終了する

  • 他の開発者が自分の機能を完成させるのを待ちます

  • 彼らはにマージしますmaster

  • マージコミットを期待してコミットをチェリーピックしますmaster

ほとんどの人がリベースのようなお尻の痛みだと思うチェリーピッキングをいじる必要がありますが、特に苦痛な状況から抜け出す方法は何だと思いますか.

于 2018-06-30T18:41:33.747 に答える