Reubicación de sucursales remotas en Git

Question

Estoy usando un repositorio intermedio de Git para duplicar un repositorio SVN remoto, desde el cual las personas pueden clonar y trabajar. El repositorio intermedio tiene su rama principal reestablecida todas las noches desde el SVN ascendente, y estamos trabajando en ramas de características. Por ejemplo:

remote: 
    master 

local: 
    master 
    feature 

puedo empujar éxito mi rama de la característica para el mando a distancia, y terminar con lo que espero:

remote: 
    master 
    feature 

local: 
    master 
    feature 

que luego re-configuración de la rama para hacer un seguimiento del mando a distancia:

remote: 
    master 
    feature 

local: 
    master 
    feature -> origin/feature 

Y todo está bien. Lo que me gustaría hacer desde aquí es volver a establecer la base de la rama de características en 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 la rama de funciones remotas actualizada con el maestro remoto. Sin embargo, este método hace que Git se quejan:

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 una combinación de cometer que me gustaría evitar. Me preocupa que el mensaje indique feature -> feature en lugar de feature -> origin/feature, pero esto puede ser solo una cuestión de presentación.

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

Answer 1

Se trata de si la función es utilizada por una persona o si otros están trabajando fuera de ella.

Puede forzar el empuje después de que el rebase si es sólo usted:

git push origin feature -f 

Sin embargo, si los demás están trabajando en ello, usted debe combinar y no rebase fuera del maestro.

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 fusiones inversas.Lo que está haciendo es contaminar el historial de su rama de características 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: volver a basarlo o no.

Este es mi artículo sobre el tema llamado branch per feature.

Espero que esto ayude.

Answer 2

Puede deshabilitar el cheque (si realmente está seguro de que sabe lo que está haciendo) utilizando la opción --force al git push.

Answer 3

Debido a que porcentualizada feature en la parte superior de la nueva master, su local de feature no es un avance rápido de origin/feature más. Por lo tanto, creo que está perfectamente bien en este caso anular el control de adelanto 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 en la parte superior de origin/feature, que se verá afectado por esta actualización forzada. Puede evitar eso fusionando en el nuevo master en feature en lugar de volver a basar. El resultado será de hecho un avance rápido.

Answer 4

Es bueno que hayas sacado este tema.

Esto es una cosa/concepto importante en git que un lof de usuarios de git se beneficiarían de saber. git rebase es una herramienta muy poderosa que te permite aplastar commits, eliminar commits, etc. Pero como con cualquier herramienta poderosa, básicamente necesitas saber lo que estás haciendo o si algo va a golpear al fan :)

When usted está trabajando localmente y jugando con sus sucursales locales, puede hacer lo que quiera siempre y cuando no haya enviado los cambios al depósito central. Esto significa que puede reescribir su propia historia, pero no la de otros. Al solo jugar con sus cosas locales, nada tendrá ningún impacto en otros repositorios.

Es por eso que es importante recordar que una vez que haya enviado las confirmaciones, no debería volver a establecerlas más adelante. La razón por la cual esto es importante es porque otras personas pueden tirar de sus compromisos y basar su trabajo en sus contribuciones a la base de códigos, y si luego decide mover ese contenido de un lugar a otro (volver a establecer la base) y enviar esos cambios, entonces otras personas tendrán problemas y tendrán que volver a establecer su código. Ahora imagina que tienes 1000 desarrolladores :) Simplemente provoca una gran cantidad de trabajos innecesarios.