Proyecto vs Repositorio en GitHub

En GitHub, ¿cuál es la diferencia conceptual entre un proyecto (que se puede crear dentro de un repository) y un repository?

He visto varias preguntas similares ( aquí , aquí y aquí ) en SO, pero ninguna de ellas explica qué es un proyecto de GitHub, qué es un repository de GitHub y cuándo usar cada una de ellas.

Agradecería que alguien pudiera explicar cada término y proporcionar un ejemplo de cuándo usar / crear cada uno. Por ejemplo, si tengo varias aplicaciones prototipo, todas independientes entre sí, ¿qué creo para gestionar de manera organizada el código fuente de todas ellas?

GitHub recientemente presentó una nueva característica llamada Proyectos . Esto proporciona una placa visual que es típica de muchas herramientas de gestión de proyectos:

Proyecto

Un repository documentado en GitHub:

Un repository es el elemento más básico de GitHub. Son más fáciles de imaginar como la carpeta de un proyecto. Un repository contiene todos los files del proyecto (incluida la documentation) y almacena el historial de revisión de cada file. Los repositorys pueden tener múltiples queueboradores y pueden ser públicos o privados.

Un proyecto según lo documentado en GitHub:

Los paneles de proyectos en GitHub lo ayudan a organizar y priorizar su trabajo. Puede crear paneles de proyectos para funciones específicas, hojas de ruta completas o incluso lists de control de versiones. Con los paneles de proyectos, tiene la flexibilidad de crear flujos de trabajo personalizados que se adapten a sus necesidades.

Parte de la confusión es que la nueva característica, Proyectos, entra en conflicto con el uso sobrecargado del término proyecto en la documentation anterior.

Hecho 1: los proyectos y repositorys siempre fueron sinónimos en GitHub.
Hecho 2: este ya no es el caso.

Hay mucha confusión sobre repositorys y proyectos. En el pasado, los dos usuarios usaban los términos de forma bastante intercambiable y la propia documentation de GitHub. Esto se refleja en algunas de las respuestas y comentarios aquí que explican las diferencias sutiles entre esos términos y cuando uno fue preferido sobre el otro. La diferencia siempre fue sutil, por ejemplo, como el rastreador de problemas que forma parte del proyecto, pero no el repository que podría considerarse una cosa estrictamente idiota, etc.

Ya no.

Actualmente, los repos y los proyectos se refieren a diferentes types de entidades que tienen API separadas:

Desde entonces ya no es correcto llamar al repository un proyecto o viceversa. Tenga en count que a menudo se confunde en la documentation oficial y es desafortunado que un término que ya se usaba ampliamente haya sido elegido como el nombre de la nueva entidad, pero este es el caso y tenemos que vivir con eso.

La consecuencia es que los repos y los proyectos generalmente se confunden y cada vez que lees sobre los proyectos de GitHub debes preguntarte si realmente se trata de los proyectos o de los repos. Si hubieran elegido algún otro nombre o una abreviatura como "proj", entonces podríamos saber que lo que se discute es el nuevo tipo de entidad, un object preciso con properties concretas, o un tipo de cosa de tipo proyectista de habla general.

El término que generalmente no es ambiguo es "junta de proyecto" .

¿Qué podemos aprender de la API?

El primer punto final en la documentation de la API de proyectos:

se describe como: Listar proyectos de repository . Significa que un repository puede tener muchos proyectos. Entonces esos dos no pueden significar lo mismo. Incluye respuesta si los proyectos están deshabilitados :

{ "message": "Projects are disabled for this repo", "documentation_url": "https://developer.github.com/v3" } 

lo que significa que algunos repos pueden tener proyectos deshabilitados. Nuevamente, esos no pueden ser lo mismo cuando un repository puede tener proyectos deshabilitados.

Hay algunos otros puntos finales interesantes:

  • Crear un proyecto de repositoryPOST /repos/:owner/:repo/projects
  • Crear un proyecto de organizaciónPOST /orgs/:org/projects

pero no hay :

  • Crear un proyecto de usuarioPOST /users/:user/projects

Lo que nos lleva a otra diferencia:

1. Los repositorys pueden pertenecer a usuarios u organizaciones
2. Los proyectos pueden pertenecer a repositorys u organizaciones

o, más importante aún:

1. Los proyectos pueden pertenecer a repositorys pero no al revés
2. Los proyectos pueden pertenecer a organizaciones pero no a usuarios
3. Los repositorys pueden pertenecer a organizaciones y a usuarios

Ver también:

Los repositorys GitHub se utilizan para almacenar todos los files, carpetas y otros resources que le interesan.

Proyecto Git: también es uno de los Recursos en el Repositorio de Git y su uso principal es administrar los proyectos con un tablero visual. Si creas un proyecto en Git Repository, creas una placa visual como una placa Kanban para administrar el proyecto.

De esta manera, puede tener múltiples proyectos en un repository.

En general, en GitHub, 1 repository = 1 proyecto . Por ejemplo: https://github.com/spring-projects/spring-boot . Pero no es una regla dura.

1 repository = muchos proyectos . Por ejemplo: https://github.com/donhuvy/java_examples

1 proyectos = muchos repositorys . Por ejemplo: https://github.com/zendframework/zendframework (1 proyecto llamado Zend Framework 3 tiene 61 + 1 = 62 repositorys, no lo creo? Cuente los modules de Zend Frameworks + repository principal)

Estoy totalmente de acuerdo con el comentario de @Brandon Ibbotson :

Un repository GitHub es solo un "directory" donde pueden existir carpetas y files.

Esta es mi comprensión personal sobre el tema.

Para un proyecto, podemos hacer el control de la versión por diferentes repositorys. Y para un repository, puede administrar un proyecto completo o parte de proyectos.

En cuanto a su proyecto (varias aplicaciones prototipo que son independientes de cada uno de ellos). Puede gestionar el proyecto por un repository o por varios repositorys, la diferencia:

  1. Administrar por un repository. Si se cambia una de las aplicaciones, todo el proyecto (todas las aplicaciones) se comprometerá con una nueva versión.

  2. Administrar por varios repositorys. Si se cambia una aplicación, solo afectará al repository que administra la aplicación. La versión para otros repositorys no fue modificada.