tag - Clasificando un desastre de Git

git tag best practices

Question

Acabo de heredar un proyecto que se mantuvo usando Git. En un punto, el código se implementó en 3 sistemas separados y cada sistema mantuvo su propio repositorio de Git descentralizado.

Cada uno de los 3 sistemas extendió el sistema base original en 3 direcciones diferentes. Ninguno de los 3 sistemas ha sido sincronizado uno contra el otro. Algunos cambios están en la rama principal, otros están en ramas nuevas.

¿Cómo puedo juntar las 3 fuentes diferentes para que pueda:

1. encuentre una base común para trabajar;
2. descubra qué cambios son correcciones de errores que deberían aplicarse en los 3 sistemas; y
3. mantenga los 3 sistemas de una manera sensata para que haya solo una rama común y separe las personalizaciones requeridas para los 3 sistemas diferentes.

Answer 1

DE ACUERDO. Después de mucho trabajo, he logrado hacerlo. Para cualquier persona que se embarque en una tarea similar, implicará una gran cantidad de:

git rebase

comandos y cuando las cosas se estropearon:

git reflog

seguido por

git reset --hard HEAD@{ref}

Answer 2

Probablemente comenzaría empujando todos los repositorios para separar las sucursales en un repositorio central, desde el cual puedo rebasear, fusionar etc. entre ramas fácilmente.

Una buena herramienta de visualización como git-age , gitnub , gitx , risita puede hacer maravillas, pero su tarea probablemente será bastante tediosa a menos que pueda encontrar los puntos de ramificación. Si hay parches similares aplicados a todas las sucursales, puede usar la rebase (interactiva) para reordenar las confirmaciones de manera que estén en el mismo orden. Luego puede comenzar a "subir y cerrar" sus ramas, moviendo el punto de la rama hacia arriba al poner las confirmaciones en el maestro. Aquí se puede encontrar una buena descripción sobre cómo reordenar commits usando rebase.

Lo más probable es que las acciones que necesita realizar se describan en los enlaces proporcionados por el índice de Git Howto . Una buena hoja de trucos siempre es agradable tenerlo a tu alcance. Además, sospecho que el seguimiento de Eric Sinks después de " DVCS y DAGs, Parte 1 " contendrá algo útil (No fue así, pero fue una lectura interesante).

Otros enlaces útiles son: Git Magic , Git Ready y SourceMage Git Guide

Espero que todos los repos tengan buenos mensajes de confirmación que le digan el propósito de cada parche, es eso o revisión del código :)

En cuanto a cómo mantener las personalizaciones, hemos tenido suerte con lo siguiente:

Comenzamos por separar (o mantener separados) el código personalizado del código genérico. Entonces probamos dos enfoques; ambos que funcionaron bien:

1. Todas las implementaciones tienen sus propios repositorios donde se guardó la personalización.
2. Todas las implementaciones tienen su propia sucursal en un repositorio de "personalización".

Después del primer despliegue y viendo que el segundo era un hecho, dedicamos un tiempo a prever futuros puntos de personalización / corte para reducir la duplicación en repositorios personalizados (alt. 1, que es el enfoque que usamos actualmente) y en la base / núcleo repo.

Y sí, intentamos refactorizar sin piedad cada vez que notamos el deslizamiento de la división núcleo / personalización :)