较小的错误修复和较小的功能哪个更合适-通过故障单编号命名分支或通过功能描述命名分支？

10

我对正确的分支命名存在分歧（当然是顺服）。这适用于错误修复和小型功能分支，不适用于长时间运行的功能分支。对于长期运行的功能分支，我们同意人类可读的名称更好。这是两种观点：

矿：

根据团队和票号命名分支更好。这样可以更轻松地在我们的票务系统中找到它们，并且打字更短。当查找有关票证的历史信息时，这也使查找GIT中的相关分支变得更加容易。

例：

team-name/12345
team-name/53719

他的：

根据分支的特征/功能命名。与单个数字相比，它更容易自动完成，并且更容易记住。

例：

team-name/fix-that-sql-bug
team-name/expand-http-parser

我提供的一个折衷方案是：

team-name/12345-fix-that-sql-bug

但是他不喜欢这样，因为它与GIT自动完成功能混为一谈。

如果这主要是基于意见的，请随时为我提供指导，以指导如何使其更适合SO-但我认为可以修改/补充我给出的理由以给出经验答案。

— 编码员
source

以我的经验，为小错误修复和小功能的分支的最佳命名通常是主干（早期合并，经常合并=>在没有充分理由的情况下无需隔离更改）。当然，这不适用于将关键修复程序向后移植到生产环境中运行的较旧版本代码的情况，对于这些代码而言，隔离已被证明是绰绰有余的（因此，自然而然地用票证命名分支是很自然的：毕竟，您没有做任何特别有意义的功能，只是在修复具有关键问题的具体关键生产错误）

— gnat 2013年

5

在这种情况下，似乎您都可以妥协一个同时具有数字和描述的命名约定：

例：

团队名称/（12345）-修复该SQL错误

团队名称/（53719）-展开-http-解析器

这里确实没有正确答案，这取决于您的观点是主观的。

但是，如果你们俩都妥协，那么您将两全其美。当我们在团队中存在类似分歧时，我会尽量记住这一点。

编辑：

为了解决自动完成问题，您可以将编号的ID放在方括号中，这样，当您键入一个分支时，您总是要键入（以查看分支。从此列表中，您将能够看到编号的ID和说明。只需输入几个数字，制表符，它将

— dmck
source

我同意，并且我补充了这一点-我认为不同意这种妥协是很愚蠢的。

— Codeman

自动完成功能仅从分支名称的开头开始起作用吗？您可以将ID放在末尾吗？我不使用自动完成功能，所以我不熟悉它。

— dmck

是的，它从头到尾都可以工作-如果要获取team-name/12345-my-ticket-fix，则必须键入team-name/123TAB。

— Codeman

@ Pheonixblade9有关可能的解决方案，请参见我的编辑，在ID之前应输入一个（，以防止您在输入分支名称时必须知道ID

— dmck

1

只要有一个大家都同意和理解的一致的系统，这真的无关紧要。

我要说的是，按票号排序会使事情更容易记住，以便在哪个分支上进行工作。因为它们直接与问题编号联系在一起，而不是说明。仅进行描述似乎确实使想起它应该是哪个特定问题变得更加困难，并且可能会竭尽全力避免模糊。

team-name/bug-that-has-specific-circumstances-to-occur-and-takes-alot-to-describe

— 施莱斯
source

0

仅仅为了利用自动完成功能而命名的东西是愚蠢的。

我同意，错误跟踪器的链接很重要（比一个好名字更重要，因为它准确地定义了几个单词无法解决的分支所要解决的问题），但与此同时，它的可用性不足以期望人们了解Bug＃7312和＃7213之间的区别。同样也无法期望人们每次都能得到正确的数字-某天某人会因为错误地读/错了7213的7213而错误地选择了错误的分支。（今天我们团队中的某个人这样做！）

两者都做-为分支编号并添加一个非常简短的文字说明，仅作为检查。我会把数字放在第一位-自动完成该死的-因为您仍然仍然必须知道该分支的文本（例如，“服务器的错误修正”或“服务器的错误修正”-您仍然需要知道如果以f或b开头！）

— gbjbaanb
source