Dos repositorys Git comparten código común

Entonces tengo un proyecto que tiene las partes del cliente y las partes del server. Me gustaría que el cliente y el código del server estén en diferentes repositorys de Git para una separación clara del código, sin embargo, comparten algunos de los files e, idealmente, los files compartidos siempre serán idénticos tanto en el cliente como en el server.

¿Cómo debo ir sobre esto? ¿Es mejor tener el tercer repository para el código común?

No daré consejos sobre "Cómo debes hacer esto". Pero explicaré cómo lograr la integración de un tercer repository con código común en los otros repositorys: este es un trabajo para los submodules de git. Los submodules de git le permiten hacer reference a una instantánea de un repository de git en una ruta especificada:

git submodule add git://example.com/repository.git path 

Luego crea una confirmación. Ahora se hace reference a una instantánea del repository dado en la path .

Poblando el submodule

  1. Ejecutar git submodule init
  2. Ejecutar la git submodule update

Cada submodule configurado se actualizará para que coincida con el estado que se supone que debe tener.

Actualizar un submodule a un compromiso posterior

  1. Cambiar al directory del submodule
  2. Realice un git pull / git fetch + git checkout para actualizar el submodule a la confirmación / label deseada
  3. Crea una nueva confirmación para actualizar la confirmación en el file .gitmodules

Eche un vistazo al manual oficial para get más información sobre los submodules.

Si comparten un código común, veo dos opciones sensatas. Separe el código común en su propio proyecto o combine los repositorys del server y del cliente para facilitar el trabajo en ellos.

Si depende de la separación del código común vale la pena el esfuerzo extra depende de usted. ¿El código común tiene sentido por sí mismo o se trata de un set de funciones específicas de este producto? Por ejemplo, si tiene un código de análisis SSL o de date en común que podría hacer un buen proyecto derivado. O tal vez haya escrito un código especial para el análisis de files de configuration, que se puede trabajar en modo independiente, incluso si nadie más que su proyecto lo usará. Si está generando un código común solo porque los dos proyectos lo comparten, no se moleste, no tendrá una dirección propia. Girarlo solo será una barrera para el desarrollo tanto para el server como para los equipos de clientes.

Si debe fusionar el cliente y el server es otra consideración. También se networkinguce a si tiene sentido considerarlos como productos separados. ¿Son útiles como productos separados? ¿Pueden funcionar juntas las diferentes versiones del cliente y del server, o deben ser la misma versión? ¿Trabajan diferentes personas en el cliente frente al server? El hecho de que quiera mantener todo junto en un super-repository dice que no.

Si se separa en varios repositorys (cliente, server, proyectos relacionados) siga la respuesta de TimWolla .

Si no está seguro, combínelos en un solo repository con los directorys server/ , client/ y common/ top level. Si sus preocupaciones están ennetworkingadas, agrúpelas. Esto también hará que sea más fácil detectar y migrar código duplicado. Puede trabajar en desennetworkingarlos y crear proyectos concretos "comunes", y en ese momento deberían ser divididos en sus propios repositorys.

TL; DR

Solo use los submodules de Git para mantener su código común. Ese es el caso de uso para el que están destinados. Existen otras opciones, pero principalmente para repositorys en el mismo sistema de files y con poca ventaja cuando se clonan en una networking.

Código común vs. files idénticos

La forma correcta de tratar con código común suele ser a través de submodules o combinación de subtree . Sin embargo, si tiene activos de file que son (y seguirán siendo) idénticos, puede aprovechar los enlaces simbólicos en los filesystems que los admiten. Hay al less tres aspectos negativos de este enfoque:

  1. Solo un repository tendría el file "real". El otro repository solo contendría un enlace simbólico a un file que puede existir o no en un sistema de files diferente.
  2. Los sistemas Windows no tienen enlaces simbólicos estilo Linux / Unix, por lo que la interoperabilidad puede ser un problema.
  3. A less que se trate de blobs binarys realmente grandes, el ahorro de espacio de los enlaces compartidos es probablemente mínimo y no vale la pena el esfuerzo.

También puede considerar el uso de alternativas para compartir objects entre repositorys en el mismo sistema de files. El manual dice (énfasis mío):

Podría estar utilizando los mecanismos objects / info / alternates o $ GIT_ALTERNATE_OBJECT_DIRECTORIES para tomar prestados objects de otras tiendas de objects. Un repository con este tipo de almacén de objects incompletos no es adecuado para publicarse para su uso con transportes tontos, pero de lo contrario está bien siempre y cuando objects / info / alternates apunte al object donde lo toma prestado.

Este tipo de uso avanzado se usa generalmente para acelerar el bifurcación en sistemas como Atlassian Stash en lugar de compartir blobs específicos, pero las herramientas están ahí si quieres hacer malabarismos con las motosierras.