3

「feature1」は「feature2」の基礎となる 2 つの機能に同時に取り組んでいます。私はそれらのために 2 つのブランチを作成します。feature1 に取り組むときは、「feature1」ブランチにコミットします。feature2 に取り組むときは、「feature2」ブランチにコミットし、定期的に「feature1」の上に「feature2」をリベースします。

git checkout feature2
git rebase feature1
... work ...
git commit ...

だから、ある瞬間、私はこの構造を持っています：

feature1: A -> B -> C
feature2: A -> B -> C -> P -> Q -> R

この時点で、機能 1 は完了です。A、B、および C を単一のコミット D に押しつぶし、この新しい状態の feature1 に基づいて feature2 をリベースします。

feature1: D
feature2: D -> P' -> Q' -> R'

単純なことですが、feature1 でインタラクティブなリベースを実行し、A、B、および C を D にうまく押しつぶして、feature2 のリベースを試みます。

git checkout feature2
git rebase feature1

ここで、git は D を feature2 ブランチにプルし、その上に A、B、C、P、Q、および R を再適用しようとします。もちろん、A、B、C の更新は D によって既に適用されているため、マージの競合が発生します。

A、B、および C が再適用されているときにマージの競合が報告された場合、実行する必要があることを試行錯誤して考えました

git rebase --skip

そして、まさに必要な結果が得られます。しかし、第一に、あなたがまだ知らなければ、これは明らかではありません。第二に、潜在的な真のマージ競合を簡単に見落としてスキップしてしまいます。後者の可能性は低いはずですが、そうなった場合、対応する更新が完全に失われるため、かなり悪いことです。

それで、私の質問は次のとおりです。いくつかのコミットが最近1つに押しつぶされたブランチにブランチをリベースするより良い方法はありますか?

4

2 に答える 2

2

--onto オプションを使用してリベースし、@n reflog コミット命名を使用してここで私の問題を解決するのが好きです。これは、git 以外の VCS とやり取りするとき、または相互に依存しているが公開されていない複数のローカル ブランチであるときによく発生します。 .

最初のリベースの後: (コミットを押しつぶしていますが、ほとんどすべてのリベースが可能です)

git rebase -i master feature1

2 回目のリベースでフォローアップします。

git rebase --onto feature1 feature1@1 feature2

または (「ロングハンド」)

git checkout feature2
git rebase --onto feature1 feature1@1

つまり、feature1 の以前のバージョンにはない feature2 のコミットを取得し、feature1 の現在のバージョンの上でそれらを再生します。

于 2013-09-18T18:52:41.583 に答える