23

为测试 bug 的解决方案而创建的 git 分支的当前最佳实践是什么,但由于审查过程表明它们是错误的或有更好的问题解决方案而没有被合并?

一个例子。项目 fizzbuzz 有一个错误报告,报告空字段崩溃。

  • 我创建了一个新分支handle-empty-fields并对该分支进行了两次提交,“解决”了问题。
  • 然后我将该分支提交给 fizzbuzz 项目经理,并将其链接到错误报告中。
  • 有人在我的修复中发现了一个错误,编写了另一个补丁,并且该补丁被接受了。

现在handle-empty-fields我的代码中的代码没用了:它不正确,不能再应用于代码,但在那个错误报告中已经引用了它。

我应该怎么办?保留分支?我很快就会得到几十个废弃的分支,而 git 无法将一个分支标记为废弃或关闭。删除分支?但随后查看该错误报告的人会发现它并得到 404。

人们经常被建议不要对他们的存储库进行rebase,因为这会给其他开发人员带来问题,尤其是下游开发人员。对功能或错误修复分支有什么建议?

更新:看起来 github 从不删除拉取请求中包含的提交。因此,如果您推送更改并将它们转换为拉取请求,您可以稍后删除分支而不会丢失任何更改。好吧,虽然 github 仍在工作;)。

4

4 回答 4

16

我这样做的方法是给它一个标签。使用完整的标签并给它一个描述性的名称。然后您可以删除该分支,因此它不会显示在您的分支列表中,但由于它已被标记,因此仍然可以通过签出该分支来重新创建该分支。标签上的所有提交仍然可用,并且您不会丢失git gc像这样的东西中的任何提交,也许:

git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX"
于 2012-01-24T15:55:14.520 回答
12

git update-ref refs/Attic/handle-empty-fields refs/heads/handle-empty-fields

作为在标签中保留死分支的替代方法,您可以使用单独的 refs 命名空间。好处是标签列表保持整洁。缺点是从瓷器转移到 git 的管道级别。

于 2012-06-21T17:40:02.667 回答
2

我认为这将取决于具体情况。可能的解决方案:

  • 在 bug 报告中添加注释,表明提到的分支原来是没用的,被删除了。如果你觉得这个分支有一些价值,简要描述你做了什么。这样,即使分支机构消失了,人们也可以获得必要的信息。

  • 保留分支,但以某种方式将其重命名以将其标记为“已放弃”。在错误报告中添加注释以表明这一点(并更改分支的链接)。例如,您可以有一些约定,例如在分支名称前加上“OLD-”。

  • 标记分支,然后将其删除(并在错误数据库条目中再次提及)。这样可以删除分支,但仍然可以通过标签访问提交。请注意,git 为标签(和分支)提供了简单的名称空间 - 您可以在名称中包含“/”。您可以就约定达成一致,例如在“oldbranch/”下使用标签。(改编自 Abizern 的回答。

  • 合并分支后,您可以在错误报告中提及/链接合并提交。那么分支可能就没那么有趣了,因为它包含在合并提交中。

通常,您可能希望对错误修复分支采用特殊的命名约定。

在我的(个人)git repo 中,对于我发现的每个错误,我首先在错误数据库中打开一个错误。如果我随后处理它,我会创建一个名称以错误 ID 结尾的分支(例如“opencrash-342”、“handle_empty_file-663”)。这样,bug DB 和分支之间的关系就很明显了。

此外,如果分支列表太长,您总是可以按附加的 ID 进行过滤(例如,列出已关闭的错误,以及一些小脚本将这些从“git log”的输出中过滤掉等)。

于 2012-01-24T15:49:35.237 回答
1

这只是我的观点,但我想你可以随意放弃任何没有有用代码的分支。在最坏的情况下,如果有人有一天会查看错误报告并发现指向被拒绝的错误修复的链接已损坏......好吧,我认为这对任何人来说都不是一个大问题。

于 2012-01-24T15:34:01.073 回答