何时才是删除git功能分支的正确时间？

88

我不想最后出现82个特征分支，因此我想知道将特征分支合并到母版后立即删除特征分支的潜在缺点。

工作流程：

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

这里有什么问题吗？

git version-control branch

— bstpierre
source

1

我不会说任何问题，因为如果您确实需要它们，则以后可以随时恢复已删除的分支。

— slebetman'8

@slebetman据我所知，已删除的分支无法恢复。但是，如果该分支在删除之前已完全合并到master中，则不再需要该分支。

— Simeon，

1

@Simeon是的，可以。Git从不删除提交，因此，当您删除分支时，您只是删除其名称。要恢复已删除的分支，您只需要记住您对该分支所做的最后一件事情，就可以搜索git reflog它。然后签出哈希

— slebetman

@slebetman，只有在分支最终合并后才会成立。如果将这些提交遗忘了，它们最终将变得无法访问，并且将在一定时间后进行垃圾回收。即使reflog中的条目最终也将被清除，默认情况下您大约有90天。

— Goldenratio '18年

@goldenratio：有什么参考吗？

— slebetman '18

61

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

我可以考虑保留一个分支的原因有几个：您可能希望保留它，以防一旦它投入生产后就会有错误回来，或者您想要历史记录。

无论哪种情况，都可以选择在删除分支之前对其进行标记。标签就像分支一样，它是一个指向提交的指针，除了一些细微的区别：1）瓷通常在结帐时不在git show-branch或tab-autocomplete等探索性命令中显示标签，2）检出一个会使您进入一个独立的（非引用）头3）您可以留下“标记消息”，这会将标记像提交一样另存为对象存储中的对象。

这样，您可以保留历史记录，并且如果确实需要进行错误修复，则建议您仅在master的基础上创建一个新分支以进行修复。

— 石匠
source

1

签出标签会设置HEAD，但不会自动创建分支。没有分支的提交上的HEAD是使其分离的原因。

— Binarian

1

没错，它将HEAD设置为提交ID而不是引用。我的那部分操作不正确。我应该更新它。

— masonk '17

96

合并后删除，但我总是做一个git merge --no-ff，以避免快速转发，这样分支历史记录就可以在图形上看到。我喜欢具有功能分支从开发分支离开的地方以及它在哪里加入的历史：

有无快速合并

这取自Vincent Driessen的一个成功的Git分支模型，这是一个非常好的git工作流，我将其应用于大多数项目。

— 克拉德
source

这是保存历史记录的另一种不错的方法，因为您可以从功能中选择可访问的提交，但不能从主服务器中选择：rev ^ 1..rev ^ 2。不利的一面是，它搞砸了您可能希望从master分支进行的所有基础调整（例如，如果您想使master重新基于上游远程服务器，这是很常见的）。

— masonk，2010年

1

我没有那个问题。我们的团队通过github进行同步，我通常不需要调整基准，但是我认为这没有不利之处。即使重新建立了development和feature分支的基础，该分支在图上仍然可见，重要的是feature分支相对于开发的内容，而不是创建该分支时最初离开的提交。

— lkraider

@Ikraider，谢谢您的提醒。我第一次学习git时看到了该文章，现在对我来说更有意义。我重新建立了功能分支的基础，但是我merge --no-ff又回到了母版，因为就像您说的那样，您可以看到历史记录。

— bstpierre

7

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

有机会将它还给您，以进行上游工作。
其他开发人员可能想要该功能，而无需掌握master中的其他功能。

实际上，大多数时候合并后删除就可以了。

— 卡尔·比勒费尔特
source

6

典型的工作流程将是

 // 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

— 费泽汗
source

1

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

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

— 第二
source

所以保留分支确实没有意义，对吧？

— bstpierre

1

我强烈建议避免“变基”。变基通常是有害的，仅在某些情况下有用。

— Dietrich Epp 2010年

9

对于您的本地，私人分支机构而言，重新定价是一个非常合理的工作流程。这是很常见的基础重建的实例（“基础重建与上游工作同步，以保持下来”）。重新建立基础*的情况很少见，而且通常有害。second的答案实际上没有任何意义，因为无论您是在基础调整还是合并上游变更，您都仍然必须以某种方式“推动”这些工作。即使在您的本地分支机构中，您也必须在某个时候合并功能以掌握。保持基于功能的基础的优点是此合并将快速进行。

— masonk，2010年

1

不过，重新部署分支还是需要提防一些问题，最近这让我很头疼。现在很明显，但是我在一个长期存在的分支上呆了几个月，总是把整个事情都依赖于master。它最终完成了约600笔细粒度的提交，但是master被疯狂地重构，并且大约被多次更改。通过每次重新建立整个分支的基础，我将其较旧的提交从它们的连接削减为对他们有意义的主提交。现在，我更喜欢在需要时合并在master中。如果分支的历史记录绝对不会受到影响，我只会进行基准调整。

— Gary Fixler