git仓库是否有命名约定？

本文翻译自：Is there a naming convention for git repositories?

For example, I have a RESTful service called Purchase Service. 例如，我有一个称为购买服务的RESTful服务。 Should I name my repository: 我应该命名我的存储库：

1. purchaserestservice
2. purchase-rest-service
3. purchase_rest_service
4. or something else? 或者是其他东西？

What's the convention? 有什么约定？ How about in Github? 在Github中怎么样？ Should public repositories follow some standard? 公共存储库是否应遵循某些标准？

---

#1楼

参考：https://stackoom.com/question/O871/git仓库是否有命名约定

---

#2楼

I'd go for purchase-rest-service . 我purchase-rest-service 。 Reasons: 原因：

1. What is "pur chase rests ervice"? 什么是“追逐服务”？ Long, concatenated words are hard to understand. 冗长的单词难以理解。 I know, I'm German. 我知道，我是德国人。 "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung." “Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung。”

2. "_" is harder to type than "-" “ _”比“-”更难键入

---

#3楼

Without favouring any particular naming choice, remember that a git repo can be cloned into any root directory of your choice: 在不偏爱任何特定命名选择的情况下，请记住，可以将git repo克隆到您选择的任何根目录中：

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

Here repo.git would be cloned into the myDir directory. 在这里repo.git将被克隆到myDir目录中。

So even if your naming convention for a public repo ended up to be slightly incorrect, it would still be possible to fix it on the client side. 因此，即使您对公共存储库的命名约定最终略有错误，也仍然可以在客户端进行修复。

That is why, in a distributed environment where any client can do whatever he/she wants, there isn't really a naming convention for Git repo. 这就是为什么在任何客户都可以做他/她想要的事情的分布式环境中，对于Git回购实际上没有命名约定的原因。
(except to reserve " xxx.git " for bare form of the repo ' xxx ') （除了为xxx.git “ xxx ”的裸形式保留“ xxx.git ”外）
There might be naming convention for REST service (similar to " Are there any naming convention guidelines for REST APIs? "), but that is a separate issue. 可能有REST服务的命名约定（类似于“ REST API是否有任何命名约定指南？ ”），但这是一个单独的问题。

---

#4楼

Maybe it is just my Java and C background showing, but I prefer CamelCase (CapCase) over punctuation in the name. 也许只是我的Java和C背景显示，但我更喜欢CamelCase（CapCase）而不是标点符号。 My workgroup uses such names, probably to match the names of the app or service the repository contains. 我的工作组使用此类名称，可能与存储库包含的应用程序或服务的名称匹配。

---

#5楼

The problem with camel case is that there are often different interpretations of words - for example, checkinService vs checkInService. 驼峰式案例的问题在于，通常会有不同的单词解释-例如，checkinService与checkInService。 Going along with Aaron's answer, it is difficult with auto-completion if you have many similarly named repos to have to constantly check if the person who created the repo you care about used a certain breakdown of the upper and lower cases. 遵循Aaron的回答，如果您有许多类似名称的回购协议，而不得不不断检查您所关心的回购协议的人是否使用了大小写的某种分类，那么自动完成很难。 avoid upper case. 避免大写。

His point about dashes is also well-advised. 他关于破折号的观点也是明智的。

1. use lower case. 使用小写。
2. use dashes. 使用破折号。
3. be specific. 请明确点。 you may find you have to differentiate between similar ideas later - ie use purchase-rest-service instead of service or rest-service. 您可能会发现以后必须区分相似的想法-即使用购买休息服务而不是服务或休息服务。
4. be consistent. 始终如一。 consider usage from the various GIT vendors - how do you want your repositories to be sorted/grouped? 考虑各种GIT供应商的使用情况-您如何对存储库进行排序/分组？

---

#6楼

lowercase-with-hyphens is the style I most often see on GitHub.* lowercase-with-hyphens是我在GitHub上最常看到的样式。*

lowercase_with_underscores is probably the second most popular style I see. lowercase_with_underscores可能是第二流行的风格。

The former is my preference because it saves keystrokes. 前者是我的偏爱，因为它可以节省击键次数。

^{* Anecdotal; *轶事； I haven't collected any data. 我还没有收集任何数据。}