28  Lidiar con el rechazo del envio

Problema: desea enviar cambios a GitHub, pero lo rechazan así:

$ git push
To https://github.com/YOU/REPO.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/YOU/REPO.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Esto significa que su historial de Git local y el del control remoto de GitHub no son compatibles, es decir, han divergido.

Le sugiero que use git status, su cliente Git, o visite su control remoto de GitHub en el navegador para obtener más información sobre la situación, es decir, para tener una idea de este trabajo que no hace. tener.

En resumen, este es el estado en GitHub:

A -- B -- C (on GitHub)

Y este es tu estado local:

A -- B -- D (what you have)

No puedes provocar que se produzca algún tipo de fusión en la copia de GitHub cuando envias.

En su lugar, debe extraer la confirmación C e integrarla de alguna manera en su historial que contiene D. Entonces podrás volver a enviar.

Esto está cubierto en el flujo de trabajo Extraer, pero tienes trabajo local.

Pero antes de que contemplen todo el horror de esto, este es un buen momento para reflexionar sobre lo que podemos aprender de esta situación.

28.1 ¡El que envia primero gana!

Es posible que hayas notado que tú, el autor de D, estás jugando con Git más que la persona que confirmo y envió C, es decir, tu colaborador.

¡Hay una lección que aprender aqui!

Si hubieras enviado D primero, te estarías relajando y ellos estarían descubriendo cómo integrar C en su historial para poder enviar. Así que envia tu trabajo con frecuencia. No se quede a oscuras y trabaje “sin conexión” durante largos períodos de tiempo.

Obviamente, debes enviar el trabajo a main porque está “listo” para compartir (o al menos “lo suficientemente listo”), no para evitar fusiones de Git.

Hay un punto verdaderamente legítimo aquí: es mejor para la salud general de un proyecto confirmar, enviar e integrarse con más frecuencia, no menos. Esto no elimina la necesidad de integrar diferentes líneas de trabajo, pero hace que cada integración sea más pequeña, menos onerosa y menos propensa a errores.

28.2 Mantente en contacto

Otra conclusión es la siguiente: cuanto antes conozca C, mejor. Importe (o busque) con frecuencia.

Pensemos en tu confirmación D. Tal vez se desarrolló durante un par de días mediante el patrón de Enmendar repetidamente. Tal vez C estuvo ahí en GitHub todo el tiempo o apareció muy temprano en su proceso.

Considere que podría ser más fácil integrar C en su trabajo D más temprano que tarde. A veces esto no es cierto, pero más a menudo sí lo es.

En general, vale la pena estar consciente de manera proactiva de lo que otros están haciendo (por ejemplo, importar o buscar con frecuencia) que estar siempre en modo reactivo, aprendiendo sobre el trabajo de su colaborador sólo cuando su envio es rechazado.

28.3 Use ramas

Finalmente, tus primeras experiencias colaborando con otros y contigo mismo en main te darán una comprensión visceral de por qué la mayoría de los usuarios de Git eventualmente comienzan a usar ramas.

Las ramas ofrecen flujos de trabajo explícitos para integrar diferentes líneas de trabajo en sus propios términos. Esto es mucho mejor que intentar realizar una fusión complicada o un rebase en medio de un pánico frustrado, porque al final del día necesitas enviar tu trabajo a GitHub.