Usa la base de datos git para asegurarte de que tienes el último código del maestro, lo que ayudará a evitar futuros conflictos de fusión.
Veamos un ejemplo de cómo afecta el rebase de git a la historia de la comisión:
Imagina que creas una rama de características del maestro, y trabajas en ella en el transcurso de una semana. El lunes, completas un git pull on master y creas una nueva rama feature_3,git checkout -b feature_3.
El martes y el miércoles, haces tres registros (c1, c2, c3), y tu historial de gilipolleces se ve algo así:
Después de tu última confirmación en la característica_3 notas una petición pull fusionada en el master, que hace cambios en las clases en las que has estado trabajando en la característica_3.
Para evitar futuros conflictos de fusión, decides rebajar tu rama de características. Después del cambio de base, tu historial de git se verá algo así:
Ahora tienes los cambios más recientes del maestro en tu rama feature_3. Fíjate en cómo la fecha de confirmación original de principios de semana sigue intacta y tienes la confirmación más reciente del maestro.
¿Cuál es la orden de rebase?
La orden que te dará la base de git rebase:
Primero, rebobina la cabeza para repetir tu trabajo encima de ella…
Avance rápido de la función 3 a refs/remotes/origen/característica 3.
si no hay conflictos de fusión.
Las últimas confirmaciones del maestro están ahora en tu rama de características y puedes continuar codificando.
¿Y si hay conflictos de fusión durante el rebase?
El comando para nuestro ejemplo sería git rebase -i HEAD~3, donde -i es «interactivo» y HEAD~# es el número de confirmaciones del historial de tu rama para tu rebase. Introducir git rebase -i HEAD~3 te permitirá interactuar con las confirmaciones para limpiar cualquier historial de git y/o resolver cualquier conflicto de fusión.
elige 44d32e5 comete 1
elige f60bba8 comete 2
escoja sdk898b cometa 3
Aquí hay algunas características interactivas adicionales para usar con git rebase -i:
- Elige… el compromiso está incluido.
- reword – permite cambiar el mensaje de confirmación.
- editar – se le dará la oportunidad de modificar el compromiso durante el rebase. Esto es especialmente útil cuando te encuentras con conflictos de fusión.
- squash – te permite agrupar múltiples compromisos en un nuevo compromiso. En esta entrada del blog tenemos una guía de lo que ocurre cuando juegas al squash.
- arreglo – la confirmación se fusiona simplemente en la confirmación anterior, y sólo se utiliza un mensaje de confirmación para describir el cambio.
GitHub tiene un gran artículo con detalles adicionales sobre lo que sucede en diferentes escenarios durante la base Git –interactivo.
Usa la base de datos de git para asegurarte de que tienes un historial limpio de git y puedes mantener una línea de tiempo de calidad para rastrear cuándo y qué se cometió.
Para obtener más información sobre cómo el aplastamiento afecta tu historial de git, consulta Una guía ilustrada del aplastamiento en el git.