¿Git Branch -m tiene efectos secundarios para otros desarrolladores?

Ya hemos aprendido cómo cambiar qué ramificación apunta a qué usando git branch -m . Si hago esto, ¿les hará la vida difícil a las otras personas que sacan de mi repository?

Digamos que hago un montón de cosas sobre un tema de topic1 y luego hago una

 git branch -m master old_master git branch -m topic1 master git push origin master 

y luego, alguien más saca el master de mi repository remoto, ¿qué tendrán que hacer para que todo apunte al lugar correcto? ¿Tendré que decirles a todos que repitan mis pasos?

¿Esto es similar al problema de los compromisos de rebase después de empujarlos y dejar a otros desarrolladores con objects colgantes?

No estoy exactamente seguro de cómo se ve tu repo, pero este es el peor de los casos.

Supongamos que su repository de origin ve así

 origen:
 o --- o --- A --- B --- C maestro

Y su repository local se ve así,

 JimPuls:
 o --- o --- A --- B --- C maestro, origen / maestro
          \
           D --- E --- F topic1

Luego, después de que su twig cambia el nombre de su repository local, se ve así:

 JimPuls:
 o --- o --- A --- B --- C old_master, origin / master
          \
           D --- E --- F maestro

Ahora, cuando se envía master a origin esa será una actualización no rápida. Después de la inserción, el repository de origin se verá así:

 origen:
 o --- o --- A ... B ... C (B y C son compromisos huérfanos)
          \
           D --- E --- F maestro

Esto puede ser cruel para tus amigos que pueden haber hecho commits encima de C Por ejemplo, si Sally estaba trabajando con usted, su repository podría verse así:

 Salida:
 o --- o --- A --- B --- C origen / maestro
                  \
                   G --- H --- Amo

Ahora, si haces tu impulso de avance rápido y Sally fetch su repository se verá así:

 Salida:
           D --- E --- F origen / maestro
          /
 o --- o --- A --- B --- C  
                  \
                   G --- H --- Amo

Ahora Sally tiene que descubrir cómo hacer que su trabajo (G, H, I) vuelva al repository. Si simplemente realiza una fusión con el origin/master , los cambios en B y C volverán al repository (¡Uy!). En su lugar, tendrá que cherry-pick rebase o rebase sus cambios de GHI en rebase origin/master .

Es genial que Git te permita hacer eso, pero es como pedir problemas. Realmente estás esperando que Sally note la situación. Es por esto que debes advertir a todos los demás queueboradores cuando hagas esto para que puedan manejar el cambio de manera apropiada.

NOTA: el anterior es el peor de los casos. Si su twig topic1 se alejó del master en C, ese cambio es un avance rápido y no hay problemas.

Básicamente, tus operaciones son las mismas que:

 # git checkout master # git reset --hard topic1 # git push origin master 

Y tendrán exactamente ese efecto: todos los demás obtendrán la twig topic1 (se llama master para ellos, sin embargo) y su ascendencia hasta el punto donde el master y el topic1 divergieron por primera vez. La antigua sucursal master se encuentra en sus depósitos y será recogida de basura en algún momento en el futuro porque nada lo señala más.

Si topic1 es una twig que se originó a partir de HEAD of master actual, estarás bien aquí. De lo contrario, entrarás en la situación del "historial de reescritura" que puede arruinar tus tags, por ejemplo. Debes pensar cuidadosamente sobre lo que realmente estás tratando de lograr. ¿Tal vez una simple git merge te servirá mejor?