3

こんな歴史があります

H o updated ctools, ds
G M─┐ merged module file
F │ o find page 
E o │ work on download restriction
D o─┘ Report downloading/emailing WIP
C o migration: find and replace URLs throughout notes
B o various local things
A o initial commit

さらに遅れて、Aはリモートマスターから外れます。これでリモートが移動しました。gitrebaseを使用して履歴を更新し、最新のリモート変更を更新したいと思います。

これらのコミットはすべてリモートマスターにないコード上にありますが、 GでマージされたサイドブランチであるD：Gの処理方法を理解していないようであるため、gitrebaseは失敗します。Git rebaseは、マージせずにそれらを順番に適用しようとします。つまり、FはEに適用されません。コードを最新のオリジンの開発に合わせて維持するために、何度かリベースする必要があることを計画しているので、永続的なソリューションが必要です。A B C D E F H...

競合の答えがGにあることをgitに伝えるにはどうすればよいですか？または、git rebaseがコミットに応答できるように他の方法を実行するにはどうすればよいですか？それが物事を容易にするなら、私は喜んでD：GをD'に押しつぶしたいと思います。

4

1 に答える 1

2

リベースはマージコミット用に設計されていないため、マスターとの Git マージはシナリオで最適なオプションです (G はここでの問題です)。しかし、本当にgit rebase -p望む結果が得られなかった場合は、次のことができます。

  1. リベース AE (これは A'-E' です)
  2. F' になるように D' の上に (cherrypick またはその他の方法で) F を個別に再適用します。
  3. E' と F' を結合して G' にする
  4. G' の上のチェリーピック H

ここでマージが好まれるその他の理由:

  1. リベースしようとしているコミットは、おそらく既にリモートの機能ブランチに属している可能性があります。それらの多くを別のリモート ブランチにリベースすると、単純に大量の重複コミットが発生し、他の人を混乱させる可能性があります。

  2. これらのコミットがローカル ブランチのみにある場合、それらをリベースする (必ずしもプッシュする必要はありません) ことにより、最終的にプッシュまたはマージされるまで、それらを事実上「差し控える」ことになります。これは、膨大な数のコミットが短期間にどこからともなく突然現れたように見えるため、他の人にとって混乱を招く可能性があります。マージは、ワークフローの定期的なアクティビティである必要があります。

とはいえ、何らかの理由で (git-svn を使用するなど) 定期的なリベースを行う予定がある場合、最善の方法は、リベースするコミットの線形履歴を維持するか、それらを少数に制限することです。 . マージを含む一連のコミットの場合、それらのマージは (ミニ リベースのように) 前から後ろに折りたたむ必要があります。

于 2012-11-23T14:46:09.310 に答える