【问题标题】:What to do with experimental non-merged git branches?如何处理实验性非合并 git 分支?
【发布时间】:2012-02-17 18:47:12
【问题描述】:

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

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

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

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

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

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

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

【问题讨论】:

标签: git github feature-branch


【解决方案1】:

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

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

【讨论】:

  • 这种类型的引用会被推送到远程仓库吗?
  • @gioele 它们是可推送的,因为任何 ref 都是可推送的。但默认情况下不会推送它们,需要在命令行或配置中使用适当的 refspec。
【解决方案2】:

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

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

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

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

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

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

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

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

【讨论】:

  • 过滤的问题是我可能是唯一安装了这样一个过滤脚本的人,其他人都会看到所有那些无用的分支。
【解决方案3】:

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

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

【讨论】:

  • 这是个好主意。不完美,因为它只是将问题从分支列表转移到标签列表,但至少标签列表很少被查阅,而分支列表是人们经常看到的东西。
  • 补充一点:您可以对标签采用一些命名约定,例如用“branch-”为短期分支的标签名称添加前缀。然后你可以过滤标签列表,或者只是排序。
【解决方案4】:

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

【讨论】:

    猜你喜欢
    • 2012-12-09
    • 2019-03-17
    • 1970-01-01
    • 2022-10-21
    • 2023-03-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多