44

背景:最近、かなり大きなトピック ブランチを にマージしましたmaster。数日後、このトピック ブランチにバグが含まれていることがわかりました。だから私はそれをgit revert -m 1 <merge-commit>編集しました。

問題:トピック ブランチをチェックアウトし、現在のブランチに対してリベースして、master1) バグを修正し、2) (再度) 修正したトピック ブランチをマスターにマージします。新しいブランチを作成するのfixedtopicは簡単ですが、毎回作成します

git checkout fixedtopic
git rebase master

git は、古いコミットは既に にマージされているため、リプレイしないと判断しmasterます。代わりに、単純に早送りリベースを行います。

質問:fixedtopicを使用してコミットのリプレイを強制するにはどうすればよいrebaseですか? できますか？cherry-pick少し面倒なので使わないほうがいいです。

追加：

  • git resetマスターを上流にプッシュしたため、マージコミットを行うことはオプションではありません。
  • master新しいブランチを作成して元に戻したくありません。その理由は、対話型リベースを使用してトピック ブランチの履歴の一部を書き直したいからです。
  • シナリオの github の要点は次のとおりです。mastermaster
4

6 に答える 6

15

これを実現する 1 つの方法は、トピック ブランチを対話的にリベースし、master から分岐した後に最初のコミットを書き換えることです (たとえばgit rebase -i HEAD~10、ブランチに 10 個のコミットがある場合)。これにより、トピック ブランチ内のすべてのコミットの sha が書き換えられます。したがって、 を使用して通常の方法でリベースできますgit rebase master。

于 2013-08-27T12:53:05.360 に答える
15

ドキュメント（git help rebase）は、「git rebase --force-rebase」がこれを行うことを示唆していますが、（Git 1.9.1）はそうではありません。ドキュメントは、「git rebase -i --no-ff」がそのコマンドと同等であることも示唆していますが、そうではありません。機能します。

要点を複製したら、コマンドは次のとおりです。

  git checkout topic
  git rebase -i --no-ff --onto master 7b3af topic

新しいバージョンの「3 番目」と「4 番目」のコミットを master の上に置きtopic、新しいバージョンの「4 番目」を指すことで、目的の結果が得られます。2 番目のコマンドでは、SHA7b3afは「2 番目の」コミットであり、topic分岐元のポイントです。

于 2015-08-14T15:15:50.633 に答える
5

--ontoGit フォームが適切なマージされていないコミットを独自に決定しようとするのを防ぐために使用する必要があります。

例 (トピックブランチがチェックアウトされている場合):

git rebase --onto master <id-of-branch-point>

元に戻したマージの前に、トピックブランチとマスターでのコミットが<id-of-branch-point>必要なためです。git merge-base

編集

もう一度状況を読み直して、マージを元に戻したポイントまでトピック ブランチを早送りし、次に元に戻してそのポイントからトピック ブランチを修正する方が良いかもしれません。このようにして、元のトピック ブランチのすべてのコミットを繰り返すのではなく、master の最終履歴に新しい ID を取得します。何をしても、「実行、元に戻す、やり直し」という履歴になりますが、この方法はよりクリーンな履歴と見なされる可能性があります。

于 2013-08-27T10:50:23.280 に答える
1

最もうまくいくと思われるのは、新しいブランチをチェックアウトしてから、元に戻すことによって以前の作業ブランチを復元することです。

私が試した他のすべては、過度に複雑であるか、機能しません。

于 2014-09-10T02:18:51.827 に答える