在GitHub上提取请求后你如何处理你的分支？

Question

我的团队正在尝试使用GitHub拉取请求进行代码审查.我唯一的问题是你做完后你对分公司做了什么？我认为你想要删除分支,但由于GitHub隐藏了已经合并到当前分支的分支,所以似乎我应该保留它.

只是好奇你对这方面的最佳实践的看法.

Answer 1

我们使用的经验法则(这里是Stack Overflow的某些部分)是"分支是为了工作,标签是为了历史".

每当合并一个分支(最有可能成为master)时,我们使用带有前缀"branch"的分支的名称来标记合并点(例如branch-topic).然后删除分支.如果我们需要在分支点恢复工作,我们有标签能够做到这一点.

当然也有例外.我们有长期运行的分支机构,我们用于各种继续工作.但一般来说,合并后会删除主题分支.

在这方面,这些合并总是完成

merge --no-ff <branch>

这可确保存在合并点和合并记录.

Answer 2

请注意,自2013年4月10日" 重新设计的合并按钮 "后,将删除该分支:

合并后删除分支也已简化.
我们不会通过额外步骤确认删除,而是在删除分支时立即删除分支,并提供方便的链接以便在您再次需要时恢复分支.

这证实了合并拉取请求后删除分支的最佳实践.

Answer 3

我总是删除已合并的分支master.毕竟,Git分支是指向提交的指针,并且该提交现在在另一个分支的历史记录中可用,因此我不再需要该分支.(您始终可以通过查看合并提交的父级来重新创建分支.)