在GitHub上提交请求后，你对你的分支做了什么？ [英] What do you do with your branch after a pull request on GitHub?

问题描述

我的团队正在尝试使用GitHub pull请求进行代码评论。我唯一的问题是你完成后你对分支做了什么？我想你会想删除这个分支，但是因为GitHub隐藏了已经合并到你当前分支中的分支，所以似乎我应该保留它。

只是好奇你对这方面的最佳实践有什么想法。

我们使用的经验法则（这里是一些每当一个分支被合并（最有可能成为主）时，我们使用标记合并点来标记合并点具有前缀分支的分支的名称（例如分支主题）。然后删除分支。如果我们需要在分支点重新开展工作，我们的标签可以做到这一点。

当然有例外。我们有很长的分支机构，用于各种持续性工作。但一般来说，合并后删除了主题分支。

在这个笔记上，这些合并总是由

  merge --no-ff< branch> 
  

这确保有合并点和合并记录。

My team is experimenting with using GitHub pull requests for code reviews. My only question is what do you do with the branch after you're done? I would think you'd want to delete the branch, but since GitHub hides branches that have been merged into your current branch, it seemed like maybe I should keep it.

Just curious on what your thoughts on best practices for this are.

解决方案

The rule of thumb that we use (which is here some where on Stack Overflow) is "branches are for work, tags are for history".

Whenever a branch is merged (most likely into master) we tag the merge point using the name of the branch with the prefix "branch" (e.g. branch-topic). Then delete the branch. If we need to resurrect work at the branch point we have the tag to be able to do that.

There are of course exceptions. We have long running branches that we use for various kinds of continuing work. But in general, topic branches are deleted after merging.

On that note, those merges are always done with

merge --no-ff <branch>

This ensures that there is a merge point and a record of the merge occurring.

这篇关于在GitHub上提交请求后，你对你的分支做了什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！