Ordenar un lío de Git

Question

Acabo de heredar un proyecto que se mantuvo utilizando Git. En un momento dado, el código se implementó en 3 sistemas separados y cada sistema mantuvo su propio repositorio 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 entre sí. Algunos cambios están en la rama principal, otros están en nuevas ramas.

¿Cómo puedo unir las 3 fuentes diferentes para poder:

1. encuentre una base común con la que trabajar;
2. descubra qué cambios son correcciones de errores que deben aplicarse en los 3 sistemas; y
3. ¿Mantener los 3 sistemas de forma sana para que haya solo una rama común y separar las personalizaciones requeridas para los 3 sistemas diferentes?

Answer 1

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

Una buena herramienta de visualización como git-age , gitnub , gitx , risita puede hacer maravillas, pero tu tarea probablemente será bastante tediosa a menos que puedas Encuentra los puntos de ramificación. Si hay parches similares aplicados a todas las sucursales, puede usar (interactivo) rebase para reordenar Sus compromisos de tal manera que estén en el mismo orden. Luego, puede comenzar a "cerrar" sus ramas, moviendo el punto de ramificación hacia arriba, poniendo comillas en maestro. Se puede encontrar una buena descripción de cómo reordenar las confirmaciones usando rebase aquí .

Las posibilidades son las acciones que debe realizar y se describen en los enlaces que se encuentran en Git Howto Index . Siempre es bueno tener a mano una buena hoja de trucos . Además, sospecho que el seguimiento de Eric Sinks publicará " DVCS y DAG, Parte 1 " contendrá algo útil (no lo hizo, pero fue una lectura interesante, sin embargo).

Los enlaces adicionales que son útiles son: Git Magic , Git Ready y Guía SourceMage Git

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

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

Comenzamos separando (o manteniendo separado) el código personalizado del código genérico. Entonces hemos intentado dos enfoques; ambos que funcionaron bien:

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

Después de la primera implementación y viendo que la segunda era un hecho, pasamos un tiempo tratando de prever futuros puntos de personalización / corte para reducir la duplicación en los repos personalizados (alt. 1, que es el enfoque que utilizamos actualmente) y en la repositorio base / core.

Y sí, intentamos refactorizar sin piedad cada vez que notamos que el núcleo / personalización se desliza por división :)

Answer 2

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

git rebase

comandos y cuando las cosas se arruinaron:

git reflog

seguido de

git reset --hard HEAD@{ref}