您选择的{DVCS}中命名分支的良好命名约定

16

我们正在办公室中缓慢整合Mercurial，并开始使用命名分支进行Web开发。

不过，就命名分支机构而言，我们还没有找到很好的约定。

我们尝试了：

FeatureName（可以看到此导致的问题）
DEVInitial_FeatureName（当开发人员来来往往时可能会造成混淆）
{uniqueID（int）} _功能

到目前为止，uniqueID_featureName获胜了，我们正在考虑将其维护在一个小的数据库中，仅供参考。

它将具有：branchID（int），featureName（varchar），featureDescription（varchar），日期，谁等...

这将给我们这样的分支：1_NewWhizBangFeature，2_NowWithMoreFoo，...，并且我们可以轻松地参考该分支的功能，而不必检查日志。

有更好的解决方案吗？

version-control mercurial

— jfrobishow
source

14

如果您没有问题追踪器，建议您设置一个问题追踪器，然后使用{问题追踪器名称} _ {票号}。当几年后有人提出错误，并且您不确切知道该功能的工作方式时，可以很容易地对文件进行注释，然后返回到用户可能要求该功能的地方。

— 阿萨·艾尔斯（Asa Ayers）
source

同意我们有一个Bugtracker，并且计划使用分支名称中的bugID进行错误修复。我的问题更多是针对全新的开发，当您不修复任何东西而是添加全新的东西时。我想我们可以创建一个愚蠢的增强票据，然后从那里去。

— jfrobishow

5

您绝对应该为新功能创建票证。也是要跟踪的工作。+1需要唯一的ID。

— AShelly 2010年

如果您确定将新功能的所有详细信息都放入了跟踪器中，则稍后有人可以验证其是否按设计工作或是否确实存在错误。我在一个拥有5年以上历史的开发团队中工作。有时候，客户端会提交错误，而当我们对其进行研究时，我们发现它正在按设计工作，原始开发人员和原始请求者都消失了。我们有类似的情况，我们不知道为什么是这样，如果这些功能不在跟踪器中，我们将无法找到。

— 阿萨·艾尔斯

2

我建议保持简单，并根据FeatureName（或feature-name）约定命名分支。是的，这意味着共享的名称空间，但这在现实世界中很少出现问题。一旦完成一项功能并将其完全合并到主线中，就可以安全地删除该分支。

分布式版本控制的主要思想是应该易于分支，引入其他官僚机构，例如强制性的唯一ID，只会使这一过程变得更加困难。

— 亚当·伯特克
source

1

我同意，这是要走的路。在哪个世界中，您会有如此多的分支以至于您无法避免冲突？

— 替代

足够公平，将描述与名称关联起来对我们来说更重要...最初的提交应包含该名称，但我不知道有什么方法可以快速提取该名称。

— jfrobishow

1

在大型公司环境中，让开发人员为功能起名会或早或晚引起头痛。

— AShelly 2010年

1

我看到了，因为在“大型公司环境”中，开发人员无法被信任。但是，等等，它们也为变量，函数和文件组成名称。我们也应该成立一个委员会来控制它！（讽刺的）

— 亚当·伯特克

2

我建议使用这种形式（例如）：

BUG_ID
错误号
TICKET_ID
票号#ID
feature_bla-bla-bla
版本-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

只需选择合适的前缀（以允许从hg分支输出过滤器），大写规则和前缀与ID /名称之间的分隔符即可。

— 木通哥
source

最后，我们+1了BUGID_ {freeCamelCasedTextDescription}。

— jfrobishow 2011年