¿Existe una convención de nomenclatura para los repositorios git?

Por ejemplo, tengo un servicio RESTful llamado Servicio de compra. ¿Debo nombrar mi repositorio?

1. purchaserestservice
2. purchase-rest-service
3. purchase_rest_service
4. ¿o algo mas?

¿Qué es la convención? ¿Qué tal en Github? ¿Deben los repositorios públicos seguir algún estándar?

Yo iría a purchase-rest-service. Razones:

1. ¿Qué es el "servicio de compras en línea"? Las palabras largas y concatenadas son difíciles de entender. Lo sé, soy alemán. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung".

2. "_" es más difícil de escribir que "-"

El problema con el caso del camello es que a menudo hay diferentes interpretaciones de las palabras, por ejemplo, checkinService vs checkInService. Siguiendo la respuesta de Aaron, es difícil con la finalización automática si tiene muchos repositorios con nombres similares para tener que verificar constantemente si la persona que creó el repositorio que le interesa utilizó un cierto desglose de las mayúsculas y minúsculas. evitar mayúsculas

Su punto sobre los guiones también está bien aconsejado.

1. use minúsculas.
2. usa guiones.
3. se específico. es posible que tenga que diferenciar ideas similares más adelante, es decir, utilice el servicio de compra-descanso en lugar del servicio o el servicio de descanso.
4. se consistente. considere el uso de varios proveedores de GIT: ¿cómo desea que se ordenen / agrupen sus repositorios?

lowercase-with-hyphens es el estilo que más veo en GitHub. *

lowercase_with_underscores Es probablemente el segundo estilo más popular que veo.

El primero es mi preferencia porque ahorra pulsaciones de teclas.

^{* Anecdótico; No he recopilado ningún dato.}

Sin favorecer ninguna opción de nomenclatura en particular, recuerde que un repositorio de git se puede clonar en cualquier directorio raíz de su elección:

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

Aquí repo.gitsería clonado en el myDirdirectorio.

Por lo tanto, incluso si su convención de nomenclatura para un repositorio público resultó ser ligeramente incorrecta, aún sería posible solucionarlo en el lado del cliente.

Es por eso que, en un entorno distribuido donde cualquier cliente puede hacer lo que quiera, no hay realmente una convención de nomenclatura para el repositorio de Git.
(excepto para reservar " xxx.git" para la forma simple del repositorio ' xxx')
Puede haber una convención de nomenclatura para el servicio REST (similar a " ¿Hay alguna pauta de convención de nomenclatura para las API REST? "), pero ese es un problema por separado.

Tal vez solo se muestre mi fondo Java y C, pero prefiero CamelCase (CapCase) sobre la puntuación en el nombre. Mi grupo de trabajo usa dichos nombres, probablemente para que coincidan con los nombres de la aplicación o el servicio que contiene el repositorio.

Si planea crear un paquete PHP, lo más probable es que quiera ponerlo en Packagist para que esté disponible para otros con el compositor. Composer tiene la convención de nomenclatura para usar vendorname/package-name-is-lowercase-with-hyphens.

Si planea crear un paquete JS, probablemente quiera usar npm. Una de sus convenciones de nomenclatura es no permitir letras mayúsculas en el medio del nombre de su paquete.

Por lo tanto, recomendaría que los paquetes PHP y JS usen lowercase-with-hyphensy nombren sus paquetes en composer o npm de forma idéntica a su paquete en GitHub.