Averigüe qué usuario está resolviendo incorrectamente los conflictos de combinación.

A menudo recibimos problemas con los usuarios que "incorrectamente" arreglan los conflictos de fusión de git y rompen cosas.

¿Me falta algún parámetro de git log que pueda usar para encontrar fusiones recientes que tuvieron conflictos y qué usuario de git resolvió dichos conflictos?

En algunos casos, es cuando alguien fusiona el maestro en la twig de "testing", por lo que puede contener el trabajo de muchas personas.

Flujo de trabajo: –

  • Haz algo de trabajo en la twig de características basada en el maestro.
  • Fusionar la twig de la característica en la twig de "testing" para la testing.
  • El maestro ocasionalmente se fusionará con la twig de testing para mantener las cosas al día.

El flujo de trabajo de git necesita mejorar mucho y hacerse más estricto, pero ¿hay algo que pueda hacer a corto ploop para encontrar al usuario solucionando incorrectamente los conflictos de fusión?

De alguna manera, es realmente trivial. De otra manera, es muy difícil.

Así es como es trivial:

  • Hay una fusión. La fusión se hace bien o se hace mal. Mire la fusión y vea si fue correcta o incorrecta. Si está mal, el autor y el autor le dicen quién hizo eso (en la medida en que usted confía en el autor y el autor 1 ).

Aquí es cómo es muy difícil:

  • Hay una fusión. ¿Es correcto?

No hay una manera automática de encontrar la respuesta a esa pregunta.

Si tiene buenas testings automatizadas, puede acercarse arbitrariamente a responder automáticamente la pregunta. Las buenas testings automatizadas no son fáciles, y se vuelven muy difíciles si intentas que sean muy buenas.

Si no tiene testings automatizadas, pero sí algunas personas que son buenas para realizar las fusiones correctamente, quizás pueda hacer comprobaciones puntuales: simplemente haga que estas buenas personas repitan la fusión por sí mismas y compare su resultado con el resultado anterior. Si es lo mismo , la combinación original se realizó correctamente. Si es diferente , no lo fue.

La presencia o ausencia de conflictos de fusión no es un indicador seguro de si la fusión se realizó correctamente. Git no tiene ningún conocimiento secreto: simplemente combina text de acuerdo con un set fijo de reglas. Dicho esto, si desea seleccionar, para las testings manuales, específicamente aquellas fusiones que vieron conflictos, puede automatizar esta parte. Simplemente repita la combinación (asegurándose de que git rerere no esté activado) y vea si hay conflictos.

Repitiendo una fusión

Arriba, la frase "repetir la fusión" aparece dos veces. Puede preguntarse cómo puede repetir una combinación. Esto es principalmente trivial. 2 Primero, encuentre la ID de confirmación de cada fusión:

 git rev-list --merges <start-point> [additional options if desinetworking] 

Esto produce una list de ID de candidato. (Querrá savelos en algún lugar, y anotar cuáles ha verificado para que no tenga que volver a verificarlos más tarde. Utilice la solución ad hoc que desee aquí).

Luego, dado un ID de combinación, simplemente revisa su primer padre como HEAD separado, y ejecuta git merge en sus ID padres restantes (este bit se basa en el comportamiento y syntax del shell POSIX):

 id=c79a113... # or whatever, from your list set -- $(git rev-parse ${id}^@) git checkout $1 # check out first parent shift # now that we have $1 out, discard $1 git merge $* # (attempt to) merge the remaining commits 

La notación rev ^@ es de gitrevisions y significa "todos los padres de la revisión dada". Si todas sus fusiones son fusiones estándar de dos padres, puede usar la más clara (pero less general):

 git checkout ${id}^1 git merge ${id}^2 

(la syntax de gitrevisions y la técnica de set y shift shell permiten fusiones de pulpos).

Dado que esta combinación se realiza en un HEAD separado, la fusión resultante, si se completa automáticamente, puede abandonarse trivialmente si se elimina cualquier otra confirmación o nombre de twig. Si la git merge falla con un conflicto, tiene una combinación conflictiva, con los resultados habituales en el índice; puede continuar para finalizar la combinación o usar git merge --abort para terminarla. (El estado de salida de git merge será 0 si la fusión es exitosa y no nula si no es así)


1 Recuerde que, a exception de las transferencias de compromiso a través de push o fetch, cada operación de Git es realizada localmente por alguien que tiene el control completo de su propio repository. El usuario puede, por supuesto, mentir y afirmar que es otra persona. Si controlas esto, puedes y debes hacerlo en el límite de transferencia: cuando aceptas un compromiso de otra persona, ya sea por git fetch from your end o git push desde su final, sabes con quién estás hablando. (a través de la authentication que haya implementado: esto está completamente fuera de Git, y generalmente es de ssh o https en estos días, a menudo envuelto en extensiones de terceros como Gitolite, o proporcionado como un service por algo como GitHub). En este momento, tiene la posibilidad de hacer la verificación que desee antes de aceptar los commits.

Alternativamente, puede verificar "después del hecho" utilizando, por ejemplo, firmas PGP. Si alguien ha firmado PGP algunas tags y / o algunas confirmaciones, y puede verificar estas firmas, puede optar por creer que esas tags y / o confirmaciones son suyas. A continuación, puede ampliar esa confianza (en la medida en que esté dispuesto, por supuesto, en function de la security de SHA-1 y cuánto confíe en el firmante) a los antepasados ​​de los commits y / o tags, ya que crea un object que coincida un SHA-1 pnetworkingefinido y su text es al less muy difícil. (Esto se llama resistencia a la segunda image previa ; consulte, por ejemplo, esta pregunta de crypto.stackexchange.com ).

2 Digo "principalmente trivial" porque las opciones que el usuario suministró a git merge no están disponibles aquí. Podría requerir que los usuarios que utilizan opciones de fusión no estándar los registren en sus confirmaciones o en las notas adjuntas a las confirmaciones, pero esto es difícil de aplicar. Ver también nota 1: solo puede aplicar reglas de aplicación en el límite de transferencia.