挤压到 master 后提交历史混乱

Question

我在回购中有两个分支：master 和 dev。

dev 的状态是

- A - S1 - S2 - ... - SN - B - C

master 的状态是

- A - S

其中 S commit 是 S1, ..., SN 从 dev 到 master 的“压缩和合并”的结果。

现在，当我比较分支时，git 显示了很多变化，但实际上它们是 B 和 C。

同步分支的最佳方式是什么？
避免这种情况的正确工作流程是什么？

Answer 1

好的....你的评论解释了发生了什么。因此，github 在进行 diff 时将使用三重点。因此，如果您尝试 git diff master..dev，您将只会看到 B 和 C 介绍的内容。但是 github 将使用 master...dev（反之亦然，无所谓）。尝试使用带三点的 git，您会发现它也将包含 S 引入的更改，这是因为当您执行 master...dev、git won' t 对比master和dev就可以了。它将首先找到它们之间的最后一个共同祖先 (A)，然后是 git diff A..dev，其中将包括 S1..SN 引入的更改...如果您尝试 dev...master，同样的事情.它最终会做 git diff A..master（这将包括 S 的变化）。那是因为当你 squashed/merge 时，并没有真正的合并。

使它再次工作的方法是将 dev 设置为 B 和 C 在 current 之上主人：

git rebase --onto master SN dev

这应该可以满足您的需求，但您会丢失 S1~..SN 的历史记录。另一种方法是将其正确合并.....但是稍微修改一下，这样您就不必自己重做（比如，您是否必须解决冲突和其他问题？我不知道......所以），你可以试试这个：

git commit-tree -p A -p SN -m "Merging S" S^{tree}
# this will create a new _merge_ revision having A and SN as parents
# the content of the files will be the same as S
# the command will print the ID of a revision
# take that revision ID and let's call it X
# branch dev can live on the way it is.... we just need to put master where X is
git checkout master # if you are not in master already
# make sure you have no changes uncommitted as the next command will destroy those changes
git reset --hard X 
# now master is on top of X, the way it should have been

现在，不要再试一次squashing/merging除非你知道自己在做什么。

挤压到 master 后提交历史混乱

Commit history mess after squashing into master

git

merge

squash