example - git reset

¿Hay algún tipo de ''git rebase--dry-run'', que me notifique los conflictos por adelantado?

Question

Estoy tratando de modificar el guión y mi guión tomará diferentes caminos dependiendo de si el rebase resulta en algún conflicto.

¿Hay alguna manera de determinar si un rebase generaría conflictos antes de ejecutar el rebase?

Answer 1

Al momento de escribir (Git v2.6.1 v2.10.0), el comando git rebase no ofrece la opción --dry-run . No hay forma de saber, antes de intentar realmente un rebase, si vas a tener conflictos o no.

Sin embargo, si ejecuta git rebase y encuentra un conflicto, el proceso se detendrá y saldrá con un estado distinto de cero. Lo que puede hacer es verificar el estado de salida de la operación de rebase y, si no es cero, ejecutar git rebase --abort para cancelar la rebase:

git rebase ... || git rebase --abort

Answer 2

Si solo quiere ver si el rebase será exitoso pero luego desea "retroceder" , puede volver a colocar la punta de la rama en el commit original. Simplemente marque o tome nota del SHA original.

O tal vez más fácil, cree una nueva rama temporal en la que "escenifique" el rebase:

git checkout your-branch
git checkout -b tmp
git rebase other-branch

Si tuvo éxito pero desea "retroceder", your-branch no se ha tocado. Simplemente git branch -D tmp y git branch -D tmp a donde empezaste.

Si hubo conflictos e hizo algún trabajo para resolverlos y ahora desea mantener el rebase, simplemente vuelva a colocar la punta de su rama en tmp (y luego git branch -D tmp ).

Answer 3

Sospecho que git rebase ... --dry-run no es posible, por la siguiente razón.

Cuando está haciendo un git rebase , git rebase al punto de partida, luego aplicará parches de forma incremental para cada confirmación para actualizar la rama. Si se produce un conflicto, se detendrá y esperará a que resuelva el conflicto antes de continuar. El camino que toma el rebase después de ese conflicto depende de cómo lo resuelva; si lo resuelve de cierta manera, eso podría introducir (o eliminar) conflictos posteriores.

Por lo tanto, git rebase ... --dry-run solo podría darte el primer conflicto - los informes de conflictos posteriores dependerán de cómo se resuelva ese primer conflicto.

La única forma en que puedo pensar en hacer esto sería a través de git diff entre la posición actual y la última confirmación en la rama a la que está haciendo un rebase. Pero eso realmente no le dará lo que está buscando: realmente solo necesita una lista de cambios conflictivos entre los dos puntos. Puede haber una manera de hacerlo con git diff , pero no es un parche normal.

Answer 4

Todavía puedes hacer git rebase, jugar con él como quieras, luego recuperar todos los cambios de antes. Suponiendo que ha hecho su rebase de alguna rama en el master , y no le gusta:

1. git reflog -20 - te da las últimas 20 posiciones de tu HEAD con una pequeña descripción
2. git checkout <the_branch_name> - coloca su HEAD en la rama
3. git reset --hard <old_sha1_found_in_reflog> - coloca su HEAD y rama en la referencia anterior, de esta manera puede recuperar la rama anterior.

Hay algunas mecánicas para entender aquí:

1. NUNCA eliminas nada en git, no con comandos, de todos modos. Es el recolector de basura que ingresa y elimina ramas sin referencia (por defecto 3 meses). Entonces su rama, anterior al rebase, todavía existe.
2. Lo mismo ocurre con el rebase de la misma rama, es solo un nuevo árbol reescrito al lado del anterior.
3. Toda la historia de rebase y tu otra en manipulaciones HEAD está escrita en el reflog
4. Puede usar anotaciones @{N} de reflog

Por lo tanto, no se pierde nada después del rebase , solo tiene que saber cómo encontrarlo y recuperarlo.

Por ejemplo, puede colocarse una etiqueta antes del rebase que volver a eliminarlo o eliminarlo. te evade todo el paso de investigación SHA1.