我的团队正在尝试使用GitHub拉取请求进行代码审核。我想知道结束后该怎么处理分支?我认为你可能希望删除该分支,但由于GitHub会隐藏已合并到当前分支的分支,所以保留它似乎更好。
只是好奇您对此的最佳实践有什么看法。
我的团队正在尝试使用GitHub拉取请求进行代码审核。我想知道结束后该怎么处理分支?我认为你可能希望删除该分支,但由于GitHub会隐藏已合并到当前分支的分支,所以保留它似乎更好。
只是好奇您对此的最佳实践有什么看法。
我们使用的经验法则(在 Stack Overflow 的某个地方)是“分支用于工作,标签用于历史记录”。
每当一个分支被合并(很可能合并到主分支),我们使用带有前缀“branch”(例如 branch-topic)的分支名称标记合并点。然后删除该分支。如果需要在分支点处恢复工作,我们有标签来进行操作。
当然也有例外情况。我们有长期运行的分支,用于各种持续性工作。但一般来说,主题分支在合并后会被删除。
顺便提一下,这些合并总是使用
merge --no-ff <branch>
这将确保有一个合并点和合并发生的记录。
这证实了在拉取请求合并后删除分支的最佳做法。在你合并后删除分支也变得更加简单。
我们不再要求你确认删除步骤,而是立即在您删除时删除该分支,并提供一个方便的链接以在需要时恢复该分支。
git branch -D topic-branch
。正确吗? - javafueled我通常会删除已经合并到master
的分支。毕竟,Git分支是指向提交的指针,而该提交现在已经在另一个分支的历史记录中可用,因此我不再需要该分支。(您可以通过查看合并提交的父提交来重新创建该分支。)