stash - git rebase y git push: avance rápido, ¿por qué usar?

git remote

Question

Tengo una rama que debería estar disponible para otros contribuyentes y que debería mantenerse constantemente actualizada con el maestro.

Lamentablemente, cada vez que hago ''git rebase'' y luego trato de presionar, se produce un mensaje de ''no avance rápido'' y aborto de empujar. La única forma de presionar aquí es usar --force. ¿Eso significa que debería usar ''git merge'' en lugar de volver a establecer una base de datos si mi sucursal se hizo pública y otros están trabajando en ello?

Answer 1

No, rebase es perfectamente legal con repositorios públicos e incluso puede ser deseable mantener la historia con fluidez. Solo tenga en cuenta que no debe usar rebase para reescribir el historial de confirmaciones publicadas remotamente. Es decir, la rebase solo se puede aplicar a la suya, local, confirma que nunca se ha publicado. Usas rebase para colocar tus commits encima de ellos cuando los recuperas y luego, quizás, los ajustes allí. Otra razón por la que puede recibir este tipo de mensaje es porque la rama que está presionando se actualizó y necesita sincronizar: busque y vuelva a establecer sus compromisos sobre lo que haya obtenido.

Answer 2

Algunas notas sobre cómo funciona git (no técnico):

Cuando restaure, git toma las confirmaciones en cuestión y las "vuelve a comprometer" sobre un historial limpio. Esto es para evitar que se muestre el historial:

Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge
Commit SHA1: aaaa -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg

Después de una rebase, puede verse así (o similar):

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

El problema es que la nueva confirmación que está intentando enviar no es un descendiente de la confirmación en la punta de la rama a la que está presionando.

Ahora, sabes que la misma información está en los commits, pero git se está responsabilizando no solo sobrescribiendo esos commits por ahí (bbbb-gggg en el ejemplo anterior).

Modelo compartido de Repo

Si está utilizando un repositorio compartido, cosas como estas pueden ser muy confusas. Déjame explicar por qué. Digamos que otro desarrollador bajó la rama, y ​​han confirmado aaaa -> gggg en su rama. Luego hacen un compromiso iiii

Mientras tanto, cambiaste de posición y forzaste un empujón, haciendo que el árbol se viera así:

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

Cuando el otro desarrollador intenta presionar, recibe un mensaje de "no avance rápido". Cuando hace una fusión, ambas historias se RELUCIAN juntas, y terminas con un desastre

Algo así (desordenado):

Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge 
Commit SHA1: aaaa -> hhhh   -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg -> iiii    -> jjjj

En otras palabras, si otros tiran AND empujando, es mejor que te quedes con git merge, o EVITAR EMPUJAR hasta después de la rebase (y solo rebase tu trabajo).

Modelo de repositorio públicamente visible

Tal vez estés usando un modelo diferente (más mordaz) en el que solo desees que la gente pueda sacar de tu repositorio. En este caso, git push --force no es tan malo, porque pueden lidiar con mantenerse al día. Pueden volver a establecer sus cambios para estar al tanto de los cambios antes de darle sus parches. Evita que su repositorio se ensucie.

Sin embargo, puede haber una mejor manera para ti. git push --mirror

De http://www.kernel.org/pub/software/scm/git/docs/git-push.html

En lugar de nombrar cada ref para enviar, especifica que todas las referencias bajo $ GIT_DIR / refs / (que incluye pero no se limita a refs / heads /, refs / remotes / y refs / tags /) se duplican en el repositorio remoto. Los refs locales recién creados se enviarán al extremo remoto, los refs localmente actualizados se actualizarán por la fuerza en el extremo remoto, y los refs eliminados se eliminarán del extremo remoto. Este es el valor predeterminado si se configura la opción de configuración remote..mirror.

Una de las mejores cosas de git es que es muy flexible y permite muchos tipos diferentes de flujos de trabajo. Pero su verdadera fuerza reside en el hecho de que es un modelo distribuido, por lo que creo que la mayor parte del ROI se puede cosechar al usarlo de esa manera.