Question

当我一个接一个地提交两个提交时，我可以用

压缩它们

git rebase -i origin/{branch}~1 {branch}

但是现在提交的顺序是不同的：

我的提交
与上游合并：合并分支＆＃39; master＆＃39; github.com：...
这被推到了原点。

现在git log和我的pull请求显示我的原始提交和合并提交。但是上面的rebase命令只显示了来自上游的其他提交，并且由于某种原因没有我的合并提交。

那么如果git rebase甚至没有显示它们怎么能压缩提交呢？

Answer 1

Rebase通常完全删除合并提交。原因很简单：rebase 副本提交，将它们变为更改，然后将这些更改应用到新的基础（因此名称＆＃34;重新基础＆＃ 34）。复制后，您放弃＆＃34;放弃＆＃34;原件承诺支持闪亮的新副本：

drawnCircle_Radius

变为：

... <--B <--C   <-- master
        \
         D <--E <--F   <-- branch

其中... <--B <--C <-- master \ D' <--E' <--F' <-- branch是D'的闪亮新副本，依此类推。换句话说，rebase会收集一系列提交，例如D，将它们转换为＆＃34;与D-E-F到B的不同之处，是什么＆＃39; s不同于D到D，以及与E到E的不同之处。然后，Git可以将相同的更改应用于F以生成C，然后将D' - vs - D更改重新应用于{{ 1}}，等等。

修改任何发布（推送）提交通常是不明智的，除非您与共享该推送存储库的所有其他人预先安排此提交，以便他们理解并将能够与此协调。从本质上讲，他们 - 其他人 - 正在使用您放弃的承诺，转而支持闪亮的新承诺;因此他们必须也放弃那些提交以支持闪亮的新提交，否则他们将带回旧/脏/破坏/任何提交。

合并提交没有明确的方法可以转换为更改，因为它们具有两个之前（或父）提交，而不仅仅是一个，并且更改 in 合并是组合来自每个父级的更改的结果。（可以创建 new 合并，但这非常棘手，将它与普通的交互式rebase结合起来并不安全。）

如何压缩旧提交和最近的合并提交

1 个答案: