¿Cómo git rebase -i para un rango de confirmaciones?

4 minutos de lectura

¿Puedo aplastar un rango de confirmaciones para una rama local de función/tema usando rebase que no incluye el compromiso más reciente? Esto es para confirmaciones que quiero preparar antes de que se fusionen y se envíen a un repositorio público.

Estaba trabajando rápidamente e hice un montón de cambios menores con títulos y descripciones deficientes que quiero aplastar en dos o tres compromisos lógicos separados con excelentes comentarios. ¿Puedo seleccionar un rango de confirmaciones entre 329aed9 y af39283 que podría estar en cualquier punto del breve historial de esta rama de función?

git rebase -i RANGE_START_COMMIT_ID RANGE_LAST_COMMIT_ID

¡Gracias!

  • Si usa vim (lo que hace Git de manera predeterminada), puede usar el modo de bloqueo visual (ctrl-v) para cambiar arbitrariamente muchas selecciones a aplastamientos a la vez.

    – Cascabel

    14 de octubre de 2011 a las 1:34

  • Gracias Jefromi. Finalmente descubrí cómo elegir y aplastar usando vim. Para otros principiantes, ejecute ‘git rebase -i mybranch~5’ donde 5 es el número de confirmaciones más recientes para manejar. Si desea que un compromiso permanezca como está, deje su prefijo como ‘elegir’. De lo contrario, cambie su prefijo de línea de ‘pick’ a ‘squash’ y rebase condensará cada confirmación de ‘squash’ en la primera confirmación etiquetada como ‘pick’ encima de ella. Si tiene 10 confirmaciones y deja tres como ‘elegir’ y el resto como ‘aplastar’, obtendrá un resultado de tres confirmaciones en total después de la reorganización. Voy a publicar una captura de pantalla que muestra cómo funciona esto.

    –Dylan Valade

    14 de octubre de 2011 a las 3:16

  • ¿No es eso casi exactamente lo que dice la ayuda debajo de la lista de confirmaciones?

    – Cascabel

    14 de octubre de 2011 a las 4:26

  • Sí, pero no es evidente a partir de la ayuda que puede usar pick para dejar algunas confirmaciones sin cambios mientras modifica otras en una sola reorganización. Al menos esa fue la desconexión para mí y espero que esto ayude a otros.

    –Dylan Valade

    14 de octubre de 2011 a las 12:42

Siempre puedes crear una nueva rama con git checkout -b new_branch af39283, y luego rebase eso. Sin embargo, si desea incluir las confirmaciones posteriores en algún momento futuro, no hay forma de evitar reorganizarlas también. El SHA1 para una confirmación depende de todas sus confirmaciones antecesoras.

  • Karl, gracias por ese consejo. No me di cuenta de que era posible generar una nueva rama hasta un SHA, pero lo probé y me gustó. Si estamos hablando de crear cuatro calabazas diferentes, entonces con este enfoque parece que se crearía una nueva rama para las últimas tres calabazas. La rama característica original se reorganizaría como la primera calabaza. Finalmente, ¿cada uno de los otros tres “git checkout -b new_branch SHA#” se fusionaría en la rama de características original para crear una rama perfecta y gloriosa?

    –Dylan Valade

    13/10/2011 a las 20:30

  • ¿Está diciendo que su resultado final deseado es una rama con 3 confirmaciones aplastadas seguidas de su confirmación original? Si ese es el caso, en la lista de confirmaciones que aparece cuando haces una rebase -isolo cambias pick a reword para cada una de las primeras confirmaciones de sus calabazas, elija squash para todo lo demás, y deja tu compromiso intacto como pick.

    -Karl Bielefeldt

    13/10/2011 a las 22:57

  • @Karl: no necesita volver a redactar las primeras confirmaciones de calabazas; Git automáticamente te permite editarlos y proporciona los mensajes de todas las confirmaciones aplastadas como punto de partida.

    – Cascabel

    14 de octubre de 2011 a las 1:31

Por lo tanto, no está del todo claro a qué se refiere con “no incluir” la confirmación más reciente, pero cuando realiza una rebase -i puede aplastar/reordenar/reformular/reparar/eliminar confirmaciones anteriores sin tener que hacer nada con la última confirmación. Por supuesto, está reescribiendo el historial debajo de él, por lo que su diferencia se volverá a aplicar y será un objeto de confirmación diferente después de la reorganización, pero dado que no ha empujado esto públicamente (y está reescribiendo el resto ) eso no debería importar mucho.

  • Gracias por tu ayuda. “sin incluir” significaba que quería hacer calabazas separadas pero dejar mi compromiso más reciente sin cambios. El último compromiso es bueno y me gustaría que permanezca independiente (no aplastado con ningún otro). Luego, hay grupos de aproximadamente 20 confirmaciones muy pequeñas que se pueden condensar en unas pocas confirmaciones aplastadas. Al final, se necesitan alrededor de 60 compromisos pequeños y se crean 4 razonables para fusionarse en un repositorio público.

    –Dylan Valade

    13/10/2011 a las 19:45

¿Ha sido útil esta solución?