Git fusionando maestro a twig – conflictos (provenientes del background de Subversion)

Antecedentes de Subversion:

Estamos en transición de Subversion a Git .

Usamos el Subversion trunk para ser nuestra "copy dorada", creamos twigs de function de larga ejecución, y nos fusionábamos trunk a twig muchas veces.

Finalmente, cuando la function se completó, fusionaríamos la twig nuevamente en el trunk .

Cuando hicimos esto, si Bar.java se modificó en trunk , pero nunca lo modificamos en la twig, nunca obtendríamos conflictos de combinación en Bar.java .

Creo que esto se debe a que Subversion tiene un concepto de svn:mergeinfo , y conoce el historial de las fusiones y que Bar.java nunca se modificó en la twig.

Diagtwig de mantenimiento de la twig SVN:

Diagrama de mantenimiento de la rama SVN

Comportamiento de Git:

Ahora que hemos hecho la transición a Git , estamos teniendo conflictos al fusionar el maestro con la twig, ¡incluso si no cambiamos Bar.java en la twig!

Creo que esto se debe a que Git no tiene la misma noción de svn:mergeinfo y no hace un seguimiento del hecho de que los cambios de Bar.java vinieron del master y se fusionaron en.

Diagtwig de Git (MUESTRA PROBLEMA):

Diagrama de Git (MUESTRA PROBLEMA)

Pregunta:

¿Hay alguna manera de que podamos seguir utilizando el mismo enfoque que usamos en Subversion (fusiones frecuentes de troncos a twigs) sin tener conflictos en Git ?

¿Hay alguna manera de implementar un equivalente de svn:mergeinfo para que Git sepa que un file solo cambió en el master y nunca cambió en la branch , y se fusiona automáticamente?

Aunque el ejemplo que ilustré es trivial (un file), de forma realist tenemos numerosos desarrolladores que trabajan en paralelo y terminan lidiando con numerosos files en conflicto, y esta diferencia en el comportamiento de svn a git nos está causando mucho dolor.

Git tiene un análogo a svn:mergeinfo , de hecho, uno mucho más avanzado. Si ve conflictos de combinación en files que no ha tocado en su twig, significa que ya lo tocó de alguna manera (la conversión automática de los finales de línea por IDE es un error común), o que algo ha reescrito el historial en el enlace troncal. Asegúrense de que ustedes no hagan git rebase , commit --amend o reescritura de historial similar contra el trunk alguna vez.

Editar en cuanto a cómo search mergeinfo

El git log estándar le mostraría la información de combinación en la segunda línea:

 $ git log commit 1ca56fefd6ed1af2a6e62f1fbd811d56fa72ded7 (HEAD -> master, origin/master, origin/HEAD) Merge: a3323f6 2237297 

Normalmente, utiliza la representación gráfica en la interfaz de usuario para ver qué se ha fusionado y qué no. En la línea de command git log --oneline --graph HEAD origin/master mostraría un subgráfico que contiene su actual workdir y origin/master para su examen. git log origin/master --not HEAD le imprimiría las confirmaciones que git asume que aún no se fusionaron de la twig actual de maestro a usted.