我可以在不明确指定父级的情况下基于分支的分叉点吗？

Question

我经常git rebase -i在发布之前清理我的历史记录。通常我想将提交编辑回当前分支分支的任何地方，而不改变其分支点。我这样做：git rebase -i $(git show-branch --merge-base $PARENT_BRANCH HEAD)

这是一个丑陋的命令，我正在努力寻找更好的方法。只要我在，我想让 git 自动找出正确的父母。

我想我想要的是 的别名git rebase -i --fork-point $(something)， wheresomething找到具有当前分支的最新共同祖先的分支。它不需要防弹。如果它适用于线性主题分支，那对我的目的来说已经足够了。

Answer 1

使用 Git 2.24（2019 年第四季度），不再有 git rebase -i --onto @{upstream}...HEAD

新的 " git rebase --keep-base <upstream>" 试图找到要重新定位的主题的原始基础，并在同一基础上重新定位，这在运行“ git rebase -i”（及其有限变体“ git rebase -x”）时很有用。

该命令还学会了在更多情况下快进，而不是重播以重新创建相同的提交。

请参阅提交 414d924、提交 4effc5b、提交 c0efb4c、提交 2b318aa（2019 年 8 月 27 日）和提交 793ac7e、提交 359eceb（2019 年 8 月 25 日）由Denton Liu ( Denton-L)。
帮助者：Eric Sunshine ( sunshineco)、Junio C gitsterHamano avar( )、Ævar Arnfjörð Bjarmason ( )和Johannes Schindelin ( dscho)。
见犯6330209，提交c9efc21（2019年8月27日），并提交4336d36通过（2019年8月25日）ÆvarArnfjörðBjarmason（ avar）.
帮助者：Eric Sunshine ( sunshineco)、Junio C gitsterHamano avar( )、Ævar Arnfjörð Bjarmason ( )和Johannes Schindelin ( dscho)。
^{（由Junio C gitsterHamano合并-- --在提交 640f9cd，2019 年 9 月 30 日）}

变基：教变基 --keep-base

一个常见的场景是，如果用户正在处理一个主题分支，并且他们希望对中间提交或自动压缩进行一些更改，他们会运行诸如

git rebase -i --onto master... master

为了保留合并基。
这在向 Git 邮件列表贡献补丁系列时很有用，通常从当前的“ master”开始。
在开发补丁的同时，' master' 也得到了进一步的开发，有时在 'master' 之上保持 rebase 不是最好的主意，而是保持基本提交原样。

除此之外，希望在不更改任何内容的情况下测试主题分支中的单个提交的用户可以运行

git rebase -x ./test.sh master... master

由于 rebase 到分支和上游的合并基础上是一种常见的情况，因此引入该--keep-base选项作为快捷方式。

这允许我们将上面的重写为

git rebase -i --keep-base master

和：

git rebase -x ./test.sh --keep-base master

分别。

git rebase手册页现在包括：

--keep-base：

设置创建新提交的起点到<upstream> <branch>.
运行“ git rebase --keep-base <upstream> <branch>”等同于运行“ git rebase --onto <upstream>... <upstream>”。

在开发上游分支上的功能的情况下，此选项很有用。
虽然该功能正在开发中，但上游分支可能会推进，并且保持在上游之上重新定位但保持基本提交原样可能不是最好的主意。

尽管此选项和--fork-point查找之间的合并基础 <upstream> and <branch>，但此选项使用合并基础作为将创建新提交的起点，而--fork-point使用合并基础来确定将重新定位的提交集。

mvds在评论中建议将此与git rebase --reapply-cherry-picks

在我的工作流程中，要为用 C 编写的固件开发最小的二进制补丁，我需要返回某个提交哈希，创建一个分支，执行修改并找到生成的二进制文件中的差异。

在那次提交之后，我们的编译器升级并变得更智能，将代码库变成了非编译代码。

为了解决这个问题，我精心挑选了能够再次编译所需的任何提交。
那些精心挑选的提交会弄乱由--keep-base,完成的魔法，除非--reapply-cherry-picks被使用。

该辩论是Git的邮件列表上