¿Cómo rastrear dos versiones de un proyecto en un repositorio de GIT?

Question

Tengo dos versiones de un proyecto en un repositorio local de git. Tengo que comprometer este repositorio en 2 repositorios remotos, uno para cada versión;

GIT

LOCAL (V1/V2) -> GIT REMOTO (V1), GIT REMOTO (V2)

Tengo algunos archivos en el repositorio local de Git que sólo debe ir a GIT REMOTO (V1) y de otra índole solo ir a REMOTO GIT (V2). Ahora comprometo el repositorio local completo para ambos controles remotos. ¿Puedo solo comprometer algunos archivos a REMOTE1?

Necesito tener ambas versiones del proyecto en un repositorio, pero me gustaría tener opciones para dividir el historial un poco. No creo que ninguna ramificación pueda ayudar, ya que tendría que hacer los mismos cambios en ambas ramas principalmente. La mayoría del código, el 90% del código es el mismo para VER 1 y VER 2. El nuevo código suele ser el mismo para ambas versiones.

Answer 1

Parece que necesita utilizar submódulos git-submodule. Guardaría el código común en el repositorio principal, pero luego almacenará las versiones separadas en los submódulos. No puedes dividir la historia con git. Cada confirmación se basa criptográficamente en el contenido y los padres.

Answer 2

La ramificación es exactamente lo que necesita. La ramificación es fácil y muy rápida con Git, por lo que no solo pierde unas pocas teclas más.

Puede usar 3 ramas. Crea una rama "común" en la que trabajarás en cosas comunes a ambas "horquillas" y te fundirás en ellas después de las confirmaciones. Para cosas específicas, trabaja en una de las ramas.

Git usa enlaces duros en el sistema de archivos, por lo que las ramas son económicas tanto en términos de velocidad como de espacio utilizado.

Finalmente, siempre puede seleccionar qué rama presionar/tirar.

Answer 3

Crea tres repositorios Git: core, app_1, app_2. Dentro de cada uno de los repositorios app, cree un submódulo Git que haga referencia al repositorio core.

Tratar el repositorio core como una biblioteca pura y los app repositorios como consumidores biblioteca puros, la estructuración de los tres proyectos de tal manera que se puede mantener todo común a los dos "versiones" de la core repositorio y todo lo que se separarían entre los dos versiones en los repositorios app. Estructura los repositorios app de manera que el proyecto core se pueda colocar al por mayor, sin modificaciones, en un subdirectorio dentro de los repositorios app. Es posible que necesite una secuencia de comandos de inicialización común mínima compartida entre todos los repositorios app, pero ese es un pequeño precio a pagar.

El escenario de estructurar el código de esta manera es muy común. Aunque usar Git de esta manera para soportar este escenario de arquitectura de código es mucho menos común, se ve como una posibilidad viable.