git rebase --continue和--stepback？

Question

git rebase --continue和--stepback？

elm*_*rco 40 git

有没有办法在交互式rebase期间退回提交？

谢谢

Answer 1

Mob*_*erg 32

就在这里.如何在交互式rebase期间退回:

获取当前HEAD的提交哈希值,例如 git rev-parse HEAD
跑 git rebase --edit-todo
将带有该哈希值的选择项插入该文件的顶部 pick <hash from step 1>
跑 git reset --hard HEAD^

现在你仍然在使用rebase,但是一个回复,你可以继续使用git rebase --continue.如果您不希望在没有编辑的情况下直接选择撤消提交,则可以添加edit <HASH>而不是添加pick <HASH>到待办事项列表(步骤3).

附录:您可以记住更多的哈希值,重置为更早的点,并添加多个选择以重做多个提交.

这里解释得更清楚:http://arigrant.com/blog/2014/5/4/git-rebase-stepping-forward-and-back

这仅适用于交互式rebase. (3认同)
@JohannesMüller这个问题特别要求退回交互式rebase. (3认同)
请注意,当您在交互式rebase和git因合并冲突而停止时执行此操作时,您还需要手动添加有关应用的提交.这不再包含在TODO列表中.因此,如果您不手动包含它,您将在新历史记录中松开该提交.我还无法弄清楚如何向git请求这个哈希,但是我的GUI客户端向我展示了这对我有用的东西. (3认同)
我认为您的答案提出了正确的想法，但答案本身可以改进。这个想法是：查看git日志中的内容，然后将所有提交添加到想重新绕到rebase待办事项的位置，然后在添加到列表之前将其重置为提交。建议用户仅选择HEAD提交可能是很冒昧的。除了不会选择只是让您回到原来的位置？除了选择要回滚的命令以外，您还需要编辑或其他一些变基命令。 (2认同)
重申 Rolf W. 的观点，当您执行“git rebase --edit-todo”时，如果发生合并冲突，则包含 _current_ 提交是**关键**，因为它**不**尚未致力于 HEAD，但它也不再位于待办事项列表中。您可以使用“git rev-parse --short REBASE_HEAD”获取此提交的短 SHA-1，并使用“pick <commit>”将其添加到待办事项列表的开头，或者您可以从原始内容中获取确切的行带有 `tail -1 \`git rev-parse --show-toplevel\`/.git/rebase-merge/done` 的待办事项列表。之后，`git reset --hard HEAD`将倒回合并冲突。 (2认同)

Answer 2

jun*_*var 9

实际上，即使您不进行交互式变基也可以。

正如 johnb003 在他的评论中提到的，在变基时，你实际上是在进行一系列新的提交。通过执行诸如之类的操作git log --pretty=oneline --abbrev-commit，您可以轻松查看已通过变基进行的所有提交。只需复制它们的哈希值以供以后轻松参考。

然后git rebase --abort，git rebase -i <base_branch>复制您想要保留的哈希值，edit如果您想修改其中任何一个，可以将它们更改为，然后继续

Answer 3

seh*_*ehe 5

不,马格努斯说.

然而,

git-rerere可以在某种程度上接近你想要的东西:如果你以前的手动冲突解决方案你不想放松,你可以启用rerere(预先录制的冲突解决方案),以便它们能够以相同的方式自动解决随后的合并.请注意,这意味着您必须记住下次要以不同方式解决的部分(可能是首先进行后退的目标？)因为 - 好吧,rerere假设您想要再次应用相同的分辨率.

如果你看一下rebase的实现,你或许可以找出GIT_WORK_TREE/GIT_DIR/GIT_INDEX的替代设置; 那么你可以使用plumbing命令和reflog来进行rebase-in-progress branch？

这会让你深入到无证的内部(管道之外)
你也可以提出一个实现rebase的补丁 --step-back

我认为这个答案是错误的。看看我的“是”-关于如何退后的答案。 (4认同)

归档时间：	14 年，4 月前
查看次数：	8890 次
最近记录：	5 年，10 月前