Question

目前使用git分支创建的最佳实践是为了测试错误的解决方案并且尚未合并，因为审核流程显示错误或有更好的问题解决方案？

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

现在handle-empty-fields我的代码中的代码是无用的：它不正确，不能再应用于代码，但它已在该错误报告中引用。

我该怎么办？保持分支？我会很快结束几十个被遗弃的分支，而git无法将分支标记为已弃置或已关闭。删除分支？但随后人们会查看该错误报告并找到404.

通常建议人们不要重新设置他们的存储库，因为这会给其他开发人员带来问题，尤其是下游开发人员。有关功能或错误修复分支的建议是什么？

更新：看起来github永远不会删除pull请求中包含的提交。因此，如果您推送更改并将其转换为拉取请求，则可以稍后删除该分支而不会丢失任何更改。好吧，虽然github还在工作;）。

Answer 1

我这样做的方法是给它一个标签。使用完整标记并为其指定一个描述性名称。然后你可以删除分支，因此它不会显示在你的分支列表中，但是因为它被标记了，所以仍然可以通过检查分支来重新创建分支。标签上的所有提交仍然可用，并且您不会丢失git gc这样的提交，可能是：

git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX"

Answer 2

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

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

Answer 3

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

在错误报告中添加评论，表明所提到的分支结果是无用的并被删除。如果你觉得这个分支有一些价值，那就简要描述一下你做了什么。这样，即使分支机构消失，人们也会得到必要的信息。
保留分支，但不知何故重命名它以将其标记为“废弃”。在错误报告中添加注释以指示此情况（并更改指向分支的链接）。例如，您可以使用一些约定，例如将“OLD-”添加到分支名称前。
标记分支，然后将其删除（并在bug db条目中再次提及）。这样就可以删除分支，但仍然可以通过标记访问提交。请注意，git为标记（和分支）提供了简单的名称空间 - 您可以在名称中包含“/”。您可以就约定达成一致，例如在“oldbranch /”下使用标签。（改编自Abizern的回答。）
合并分支后，您可以在错误报告中提及/链接合并提交。然后分支可能不那么有趣，因为它包含在合并提交中。

通常，您可能希望采用特殊的命名约定来修复分支。

在我的（个人）git仓库中，对于我发现的每个bug，我首先在bug DB中打开一个bug。如果我然后处理它，我创建一个名称以错误ID结尾的分支（例如“opencrash-342”，“handle_empty_file-663”）。这样，bug DB和分支之间的关系是显而易见的。

此外，如果分支列表变得太长，您总是可以通过附加的ID进行过滤（例如，列出已关闭的错误，以及一些小脚本，以便从“git log”的输出中过滤掉这些等等。）

Answer 4

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