Git pull requiere una fusión pero no cambios locales

Tengo un webhook en un repository de GitHub que desencadena una transferencia de git en otro server para que el repository en el server esté siempre sincronizado con lo que se envió a GitHub.

A veces, la extracción requiere una fusión de compromiso, pero la versión del server nunca se compromete o se modifica. Cuando miro los diffs, la confirmación de fusión muestra los cambios de los últimos commits, lo que hace que parezca que la versión del server está actualizada y lo que está tratando de desplegar está detrás de esto.

Ejecuta este código para desplegar todas las twigs (que se pueden mejorar). Pero en este caso, la única twig es master .

git fetch origin for remote in $(git branch -r) ; do git checkout $(echo $remote | cut -d \'/\' -f2) && git pull origin $(echo $remote | cut -d \'/\' -f2); done

Cuando ejecuto el git status en la versión del server, dice que la twig local está XX delante del control remoto. ¿De dónde vienen estos cambios?

Parece que puede estar modificando confirmaciones que ya se han enviado a GitHub. Hay muchas forms en que esto puede suceder, pero dos de las más comunes son la modificación de las confirmaciones y las modificaciones. Ambas cosas están bien para hacer commits locales , pero hacerlo con commits compartidos a menudo causa problemas.

Considere un repository simple en GitHub:

 A---B---C [master] 

Si un desarrollador decide enmendar la C , se cambia el hash de la confirmación, por ejemplo, a D Entonces ahora GitHub tiene los commits listdos anteriormente, pero el desarrollador tiene esto localmente:

 A---B---D [master] 

Cuando el desarrollador presiona a GitHub, se rechazará la inserción, ya que GitHub contiene commit C la twig master , pero esa confirmación no está presente en la twig del desarrollador. Para que GitHub acepte los cambios, el desarrollador ahora debe forzar la inserción.

Cada vez que te encuentres empujando a la fuerza en Git, probablemente estés haciendo algo que debería ser considerado cuidadosamente. Debe ser una acción ocasional que solo se realiza cuando es necesario y no como parte del flujo de trabajo "normal".

Ahora que GitHub se actualizó por la fuerza a la nueva estructura de compromiso que incluye el compromiso D , tenemos exactamente el mismo problema cuando intenta pull actualizaciones de GitHub: la copy del repository en las máquinas de otros desarrolladores y en su server no puede resolver limpiamente el pull porque contienen commit C , que ya no está presente en GitHub.

Podemos evitar este problema al no modificar el historial compartido. En lugar de modificar las confirmaciones compartidas, considere agregar una nueva confirmación. Su historial ahora puede contener posts como

  • Agregar nueva característica X
  • Oops, soluciona un error simple en la característica X

pero ese es un pequeño precio a pagar por no tener que lidiar con sucursales que han divergido gracias a la historia compartida modificada.