Existe-t-il une convention de dénomination pour les référentiels git?

Par exemple, j'ai un service RESTful appelé Service d'achat. Dois-je nommer mon référentiel:

1. purchaserestservice
2. purchase-rest-service
3. purchase_rest_service
4. ou autre chose?

Quelle est la convention? Et à Github? Les référentiels publics devraient-ils suivre une norme?

J'irais pour purchase-rest-service. Les raisons:

1. Qu'est-ce que le «pur chase rests ervice»? Les mots longs et concaténés sont difficiles à comprendre. Je sais, je suis allemand. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."

2. "_" est plus difficile à taper que "-"

Le problème avec le cas de chameau est qu'il existe souvent des interprétations différentes des mots - par exemple, checkinService vs checkInService. En accord avec la réponse d'Aaron, la saisie semi-automatique est difficile si vous avez de nombreux référentiels de même nom pour vérifier constamment si la personne qui a créé le référentiel que vous aimez utilise une certaine ventilation des majuscules et des minuscules. éviter les majuscules.

Son point sur les tirets est également judicieux.

1. utilisez des minuscules.
2. utilisez des tirets.
3. être spécifique. il se peut que vous deviez faire la différence entre des idées similaires plus tard - c'est-à-dire utiliser le service d'achat-repos au lieu du service ou du service de repos.
4. être cohérent. envisager l'utilisation des différents fournisseurs GIT - comment voulez-vous que vos référentiels soient triés / regroupés?

lowercase-with-hyphens est le style que je vois le plus souvent sur GitHub. *

lowercase_with_underscores est probablement le deuxième style le plus populaire que je vois.

Le premier est ma préférence car il enregistre les frappes.

^{* Anecdotique; Je n'ai collecté aucune donnée.}

Sans privilégier un choix de nommage particulier, n'oubliez pas qu'un dépôt git peut être cloné dans n'importe quel répertoire racine de votre choix:

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

Ici repo.gitserait cloné dans le myDirrépertoire.

Ainsi, même si votre convention de dénomination pour un dépôt public se révélait légèrement incorrecte, il serait toujours possible de la corriger côté client.

C'est pourquoi, dans un environnement distribué où tout client peut faire ce qu'il veut, il n'y a pas vraiment de convention de dénomination pour le dépôt Git.
(sauf pour réserver " xxx.git" à la forme nue du référentiel ' xxx')
Il peut y avoir une convention de dénomination pour le service REST (similaire à " Existe-t-il des directives de convention de dénomination pour les API REST? "), mais il s'agit d'un problème distinct.

Peut-être que c'est juste mon arrière-plan Java et C qui s'affiche, mais je préfère CamelCase (CapCase) à la ponctuation dans le nom. Mon groupe de travail utilise de tels noms, probablement pour correspondre aux noms de l'application ou du service que contient le référentiel.

Si vous envisagez de créer un package PHP, vous voudrez probablement mettre Packagist pour le rendre disponible pour d'autres avec composer. Composer a la convention de nommage as à utiliser vendorname/package-name-is-lowercase-with-hyphens.

Si vous prévoyez de créer un package JS, vous voudrez probablement utiliser npm. L'une de leurs conventions de dénomination consiste à ne pas autoriser les majuscules au milieu du nom de votre package.

Par conséquent, je recommanderais aux packages PHP et JS d'utiliser lowercase-with-hyphenset de nommer vos packages dans composer ou npm de manière identique à votre package sur GitHub.