一个分支的交互式变基,其与主人的分歧点

Aar*_*ron 21 git rebase

假设我有一个主题分支,我想重写它的整个历史,因为它最初是从master为pull请求创建的.无论出于何种原因,使用git log确定我想传递给的提交哈希并不容易或明显

git rebase -i <commit>
Run Code Online (Sandbox Code Playgroud)

我知道我可以git merge-base <branch1> <branch2 || master>用来查找两个引用可以跟踪其祖先的提交,并可以使用它来确定提交.我想知道的是,如果有一种更好的方式来交互式地改变整个分支(无论主人是否提高)而不是使用

git rebase -i `git merge-base my_branch master`
Run Code Online (Sandbox Code Playgroud)

编辑:我不想更改在此分支上进行的第一次提交的父级,因此git rebase -i master只有在创建分支并且从当前指向的提交主机创建分支时,两个主服务器都没有高级的情况下才会工作.

twa*_*erg 20

也许我误解了你的问题,但我认为git rebase -i master应该做你想做的事.它将找出合并基础并将整个分支从该点重新绑定到当前HEAD,以便它看起来已经从当前的主数据分支.

此外,如果主人没有进步,那么重新定位几乎就是无操作.

  • 实际上,在再次阅读完整篇文章之后,也许你只想在你的分支上重新安排提交(可能会跳过一些或组合或重新排序)而不将其移动到任何地方?在这种情况下,我认为`git rebase -i`(没有指定目标分支)应该这样做. (3认同)
  • 谢谢!你的最后评论是我想要的解释.您建议的任何修改都可以使我原来的问题对其他人更有价值吗?我下次会尝试`git rebase -i`.我确实知道我在原始问题中发布的内容是有效的,我只知道merge-base是由git内部使用的,并且认为可能还有其他方法来缩短我的表达式. (2认同)
  • 我想我第一次错过的是你没有尝试重新安置分支,而是重新安排它.我个人倾向于使用`rebase`来在不同的地方切割和嫁接分支,而不是重新排序和压缩提交,所以我从不同的角度看待你的问题.我想明确表示你只想在现有分支上调整历史记录而不是移动分支可能会有所帮助,因为`git rebase`(以及其他子命令)有时会有多个可能的用途...... (2认同)

Akr*_*kos 5

我只发现对您列出的命令的一项迭代改进。您的命令:

git rebase -i `git merge-base my_branch master`
Run Code Online (Sandbox Code Playgroud)

一个改进是不必记住要变基的分支的名称。假设您当前位于要变基的分支上(根据我的经验,这几乎总是这种情况),您可以使用:

git rebase -i `git merge-base HEAD master`
Run Code Online (Sandbox Code Playgroud)