4

昨日、git で非常に奇妙な状況が発生しました。

  1. いつものように機能ブランチを作成しました。その後、誰かがその機能ブランチで数日間作業します。

  2. その間に、master ブランチで重要なことが起こりました。これらの変更は、機能ブランチでも必要でした。

  3. そのため、マスター ブランチをフィーチャー ブランチにマージしました (フィーチャーで共同作業する必要があるため、フィーチャー ブランチは通常すぐにリモートにプッシュされるため、リベースはありません)。このマージはローカルでのみ行われ、まだリモートにはプッシュされていません。

  4. 機能ブランチの作業は続きます

  5. master からのマージ + 継続的な作業により、ローカル機能ブランチ new_feature は origin/new_feature より 40 コミット先になりました

  6. ここで、これら 40 個のコミットをリモートの機能ブランチにプッシュしたいと考えました。最初に、プッシュする前にいつものように git pull --rebase を実行します。

  7. 今、私たちはたくさんの紛争を経験しています。40 件のコミットを修正する価値はないと判断し、git rebase --abort を実行します。次に、git pull --no-rebase を試します。「すでに最新です」 - 奇妙な

  8. git status では、ローカル ブランチとリモート ブランチが分岐していることがわからないため、git push を試します。

  9. 予想外に、git push が機能しました。最後にプルしてから変更されたリモート ブランチにプッシュしようとすると、拒否されます。したがって、明らかにリモートは変更されていませんが、 git pull --rebase は奇妙なことをしました。

では、これについて奇妙なのは、

  1. git pull --rebase はすぐに「すでに最新」を返さず、

  2. git pull --rebase は、実際には終了すべきではない大量の競合を報告しました (報告された競合は、機能ブランチで作業されたものとは何の関係もありませんでした)

何がそのような状況を引き起こす可能性がありますか?

4

2 に答える 2

2

rerere を有効にしたり、40 の競合すべてを解決したとしても、期待した結果が得られるとは思えません。問題は次のとおりです。リベースを行いますが、マージをコミットしたいのです! 「git pull --rebase」を呼び出すことで、git は「git rebase origin/featureXY」を実行します (機能ブランチが featureXY と呼ばれると仮定します)。また、オリジンに変更がない場合は、現在のブランチでオリジン ブランチの状態にリベースを実行します。また、マージ コミットでリベースを実行すると、git は通常どおり実行されます。すべてのマージを解決し、フラットな履歴を作成します。つまり、以前にブランチにマージされたマスターのすべてのコミットがブランチに適用されます。結果は、マージ コミットのないストレート ヒストリーになります。

結論: リベースとマージを混在させないでください! ワークフローでは、マージを直接プッシュすることは避けられません。そうしないと、pull-rebase を使用し続けることができません。

于 2014-10-02T21:35:28.867 に答える