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

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

Cuando rebases, git toma las confirmaciones en cuestión, y las "vuelve a comprometer" encima de un historial limpio. Esto es para evitar que la historia muestre:

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

Después de un 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 es NO un descendiente de la confirmación en la punta de la rama a la que está enviando.

Ahora, usted sabe que la misma información está en las confirmaciones, pero git es responsable no solo sobrescribiendo esas confirmaciones (bbbb-gggg en el ejemplo anterior).

Modelo de repositorio compartido

Si está utilizando un repositorio compartido, entonces cosas como esta pueden ser muy confusas. Déjame explicarte por qué. Digamos que otro desarrollador bajó la rama, y tienen commits aaaa -> gggg en su rama. Entonces hacen un commit iiii

Mientras tanto, usted rebasado y forzó un empujón, haciendo que el árbol se viera así:

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

Cuando el otro desarrollador intenta empujar, recibe un mensaje de "no avance rápido". Cuando hace una fusión, entonces ambas historias se vuelven a vincular, y terminas con un lío

Algo como esto (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 están tirando Y empujando, es mejor que te quedes con git merge, o EVITA EMPUJAR hasta después del rebase (y solo rebase tu trabajo).

Modelo de Repositorio Públicamente Visible

Tal vez esté utilizando un modelo diferente (más gitano) donde solo desea que la gente pueda extraer de su repositorio. En este caso, git push force force no es tan malo, porque entonces pueden lidiar con mantenerse al día con él. Pueden rebase sus cambios para estar en la parte superior de sus cambios antes de darle sus parches a usted. Evita que tu repositorio se arruine.

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

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

En lugar de nombrar cada ref a push, especifica que todas las refs bajo $GIT_DIR/refs/ (que incluye, pero no limitado a refs / cabezas/, refs / remotes/, y refs/ tags/) be mirrored al repositorio remoto. Los árbitros locales recién creados serán empujado al extremo remoto, localmente refs actualizado será fuerza actualizada en el extremo remoto, y eliminado refs se se retira del extremo remoto. Este es el valor predeterminado si la configuración opción remota..el espejo está listo.

Una de las grandes cosas de git es que es muy flexible y permite muchos tipos diferentes de flujos de trabajo. Pero su verdadera fortaleza radica en el hecho de que es un modelo distribuido, por lo que creo que el mayor ROI se puede obtener al usarlo de esa manera.