gitリポジトリの命名規則はありますか？

たとえば、Purchase ServiceというRESTfulなサービスがあります。リポジトリに名前を付けますか？

1. purchaserestservice
2. purchase-rest-service
3. purchase_rest_service
4. または、他の何か？

慣習は何ですか？Githubではどうですか？公開リポジトリはいくつかの標準に従うべきですか？

私は行くだろうpurchase-rest-service。理由：

1. 「パーチェスレストサービス」とは？長い連結された単語は理解しにくいです。私はドイツ人です。「Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung。」

2. 「_」は「-」よりも入力が難しい

キャメルケースの問題は、単語の解釈が異なることが多いことです。たとえば、checkinServiceとcheckInServiceです。アーロンの答えに沿って、同じ名前のリポジトリが多数ある場合、オートコンプリートでは、気になるリポジトリを作成した人が大文字と小文字の特定の内訳を使用しているかどうかを常に確認する必要があります。大文字は避けてください。

ダッシュに関する彼のポイントもよく知られています。

1. 小文字を使用します。
2. ダッシュを使用します。
3. 具体的に。後で同様のアイデアを区別する必要がある場合があります。つまり、サービスや休憩サービスの代わりに購入/休憩サービスを使用します。
4. 一貫している。さまざまなGITベンダーからの使用を検討してください-リポジトリをどのようにソート/グループ化したいですか？

lowercase-with-hyphens GitHubで最もよく目にするスタイルです。*

lowercase_with_underscores おそらく私が目にする2番目に人気のあるスタイルです。

前者はキーストロークを節約するため、私の好みです。

^{*逸話的; データを収集していません。}

特定のネーミング選択を優先することなく、git repoは選択した任意のルートディレクトリに複製できることに注意してください。

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

ここでディレクトリにrepo.git複製されmyDirます。

したがって、パブリックリポジトリの命名規則がわずかに不正確になったとしても、クライアント側で修正することは可能です。

そのため、クライアントが自分のやりたいことをすべて実行できる分散環境では、Gitリポジトリの命名規則は実際にはありません。
（リポ ' 'のベアフォームxxx.git用に「」を予約することを除いて） RESTサービスには命名規則がある可能性があります（「REST APIの命名規則ガイドラインはありますか？」と同様）。しかし、それは別の問題です。xxx

多分それは私のJavaとCの背景を示しているだけかもしれませんが、名前の句読点よりもCamelCase（CapCase）を好みます。私のワークグループはそのような名前を使用しており、おそらくリポジトリに含まれるアプリまたはサービスの名前と一致させるためです。

PHPパッケージの作成を計画している場合は、Packagistに入れて、他のcomposerで使用できるようにすることをお勧めします。Composerには、使用する命名規則としてvendorname/package-name-is-lowercase-with-hyphens。

JSパッケージを作成する場合は、npmを使用することをお勧めします。命名規則の 1つパッケージ名の途中で大文字を許可しないことです。

したがって、PHPおよびJS lowercase-with-hyphensパッケージで、GitHub上のパッケージと同じようにcomposerまたはnpmでパッケージを使用して名前を付けることをお勧めします。