Rebase y lo que quiere decir refinanciar commit commits

Question

A menudo se dice que no debe volver a establecer los commit que ya ha enviado. ¿Qué podría ser el significado de eso?

Answer 1

El ProGit book tiene un good explanation.

La respuesta específica a su pregunta se puede encontrar en la sección titulada "Los peligros de rebasar". Una cita de esa sección:

Cuando se rebase cosas, estás abandonando compromete existentes y crear otros nuevos que son similares pero diferente. Si se presiona compromete en alguna parte y otros les tire hacia abajo y la base de trabajar en ellos, y luego se reescribir esas confirmaciones con git rebase y empuje hacia arriba de nuevo, sus colaboradores tendrán que volver a fusionar su trabajo y las cosas desordenar cuando intente recuperar su trabajo en el suyo.

Actualización:
Basado en su comentario a continuación, parece que su tiene problemas con el flujo de trabajo de Git. Aquí hay algunas referencias que pueden ayudar:

• La página gitworkflows hombre: Véase "La fusión de Arriba" y "ramas puntuales"
• ProGit: Ver "Private Managed Team" blog de
• Jarrod Spillers: Ver "git merge vs git rebase: Avoiding Rebase Hell"

Answer 2

Una rebase altera el historial de su repositorio. Si push se compromete con el mundo, es decir, los pone a disposición de los demás y luego cambia la vista del historial de confirmaciones, se vuelve difícil trabajar con cualquiera que tenga su historial anterior.

Rebase considered harmful es una buena visión general, creo.

Answer 3

Rebasing reescribe el historial. Si nadie sabe acerca de esa historia, entonces eso está perfectamente bien. Sin embargo, si esa historia se conoce públicamente, entonces la reescritura de la historia en Git funciona del mismo modo que en el mundo real: se necesita una conspiración.

Las conspiraciones son realmente difícil de mantener juntas, por lo que es mejor evitar volver a basar las ramas públicas en primer lugar.

Tenga en cuenta que no son ejemplos de éxito conspiraciones: la rama pu del repositorio git de Junio ​​Hamano C. (el repositorio Git oficial del SMC) se reajusta con frecuencia. La forma en que esto funciona es que casi todo el mundo que usa pu también está suscrito a la lista de distribución de desarrolladores de Git, y el hecho de que la rama pu se haya actualizado es ampliamente publicitada en la lista de correo y el sitio web de Git.

Answer 4

Para entender esto, tenemos que entender un poco acerca de cómo funciona git. Un repositorio git es una estructura de árbol, donde los nodos del árbol son commits.Aquí hay un ejemplo de un repositorio muy simple:

tiene cuatro confirmaciones en la rama maestra, y cada confirmación tiene una ID (en este caso, a, b, c y d). Notarás que d es actualmente la última confirmación (o HEAD) de la rama principal.

Aquí, tenemos dos ramas: master y my-branch. Puede ver que tanto master como my-branch contienen commits ayb, pero luego comienzan a divergir: master contiene c y d, mientras que my-branch contiene e y f. Se dice que b es la "base de fusión" de mi rama en comparación con el maestro, o más comúnmente, solo la "base". Tiene sentido: se puede ver que my-branch se basó en una versión anterior de master.

Digamos que my-branch se ha quedado obsoleto y desea actualizarlo con la última versión de master. Para decirlo de otra manera, my-branch necesita contener cyd. Podría hacer una combinación, pero eso hace que la rama contenga confusiones de fusión extrañas que hacen que revisar la solicitud de extracción sea mucho más difícil. En cambio, puedes hacer una rebase.

Cuando se rebase, git encuentra la base de su rama (en este caso, b), encuentra todas las confirmaciones que entre la base y la altura (en este caso, E y F), y volver a reproduce esas confirmaciones en la CABEZA de la rama sobre la que está refinanciando (en este caso, maestro). Git en realidad crea nuevas confirmaciones que representan cómo se verán sus cambios en la parte superior del maestro: en el diagrama, estas confirmaciones se llaman e 'y f'. Git no borra tus confirmaciones anteriores: e y f no se tocan, y si algo sale mal con la rebase, puedes volver a la forma en que solían ser las cosas.

Cuando muchas personas diferentes trabajan en un proyecto de forma simulada, las solicitudes de extracción pueden quedar obsoletas rápidamente. Una solicitud de extracción "obsoleta" es aquella que ya no está actualizada con la línea principal de desarrollo, y debe actualizarse antes de que pueda fusionarse en el proyecto. La razón más común por la cual las solicitudes de extracción se vuelven obsoletas es debido a conflictos: si dos solicitudes de extracción modifican líneas similares en el mismo archivo, y una solicitud de extracción se fusiona, la solicitud de extracción no compartida ahora tendrá un conflicto. A veces, una solicitud de extracción puede quedar obsoleta sin conflictos: quizás los cambios en un archivo diferente en la base de código requieran cambios correspondientes en su solicitud de extracción para ajustarse a la nueva arquitectura, o tal vez la rama se creó cuando alguien accidentalmente fusionó las pruebas de unidad rama principal Independientemente de la razón, si su solicitud de extracción se ha quedado obsoleta, tendrá que volver a establecer la base de su rama en la última versión de la rama maestra antes de que pueda fusionarse.