问题描述
在发布历史记录之前，我经常使用git rebase -i清理历史记录.通常，我想将提交还原到当前分支分支的任何位置，而无需更改其分支点.我这样做是这样的:git rebase -i $(git show-branch --merge-base $PARENT_BRANCH HEAD)
I often use git rebase -i to clean up my history before publishing it. Usually I want to edit commits back to wherever the current branch forked off, without changing its fork point. I do it something like this: git rebase -i $(git show-branch --merge-base $PARENT_BRANCH HEAD)
这是一个丑陋的命令，我正在尝试寻找一种更好的方法.只要我愿意，我想让git自动找出合适的父母.
It's an ugly command and I'm trying to find a better way. As long as I'm at it, I'd like to have git automatically figure out the right parent.
我认为我想要的是git rebase -i --fork-point $(something)的别名，其中something查找具有当前分支的最近共同祖先的分支.它不需要是防弹的.如果它适用于线性主题分支，就我的目的而言就足够了.
I think what I want is an alias for git rebase -i --fork-point $(something), where something finds the branch with the most recent common ancestor of the current branch. It doesn't need to be bulletproof. If it works for a linear topic branch, that's good enough for my purposes.
推荐答案
有了Git 2.24(2019年第四季度)，就不再有git rebase -i --onto @{upstream}...HEAD
With Git 2.24 (Q4 2019), no more git rebase -i --onto @{upstream}...HEAD
新的"git rebase --keep-base <upstream>"尝试找到要重新建立基础的主题的原始基础，并在同一基础上重新构建基础，这在运行"git rebase -i"链接时很有用. (及其受限制的变体"git rebase -x").
The new "git rebase --keep-base <upstream>" tries to find the original base of the topic being rebased and rebase on top of that same base, which is useful when running the "git rebase -i" (and its limited variant "git rebase -x").
该命令还学会了在更多情况下可以快速转发，而不必重播以重新创建相同的提交.
The command also has learned to fast-forward in more cases where it can instead of replaying to recreate identical commits.
请参见提交414d924 ，提交4effc5b ，，提交2b318aa (2019年8月27日)，以及提交793ac7e ，提交359eceb (2019年8月25日)通过 Denton刘(Denton-L).
帮助方式:埃里克·阳光(sunshineco)， Junio C Hamano(gitster)，ÆvarArnfjörðBjarmason(avar)，和 Johannes Schindelin(dscho).
参见提交6330209 ，提交c9efc21 (2019年8月27日)和提交4336d36 (2019年8月25日)，由ÆvarArnfjörðBjarmason(avar).
帮助方式:埃里克·阳光(sunshineco)， Junio C Hamano(gitster)，ÆvarArnfjörðBjarmason(avar)，和 Johannes Schindelin(dscho).
See commit 414d924, commit 4effc5b, commit c0efb4c, commit 2b318aa (27 Aug 2019), and commit 793ac7e, commit 359eceb (25 Aug 2019) by Denton Liu (Denton-L).
Helped-by: Eric Sunshine (sunshineco), Junio C Hamano (gitster), Ævar Arnfjörð Bjarmason (avar), and Johannes Schindelin (dscho).
See commit 6330209, commit c9efc21 (27 Aug 2019), and commit 4336d36 (25 Aug 2019) by Ævar Arnfjörð Bjarmason (avar).
Helped-by: Eric Sunshine (sunshineco), Junio C Hamano (gitster), Ævar Arnfjörð Bjarmason (avar), and Johannes Schindelin (dscho).
git rebase -i --onto master... master
git rebase -x ./test.sh master... master
git rebase -i --keep-base master
git rebase -x ./test.sh --keep-base master
git rebase man page now includes:
mvds 建议将其与 git rebase --reapply-cherry-picks
mvds suggests in the comments combining this with git rebase --reapply-cherry-picks
自从进行特定提交以来，我们的编译器已升级并变得更智能，从而将代码库转换为非编译代码.
In the time since that certain commit, our compiler was upgraded and became smarter, turning the codebase into non-compiling code.
为了解决这个问题，我选择了所有需要再次编译的提交.
除非使用了--reapply-cherry-picks，否则那些精心挑选的提交将弄乱--keep-base所做的魔术.
To remedy this, I cherry-pick any commits needed to be able to compile again.
Those cherry-picked commits will mess up the magic done by --keep-base, unless --reapply-cherry-picks is used.
这篇关于我可以在不显式指定父级的情况下基于分支的派生点吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！