我的团队正在尝试使用 GitHub 拉取请求进行代码审查。我唯一的问题是你完成后如何处理分支？我认为您想删除该分支，但由于 GitHub 隐藏了已合并到您当前分支中的分支，所以我似乎应该保留它。
只是好奇您对此最佳实践的想法是什么。
问问题
20573 次
3 回答
36
我们使用的经验法则（这里是 Stack Overflow 上的某个地方）是“分支用于工作，标签用于历史”。
每当一个分支被合并（很可能合并到主分支中）时，我们使用带有前缀“branch”的分支名称（例如分支主题）来标记合并点。然后删除分支。如果我们需要在分支点恢复工作，我们有标签可以做到这一点。
当然也有例外。我们有长期运行的分支机构，可用于各种持续工作。但一般情况下，主题分支在合并后会被删除。
在那一点上，这些合并总是用
merge --no-ff <branch>
这确保存在合并点和合并发生的记录。
于 2011-10-26T16:28:23.410 回答
25
请注意，自 2013 年 4 月 10 日，“重新设计的合并按钮”以来，该分支已为您删除：
合并后删除分支也得到了简化。
我们不会通过额外的步骤确认删除，而是在您删除分支时立即删除它，并提供方便的链接以在您再次需要时恢复分支。
这证实了在合并拉取请求后删除分支的最佳实践。
于 2013-04-12T11:42:18.413 回答
14
我总是删除已合并到master. 毕竟，Git 分支是指向提交的指针，并且该提交现在在另一个分支的历史记录中可用，因此我不再需要该分支。（您始终可以通过查看合并提交的父级来重新创建分支。）
于 2011-10-26T14:23:13.037 回答