git 存储库有命名约定吗？答案

【问题标题】：Is there a naming convention for git repositories?git 存储库有命名约定吗？
【发布时间】：2012-08-10 11:11:42
【问题描述】：

例如，我有一个名为 Purchase Service 的 RESTful 服务。我应该命名我的存储库吗：

purchaserestservice
purchase-rest-service
purchase_rest_service
还是别的什么？

什么是约定？在 Github 上怎么样？公共存储库应该遵循一些标准吗？

【问题讨论】：

这篇博文可能有用gravitydept.com/blog/…

标签： git github naming-conventions

【解决方案1】：

我会选择purchase-rest-service。原因：

什么是“购买休息服务”？长而连在一起的词很难理解。我知道，我是德国人。 “Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung。”
“_”比“-”更难输入

【讨论】：

我（真的）不明白，但你没有错过 ...auschreibung... 中的 S 吗？
@adimauro: 申请多瑙河轮船船长专利申请表的空缺职位。
您不喜欢camelCase的任何特殊原因？这是我常用的通用项目命名约定，因为它不使用特殊字符。
@10gistic 存储库名称经常出现在可能不区分大小写甚至转换为小写的 URL（例如在 github 上）中，因此 camelCase 是一个坏主意。我不认为 github 会这样做，但保存起来似乎更好。
GitHub 中的人使用连字符。 habrastorage.org/getpro/habr/post_images/d34/331/a8d/…

【解决方案2】：

驼峰式大小写的问题在于，通常对单词有不同的解释——例如，checkinService 与 checkInService。按照 Aaron 的回答，如果您有许多名称相似的存储库必须不断检查创建您关心的存储库的人是否使用了大写和小写的某种细分，那么自动完成是很困难的。避免大写。

他关于破折号的观点也很明智。

使用小写。
使用破折号。
要具体。稍后您可能会发现您必须区分相似的想法 - 即使用 purchase-rest-service 而不是 service 或 rest-service。
保持一致。考虑各种 GIT 供应商的使用情况 - 您希望如何对存储库进行排序/分组？

【讨论】：

您的回答涉及两个重要问题，而最佳答案却没有。
忘记是 checkin-service 还是 check-in-service 如何比忘记是 checkinService 还是 checkInService 好？
骆驼案对于非母语人士来说也更难。
@BenAveling 实际上没有。骆驼案似乎更容易正确阅读。 citeseerx.ist.psu.edu/viewdoc/…

【解决方案3】：

lowercase-with-hyphens 是我在 GitHub 上最常看到的样式。*

lowercase_with_underscores 可能是我看到的第二受欢迎的风格。

前者是我的首选，因为它可以节省击键次数。

^{* 轶事；我没有收集任何数据。}

【讨论】：

连字符也有 SEO 优势。这可能不是主要考虑因素，但由于我们有点在谈论 URL，所以它是相关的。
连字符还有另一个优点：它们更容易在带下划线的超链接中被发现（下划线可能很容易被误认为是空格）。
如你所说，很难收集数据，但我去了github.com/trending/developers，只看到了之前提到的样式：lowercase-with-hyphens

【解决方案4】：

在不偏爱任何特定命名选择的情况下，请记住 git repo 可以克隆到您选择的任何根目录中：

git clone https://github.com/user/repo.git myDir

这里的repo.git 将被克隆到myDir 目录中。

因此，即使您对公共 repo 的命名约定最终有点不正确，仍然可以在客户端进行修复。

这就是为什么在任何客户端都可以为所欲为的分布式环境中，Git 存储库没有真正的命名约定。
（除了为 repo 'xxx' 的 bare 形式保留“xxx.git”）
REST 服务可能有命名约定（类似于“Are there any naming convention guidelines for REST APIs?”），但这是一个单独的问题。

【讨论】：

好点。但是，在客户端修复 repo 名称在一定程度上证明了命名约定会有所帮助。你不觉得吗？如果它首先遵循约定，为什么要修复它？也许maven对我影响很大。
@AdrianM 我的观点是：是的，命名约定很有用，但它与 Git 或 GitHub 无关，与你想对那个特定的 repo 做的一切都无关。因此，您的问题的答案是“不，没有 git 存储库的命名约定”。

【解决方案5】：

也许这只是我的 Java 和 C 背景显示，但我更喜欢 CamelCase (CapCase) 而不是名称中的标点符号。我的工作组使用这样的名称，可能是为了匹配存储库包含的应用程序或服务的名称。

【讨论】：

这篇文章很稀疏，这不是我个人的偏好，但他仍然提到了一个好处，Java 中的项目名称是驼峰式的，并且在一致性上有一些安慰。我们确定这里的反对意见不仅仅是一种命名偏见吗？
同意。其他答案讨论了 camelCase 的缺点，但在 Java 世界中，无论如何决定 camelCase 更好是完全合理的......尤其是对于对 Windows 世界一无所知的项目。
学究式公益公告：PascalCase 不是 camelCase。
@MarredCheese 我公司有个人坚持称其为“上骆驼案”，我想把午餐扔给他。

【解决方案6】：

如果您打算创建一个 PHP 包，您很可能希望将其放入 Packagist 以使其可用于其他作曲家。 Composer 拥有naming-convention 以使用vendorname/package-name-is-lowercase-with-hyphens。

如果你打算创建一个 JS 包，你可能想要使用 npm。他们的naming conventions 之一是不允许在您的包名称中间出现大写字母。

因此，我建议 PHP 和 JS 包使用 lowercase-with-hyphens 并在 composer 或 npm 中将包命名为与 GitHub 上的包相同。

【讨论】：