Git push rechazado después de rebase de rama de característica

OK, pensé que este era un simple escenario git, ¿qué me estoy perdiendo?

Tengo una masterrama y una featurerama. Realizo algunos trabajos master, otros feature, y luego otros master. Termino con algo como esto (el orden lexicográfico implica el orden de los commits):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

No tengo ningún problema para git push origin mastermantener masteractualizado el control remoto , ni con git push origin feature(cuando está activado feature) para mantener una copia de seguridad remota para mi featuretrabajo. Hasta ahora, estamos bien.

Pero ahora quiero hacer una nueva base featuresobre los F--Gcommits en master, así que yo git checkout featurey git rebase master. Sigue bien. Ahora tenemos:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Problema: en el momento en que quiero hacer una copia de seguridad de la nueva bifurcación featureramificada git push origin feature, el empuje se rechaza ya que el árbol ha cambiado debido a la rebase. Esto solo se puede resolver con git push --force origin feature.

Odio usar --forcesin estar seguro de que lo necesito. Entonces, ¿lo necesito? ¿El rebase implica necesariamente que el próximo pushdebe ser --forcecompleto?

Esta rama de características no se comparte con ningún otro desarrollador, por lo que no tengo ningún problema de facto con el empuje de fuerza, no voy a perder ningún dato, la pregunta es más conceptual.

El problema es que se git pushsupone que la rama remota se puede reenviar rápidamente a su rama local, es decir, que toda la diferencia entre las ramas locales y remotas está en que el local tenga algunas confirmaciones nuevas al final de la siguiente manera:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Cuando realiza git rebaseconfirmaciones, D y E se aplican a una nueva base y se crean nuevas confirmaciones. Eso significa que después de rebase tienes algo así:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

En esa situación, la rama remota no se puede reenviar rápidamente a local. Sin embargo, teóricamente, la rama local se puede fusionar en remota (obviamente no la necesita en ese caso), pero como git pushrealiza solo fusiones de avance rápido, se produce un error.

Y lo que --forcehace la opción es simplemente ignorar el estado de la rama remota y configurarlo para la confirmación que está presionando. Tan git push --force origin feature-branchsimplemente reemplaza origin/feature-brancha local feature-branch.

En mi opinión, la función de rebasamiento de ramas se masteractiva y la fuerza de empujarlos de vuelta al repositorio remoto está bien, siempre y cuando usted sea el único que trabaje en esa rama.

En lugar de usar -f o --force los desarrolladores deberían usar

--force-with-lease

¿Por qué? Porque comprueba la rama remota en busca de cambios, lo cual es absolutamente una buena idea. Imaginemos que James y Lisa están trabajando en la misma rama de características y Lisa ha empujado una confirmación. James ahora rebasa su rama local y es rechazado cuando intenta presionar. Por supuesto, James piensa que esto se debe a un rebase y usa --force y volvería a escribir todos los cambios de Lisa. Si James hubiera usado la fuerza con arrendamiento, habría recibido una advertencia de que alguien más ha cometido compromisos. No veo por qué alguien usaría --force en lugar de --force-with-lease al presionar después de un rebase.

En su lugar, usaría "checkout -b" y es más fácil de entender.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

cuando eliminas, evitas empujar una rama existente que contiene una ID de SHA diferente. Solo estoy borrando la rama remota en este caso.

Una solución a esto es hacer lo que hace el script de fusión de rebase de msysGit : después del rebase, fusionarse en el antiguo encabezado de featurewith -s ours. Terminas con el gráfico de confirmación:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... y tu impulso featureserá un avance rápido.

En otras palabras, puedes hacer:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(No probado, pero creo que es correcto ...)

Puede ser o no el caso de que solo haya un desarrollador en esta rama, que ahora (después de la modificación) no está en línea con el origen / característica.

Como tal, sugeriría usar la siguiente secuencia:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Sí, nueva rama, esto debería resolver esto sin una fuerza, lo que creo que generalmente es un gran inconveniente.

Mi forma de evitar el empuje de la fuerza es crear una nueva rama y continuar trabajando en esa nueva rama y, después de un poco de estabilidad, eliminar la vieja rama que se volvió a armar:

• Rebasar localmente la sucursal desprotegida
• Ramificación de la rama rebaseada a una nueva rama
• Empujar esa rama como una nueva rama al control remoto. y eliminar la rama vieja en remoto

Otros han respondido tu pregunta. Si rebasas una rama, tendrás que forzarla a empujar esa rama.

Rebase y un repositorio compartido generalmente no se llevan bien. Esto es reescribir la historia. Si otros están usando esa rama o se han bifurcado de esa rama, entonces el rebase será bastante desagradable.

En general, rebase funciona bien para la administración de sucursales locales. La administración remota de sucursales funciona mejor con fusiones explícitas (--no-ff).

También evitamos fusionar master en una rama de características. En su lugar, cambiamos a maestro pero con un nuevo nombre de rama (por ejemplo, agregando un sufijo de versión). Esto evita el problema de rebase en el repositorio compartido.

¿Qué hay de malo con un git merge masteren la featurerama? Esto preservará el trabajo que tenía, mientras lo mantiene separado de la rama principal.

A--B--C------F--G
       \         \
        D--E------H

Editar: Ah, lo siento, no leí tu declaración de problema. Necesitará fuerza mientras realiza a rebase. Todos los comandos que modifican el historial necesitarán el --forceargumento. Esto es a prueba de fallas para evitar que pierda el trabajo (lo antiguo Dy Elo que se perdería).

Así que realizó una git rebaseque hizo que el árbol se vea (aunque parcialmente oculto como Dy Eya no está en una rama con nombre):

A--B--C------F--G
       \         \
        D--E      D'--E'

Entonces, al tratar de impulsar su nueva featurerama (con D'y E'dentro de ella), perdería Dy E.

Para mí, seguir pasos sencillos funciona:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Después de hacer todo lo anterior, también podemos eliminar la rama myFeature siguiendo el comando:

git push origin --delete myFeature

Lo siguiente funciona para mí:

git push -f origin branch_name

y no elimina ninguno de mi código.

Pero, si desea evitar esto, puede hacer lo siguiente:

git checkout master
git pull --rebase
git checkout -b new_branch_name

entonces puedes elegir todos tus commits para la nueva sucursal. git cherry-pick COMMIT ID y luego empuje su nueva rama.

Como el OP entiende el problema, solo busca una solución más agradable ...

¿Qué tal esto como práctica?

• Tenga una rama de desarrollo de características real (donde nunca rebase y fuerce, para que sus compañeros desarrolladores de características no lo odien). Aquí, regularmente toma esos cambios de main con una fusión. Una historia más desordenada , sí, pero la vida es fácil y nadie se interrumpe en su trabajo.

• Tenga una segunda rama de desarrollo de características, donde un miembro del equipo de características regularmente empuja todos los compromisos de características a, de hecho rebase, de hecho forzado. De manera casi limpia basada en un compromiso maestro bastante reciente. Una vez completada la función, empuje esa rama encima del maestro.

Es posible que ya haya un nombre de patrón para este método.