Github的"Squash and Merge" -随后的拉取请求显示所有先前的更改 [英] Github "Squash and Merge" - subsequent pull request showing all previous changes
问题描述
我有一个从master分支中拉出的分支.我们称其为集成.
I have a branch which I pulled from master branch. Let's call it integration.
在集成分支中,我进行了各种提交(C1,C2,C3).完成后,我向master分支发出了一个Pull Request.在master分支中,我进行了压缩合并",因此只在master中进行了一次提交.这一切看起来都很棒.
In the integration branch, I made various commits (C1, C2, C3). When I am done, I made a Pull Request to the master branch. From the master branch, I did a "Squash and Merge" so it results in only a single commit in the master. This all seems great.
但是后来,我对集成分支做了一些其他更改,当我再次发出拉取请求时,我看到了已经提交的先前更改(C1,C2,C3,C4)的所有提交注释.如果我在较早的提交中使用默认的创建合并提交",则不会出现此问题.我做错了什么?
But then later, I made some additional changes to the integration branch and when I make a pull request again, I am seeing all the commit comments of previous changes (C1, C2, C3, C4) that I have already committed. This issue is not seen if I use the default "Create an Merge commit" in my earlier commit. What did I do wrong?
推荐答案
从视觉上更容易理解.这是您的仓库. master
位于提交B
,而您的feature
分支位于提交C3
.
It's easier to understand visually. Here's your repo. master
is at commit B
, and your feature
branch is at commit C3
.
A - B [master]
\
C1 - C2 - C3 [feature]
正常合并会执行此操作.添加了新的合并提交BC123
,将master
中的内容与feature
中的内容进行了合并.历史联系在一起.请注意,feature
不会移动,它仍然位于C3
.
A normal merge does this. A new merge commit, BC123
, is added combining the content in master
with those in feature
. The histories are linked together. Note that feature
does not move, it's still at C3
.
A - B ------------- BC123 [master]
\ /
C1 - C2 - C3 [feature]
壁球合并可以做到这一点.
A squash and merge does this.
A - B ------------- BC123 [master]
\
C1 - C2 - C3 [feature]
BC123
包含与以前相同的合并内容,但是没有与feature
分支的连接.同样,feature
不会更改. feature
不会被挤压,它会粘在周围.相反,BC123
包含来自feature
的压缩更改.
BC123
contains the same merged content as before, but there's no connection to the feature
branch. And again, feature
does not change. feature
does not get squashed, it sticks around. Instead BC123
contains the squashed changes from feature
.
当您在feature
上做更多工作时,在此处提交C4
和C5
时,就会发生这种情况.
When you did more work on feature
, commits C4
and C5
here, this happened.
A - B ------------- BC123 [master]
\
C1 - C2 - C3 - C4 - C5 [feature]
当您发出拉取请求时,将显示feature
中而不是master
中的所有更改.就Git而言,它是C1
到C5
.如果您要压榨&再次合并,将在master
上进行新的提交,但仅包含C4和C5的内容,因为Git非常擅长于找出分支之间的重复内容.
And when you issue a pull request, all the changes in feature
not in master
will appear. As far as Git is concerned that's C1
to C5
. If you were to squash & merge again, there would be a new commit on master
, but only with the content of C4 and C5 because Git is pretty good at figuring out duplicate content between branches.
A - B ------------- BC123 - C45 [master]
\
C1 - C2 - C3 - C4 - C5 [feature]
虽然您可以以这种方式工作,但令人困惑.
While you can work this way, it's confusing.
长话短说:合并分支后,就不要再对其进行处理了.删除它.如果您需要做更多工作,请打开一个新分支.
Long story short: once you merge a branch, don't work on it anymore. Delete it. If you need to do more work open a new branch.
如果我在较早的提交中使用默认的创建合并提交",则不会出现此问题.
回到合并版本...
A - B ------------- BC123 [master]
\ /
C1 - C2 - C3 [feature]
如果您要在feature
...
A - B ------------- BC123 [master]
\ /
C1 - C2 - C3 - C4 - C5 [feature]
然后执行拉取请求,Git将向您显示feature
中的提交,而这些提交不在master
中.由于合并,master
包含C1
,C2
和C3
.因此,PR仅向您显示C4
和C5
.这仍然令人困惑,并且适用相同的建议:合并分支后,将其删除.如果您需要做更多工作,请打开另一个.
And then do a pull request, Git will show you the commits in feature
which are not in master
. Because of the merge, master
contains C1
, C2
, and C3
. So the PR only shows you C4
and C5
. This is still confusing, and the same advice applies: once you merge a branch, delete it. Open another one if you need to do more work.
壁球&合并更简单,合并(正确完成)为Git提供了更健康的历史记录和更多信息.如果您了解分支和合并的工作原理,那么您将从Git中获得更多收益.
While squash & merge is simpler, merging (done right) provides a healthier history and more information for Git to work from. You'll get more out of Git if you understand how branching and merging works.
这篇关于Github的"Squash and Merge" -随后的拉取请求显示所有先前的更改的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!