¿Debo empujar o tirar primero?

Por favor, imagina esto:

Mi compañero de trabajo y yo estamos trabajando en la twig principal. Cambié (agregué y eliminé) algún código. Al mismo time, mi compañero de trabajo hizo algunos cambios y envió un commit a la twig principal.

Ahora mi directory de trabajo actual es diferente de la twig principal y quiero mantener ambos cambios en la twig principal y mi directory de trabajo.

¿Qué debería hacer en este caso?

Si hago un push, la twig master será la misma que mi directory de trabajo (los cambios de mi compañero de trabajo se habrán ido) . Si hago un pull primero, naturalmente todos mis cambios se habrán ido. De todos modos, ¿cómo puedo manejar esa situación?

Suponiendo que haya cometido el código localmente, primero debe hacer:

 git pull origin master --rebase 

Esto obtendrá el código del control remoto y lo rebase. Una vez hecho esto, simplemente devuelva el código a control remoto.

 git push origin master 

Ni sus cambios ni los cambios de su compañero de trabajo pueden perderse tan fácilmente al usar Git. Una vez que se compromete algo, se necesita un cierto esfuerzo para eliminar realmente esos cambios comprometidos nuevamente. Ese es uno de los aspectos más hermosos de Git.

En la situación que describes, no podrás presionar de todos modos, porque Git detectará que hay cambios en el repository remoto que no están disponibles en tu repository local. Tendrá que search esos cambios y luego fusionarlos o volver a establecer la base de sus cambios sobre los obtenidos del repository remoto.

Para hacerlo más fácil, probablemente git pull hacer un git pull . Git fusionará automáticamente los cambios de sus compañeros de trabajo en su copy de trabajo, si es posible. Si sus compañeros de trabajo y sus propios cambios entran en conflicto de una manera más complicada, deberá fusionar los cambios manualmente. Pero eso no debería ocurrir muy a menudo si ambos siguen un flujo de trabajo estructurado de Git.

git pull ejecuta git fetch con los parameters dados y llama a git merge para fusionar los encabezados de las twigs recuperadas en la twig actual.

fuente

Tire primero. Tu contribución no se perderá. Esa es la ventaja de los sistemas de control de versiones. Permite que un gran equipo trabaje en equipos de código al mismo time.

Antes de que podamos enviar nuestros cambios a su sucursal en git-hub, debemos asegurarnos de que nuestro repository local tenga todos los cambios realizados en git-hub. El siguiente paso correcto es tirar. Esto puede funcionar de dos maneras:

  1. pull tradicional: un command de fusión combinará los cambios remotos con nuestros cambios locales. Esto agregará un nuevo compromiso, y la list de cambios debe mostrar que las líneas de desarrollo separadas han vuelto a estar juntas.

  2. Pull+rebase : si comprobamos la opción de re-base , Hg/Git temporalmente deshace ("rebobina") cualquier cambio de nuevas confirmaciones locales, fast-forward para que la twig local sea idéntica al control remoto, luego rehaga ("repetición") el local changes/commits con el nuevo HEAD de la twig. Esto cambiará las marcas de time de sus confirmaciones locales, pero la list de cambios debe mostrar que todos los cambios ocurrieron linealmente. En cualquier caso, existe la posibilidad de que necesitemos resolver conflictos si cambiamos partes de código superpuestas en sus últimas commits .