在我们团队的存储库中,我们通过提交PR进行工作,并且仅使用github的squash&merge功能将它们合并为master。对我来说,问题在于我再也看不到分支与git branch --merged
合并为master了,因为这将不会显示已被压缩和合并的分支。我的当地分支机构堆积如山,很难一一查看,看看可以删除哪些分支。还有另一种列出它们的方法吗?
答案 0 :(得分:2)
tl; dr; 不幸的是,没有。您必须在GitHub上检查PR的状态,并在合并后用git branch -D
强行删除本地分支。
GitHub Squash and merge操作实际上并没有合并您的topic branch,而是将来自该分支的所有提交压缩为一个,然后对提交进行 rebases 在目标分支的顶部。
当您在GitHub上的请求中选择 Squash and merge (压缩并合并)选项时,该请求的提交将被压缩为单个提交。
最重要的部分:
使用快速转发选项合并具有压缩提交的拉请求。
fast-forward merge不会创建合并提交―它只是将目标分支引用向前移动,使其指向与源分支相同的提交。仅当源分支指向目标分支的后代时,才可以这样做。
因此,如果您的主题分支在本地存储库中看起来像这样:
master
v
o--o--o--o
\
A--B--C <- This is the branch you want to merge with a PR
^
topic
当您使用Squash and merge时,GitHub将重写您的topic
分支的历史记录,使其看起来像这样:
master
v
o--o--o--o
\
S <- This is A, B and C squashed together
^
topic
然后,GitHub将在topic
之上 master
。请注意,由于父级不同,这将导致提交与原始压缩的提交S
相差 。为了区别起见,我们将重新提交称为S'
( S prime ):
master
v
o--o--o--o
\
S'
^
topic
最后,topic
分支与fast-forward merge合并到master
中:
master
v
o--o--o--o--S'
^
topic
这一切都发生在GitHub服务器托管的存储库中。同时,在您的计算机上,存储库仍如下所示:
master
v
o--o--o--o
\
A--B--C
^
topic
在master
上完成git pull
之后,您将收到经过压缩和重新调整的提交S'
:
master
v
o--o--o--o--S'
\
A--B--C
^
topic
Git无法知道提交S'
包含A
,B
和C
的组合更改。这就是为什么它仍将topic
报告为未合并的原因。
一次Linus Torvalds wrote:
人们可以(也许应该)重建其 private 树(他们自己的树)的基础 工作)。这是清理。但是从来没有其他人编写代码。那是“破坏 历史”。
然后他继续:
您绝不能毁灭他人的历史。您不得重新设定基准 犯其他人所做的。基本上,如果没有您的签字 在它上面,它是不可行的:您不能重新设置它的基础,因为它不是您的。
显而易见,GitHub的Squash and merge功能通过完全重写其PR分支来破坏其他人的历史。
我不会坐在这里告诉你Squash and merge本质上是邪恶 ―我敢肯定它有用途。
但是,如果您的团队经常发现自己不得不处理陈旧的本地分支机构(如您所述),则您可能需要考虑切换到合并了PR的合并工作流,而这些PRs保持了现状。 >而不是销毁它。
答案 1 :(得分:0)
git branch --merged master
列出了合并为master的分支
git branch --merged
列出了合并到HEAD中的分支(即当前分支的尖端)
git branch --no-merged
列出尚未合并的分支
默认情况下,这仅适用于本地分支。 -a标志将显示本地和远程分支,而-r标志仅显示远程分支。
希望这会有所帮助。