Reorganizar ramas remotas en Git

Question

Reorganizar ramas remotas en Git

Estoy usando un repositorio Git intermedio para reflejar un repositorio SVN remoto, desde el cual la gente puede clonar y trabajar. El repositorio intermedio tiene su rama maestra rebasada todas las noches desde el SVN de origen, y estamos trabajando en ramas de características. Por ejemplo:

remote:
  master

local:
  master
  feature

Puedo empujar con éxito mi rama de características de vuelta al control remoto, y terminar con lo que espero:

remote:
  master
  feature

local:
  master
  feature

Luego vuelvo a configurar la rama para rastrear el control remoto:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

Y todo está bien. Lo que haría me gusta hacer desde aquí es rebase la rama de características a la rama principal en el control remoto, pero me gustaría hacer esto desde mi máquina local. Me gustaría poder hacer:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Para mantener actualizada la rama de características remotas con el maestro remoto. Sin embargo, este método hace que Git se queje:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull hace el truco, pero causa un commit de fusión que me gustaría evitar. Me preocupa que el mensaje diga feature -> feature en lugar de feature -> origin/feature pero esto puede ser solo una presentación.

¿Me estoy perdiendo algo, o estoy haciendo esto de la manera completamente equivocada? No es crítico evitar hacer el rebase en el servidor remoto, pero hace que arreglar cualquier conflicto de fusión del rebase sea mucho más difícil.

115

git branch rebase version-control feature-branch

Author: Aziz Shaikh, 2011-06-01

Source

4 answers

Es bueno que hayas sacado este tema.

Este es un concepto importante en git que un lof de usuarios de git se beneficiaría de conocer. git rebase es una herramienta muy poderosa y te permite aplastar commits juntos, eliminar commits, etc. Pero como con cualquier herramienta poderosa, básicamente necesitas saber lo que estás haciendo o algo podría salir realmente mal.

Cuando estás trabajando localmente y jugando con tus sucursales locales, puedes hacer lo que quieras siempre y cuando no lo hayas hecho empujó los cambios al repositorio central. Esto significa que puede reescribir su propia historia, pero no la historia de otros. Al solo jugar con sus cosas locales, nada tendrá ningún impacto en otros repositorios.

Esta es la razón por la que es importante recordar que una vez que hayas enviado confirmaciones, no deberías rebase más adelante. La razón por la que esto es importante, es que otras personas podrían tirar en sus confirmaciones y basar su trabajo en sus contribuciones a la base de código, y si más adelante decide mover ese contenido de un lugar a otro (rebase it) y empujar esos cambios, entonces otras personas tendrán problemas y tendrán que rebase su código. Ahora imagine que tiene 1000 desarrolladores :) Solo causa una gran cantidad de reelaboración innecesaria.

27

Author: ralphtheninja,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-04-25 19:42:11

Debido a que rebases feature encima del nuevo master, tu feature local ya no es un avance rápido de origin/feature. Por lo tanto, creo que está perfectamente bien en este caso anular la comprobación de avance rápido haciendo git push origin +feature. También puede especificar esto en su configuración

git config remote.origin.push +refs/heads/feature:refs/heads/feature

Si otras personas trabajan encima de origin/feature, se verán perturbadas por esta actualización forzada. Puede evitar eso fusionando el nuevo master en feature en lugar de cambiar la base. El resultado será un avance rápido.

5

Author: Tilman Vogel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-01 17:51:22

Puede desactivar la comprobación (si está realmente seguro de que sabe lo que está haciendo) utilizando la opción --force para git push.

1

Author: Andrew Aylett,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-01 10:55:35

score 158 · Accepted Answer

Se trata de si la característica es utilizada por una persona o si otras están trabajando fuera de ella.

Puede forzar el empuje después del rebase si es solo usted:

git push origin feature -f

Sin embargo, si otros están trabajando en él, debe fusionar y no rebase fuera de master.

git merge master
git push origin feature

Esto asegurará que tenga una historia común con las personas con las que está colaborando.

En un nivel diferente, no deberías estar haciendo back-merges. Lo que estás haciendo está contaminando tu el historial de la rama de característica con otras confirmaciones que no pertenecen a la característica, lo que hace que el trabajo posterior con esa rama sea más difícil, rebase o no.

Este es mi artículo sobre el tema llamado rama por característica.

Espero que esto ayude.