什么时候是删除 git 功能分支的合适时机？

When is the right time to delete a git feature branch?

提问by bstpierre

I don't want to end up with 82 feature branches hanging around, so I'm wondering what the potential drawbacks are to simply deleting the feature branch as soon as I merge it to master.

我不想最终有82 个功能分支挂在周围，所以我想知道在我将它合并到 master 后简单地删除功能分支有什么潜在的缺点。

Workflow:

工作流程：

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Any issues here?

这里有什么问题吗？

采纳答案by masonk

Delete after merge is the usual way. This is why git branch -d yourbranchnamechecks to make sure that the branch is fully merged before it will delete.

合并后删除是通常的方式。这就是为什么git branch -d yourbranchname在删除之前检查以确保分支完全合并的原因。

There are a few reasons that I can think of to keep a branch around: you might want to hold onto it in case you have bugs coming back once it hits production, or you might want a historical record.

我可以想到保留分支的几个原因：您可能希望保留它，以防在它投入生产后出现错误，或者您可能想要一个历史记录。

In either case, you have the option of tagging the head of the branch before you delete it. A tag is like a branch in that it is a pointer to a commit, except for a few minor differences: 1) porcelain usually doesn't display tags in exploratory commands like git show-branch or tab-auto complete in checkout, 2) checking one out puts you in a detached (non-ref) HEAD 3) you can leave a "tagging message", which causes the tag to be saved as an object in the object store like a commit.

在任何一种情况下，您都可以选择在删除之前标记分支的头部。标签就像一个分支，因为它是一个提交的指针，除了一些细微的区别：1）瓷器通常不会在像 git show-branch 或 tab-auto complete 这样的探索性命令中显示标签，2）检查一个结果会让你进入一个分离的（非引用）HEAD 3）你可以留下一个“标记消息”，这会导致标记像提交一样被保存为对象存储中的对象。

This way you preserve history, and if you ever do need to bug fix, I recommend just creating a new branch off of master for the fix.

通过这种方式，您可以保留历史记录，如果您确实需要修复错误，我建议您只需在 master 之外创建一个新分支来进行修复。

回答by lkraider

I delete after merge, but I always do a git merge --no-ff, to avoid fast forwarding so that the branch history is visible on the graph. I like to have the history of where the feature branch departed from the development branch and where it joined back:

我在合并后删除，但我总是执行git merge --no-ff, 以避免快速转发，以便在图表上可以看到分支历史记录。我喜欢记录功能分支从开发分支离开和重新连接的历史：

This is taken from A successful Git branching modelby Vincent Driessen, a very nice workflow to use with git which I apply for most of my projects.

这取自Vincent Driessen 的一个成功的 Git 分支模型，这是一个与 git 一起使用的非常好的工作流程，我在我的大多数项目中都使用了它。

回答by Karl Bielefeldt

I can think of two reasons why you might want to keep a feature branch around for a bit:

我可以想到两个原因，为什么您可能希望保留一个功能分支一段时间：

• There is a chance it will get kicked back to you for more work by upstream.
• Other developers possibly wanting that feature without wanting everything else in master.

• 它有可能会被上游踢回给你做更多的工作。
• 其他开发人员可能想要该功能而不想要 master 中的所有其他内容。

In practice, most of the time deleting after merge is just fine.

在实践中，大多数时候在合并后删除就可以了。

回答by Fizer Khan

Typical workflow will be

典型的工作流程是

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

回答by second

i think that is the typical workflow (deleting after merge)

我认为这是典型的工作流程（合并后删除）

EDIT So, rather than merge, at least for short lived branches, i think the idea is to rebase them on to the master. then you end up with a linear change history, and the entire branch becomes part of the main trunk. in this case you have all the changes there so you clearly don't need a copy.

编辑因此，至少对于短期分支而言，与其合并，我认为这个想法是将它们重新建立在 master 上。那么你最终会得到一个线性的变化历史，整个分支成为主干的一部分。在这种情况下，您拥有所有更改，因此您显然不需要副本。