Git se fusiona todo el time

Un progtwigdor en mi equipo tiene un problema muy extraño con un repository particular de Git.

Él es el único usuario que realiza cambios en el repository, sin embargo, cada vez que presiona, Git realizará un post de compromiso de fusión en lugar del post de confirmación real.

Es difícil de explicar por lo que una image es más adecuada: enter image description here

En algún momento comenzó a hacer lo de "playMakerTest" y nunca se recuperó de hacer eso. Cada compromiso que él hace y empuja termina siendo una fusión. Incluso después de revisar limpiamente, volver a establecer la base del compromiso más reciente, mover todo de nuevo a maestro y deshacerse de todas las demás twigs.

¿Alguien tiene una idea de por qué está sucediendo esto? Estoy realmente a punto de crear un nuevo reportaje …

No sé si vas a eliminar esta pregunta (como se sugirió en los comentarios anteriores), pero por ahora señalaré una cosa:

git push no puede crear una combinación . 1

Cuando usas git push , haces que tu git invoque a otro git (por ejemplo, a través de ssh), después de lo cual los dos repositorys de git mantienen una pequeña conversación para discutir qué objects tienen los tuyos y cuáles no. les gusta poner algunas de sus references a point-to.

Por ejemplo, en su caso usted (o más precisamente su progtwigdor en su equipo) podría llamar a la instancia del server git y decir "por favor cambie la twig de branch a la de 1234567... ". Para que el server haga eso, el server debe tener la confirmación 1234567... para que su git pueda empaquetar ese object con cualquier otro object necesario y enviarlo primero.

El git del lado del server no se fusiona durante este process, simplemente acepta los objects que se necesiten primero, luego acepta requestes como "establecer refs/heads/branch a 1234567... ". Esas requestes se ejecutan a través de la comprobación de permissions (ganchos de pre-receive y update ), que típicamente hacen cosas como rechazar actualizaciones no rápidas, o al usar sistemas más sofisticados como gitolite, verificar si el usuario remoto tiene permiso para crear, eliminar, o actualiza una twig en particular. 2 Si las comprobaciones de permissions lo permiten, el process de git del lado del server simplemente establece las references solicitadas (generalmente nombres de twigs, a veces tags, también hay references de notas y demás).

Cada una de estas combinaciones, entonces, viene del lado del usuario (no del server), antes del paso de git push . Como se señaló en los comentarios anteriores, esto se debió a que el usuario modificó repetidamente una confirmación existente pero presionada , que copy la confirmación a una nueva ID. Presionar esa nueva ID no será una operación de avance rápido y será rechazada por defecto; para lograrlo, el usuario presumiblemente realiza fusiones adicionales.


1 Bueno, no solo, de todos modos. Usando los ganchos mencionados anteriormente, es posible configurar un server de forma tal que cuando reciba un empuje, guarde los nuevos commit, rechace el push y luego ejecute commands git separados para crear fusiones utilizando el save-but – commit (s) rechazado (s). Es un modo de operación bastante retorcido, y no es algo que la gente haría o debería hacer en general. (Además, no es precisamente el impulso que crea la combinación aquí, sino el impulso que activa otro script y el otro script que crea la fusión).

Después de algunas testings, he confirmado que "Enmendar el último compromiso" fue realmente el problema.

Después de que ya se haya enviado una confirmación, la corrección intentará corregir la última confirmación. Al comprometerse, se dará count de que el compromiso que acaba de modificar ya había sido empujado y lanzará un conflicto de fusión.

El progtwigdor en cuestión se perdió todas las banderas rojas y simplemente "solucionó" los conflictos de fusión y presionó los cambios, como usuario inicial de Git, pensó que se suponía que "era así". Hasta que otros y yo comenzamos a quejarnos, todos sus compromisos son fusiones y arruinan la integridad de la historia.