Ordenando un desorden Git

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 traer los 3 fuentes diferentes, de forma que pueda:

1. encontrar una base común para trabajar con;
2. descubre qué cambios son correcciones de errores que deberían aplicarse en los 3 sistemas; y
3. mantienen los 3 sistemas de una manera sensata, de modo que solo haya una rama común y separen 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 rebasear, fusionar etc. entre ramas fácilmente.

Una buena herramienta de visualización tales como git-age, gitnub, gitx, giggle puede hacer maravillas, pero su tarea será probablemente bastante tedioso a menos que pueda encontrar los puntos de ramificación. Si hay parches similares aplicados a todas las sucursales, puede usar (interactivo) rebase para reordenar sus confirmaciones de modo 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. Se puede encontrar una buena descripción sobre cómo reordenar commits usando rebase here.

Las posibilidades son las acciones que debe realizar se describen en los enlaces proporcionados por el Git Howto Index. Un buen cheat sheet siempre es bueno tenerlo a tu alcance. Además, sospecho que el seguimiento de Eric Sinks post "DVCS and DAGs, Part 1" contendrá algo útil (No fue así, pero fue una lectura interesante).

adicional buenas para tener enlaces son: Git Magic, Git Ready y SourceMage Git Guide

espero que todos los repositorios habían buena comprometerse mensajes que indican el propósito de cada parche, es eso o revisión de 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; tanto que funcionaba bien:

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

Después de que el primer despliegue y al ver que el segundo era un hecho pasamos mucho tiempo tratando de prever la personalización futuro/puntos de corte para reducir la duplicación a través de los repositorios personalizados (alt. 1, que es el enfoque que utilizamos en la actualidad) y en el repositorio de base/core.

Y sí, nosotros tratamos de refactorizar sin piedad cada vez que nos damos cuenta el núcleo/personalización split deslizamiento :)

Answer 2

OK. Después de mucho trabajo, he logrado hacerlo. Para cualquier otra persona de emprender una tarea similar, implicará una gran cantidad de:

git rebase

comandos y cuando las cosas se cagado:

git reflog

seguido por

git reset --hard HEAD@{ref}