¿Qué hace exactamente git rebase --skip?

107

Acabo de hacer una git pull --rebase origin mastery hubo un conflicto.

En primer lugar, este conflicto estaba en un archivo que no había tocado y tenía aproximadamente 10 confirmaciones. ¿Por qué pasó esto?

Luego accidentalmente escribí git rebase --skip y 'se saltó ese parche'.

Preocupado por haberme saltado una confirmación, verifiqué una nueva versión de la rama maestra e hice una diferencia entre la rama en la que hice la rebase y la nueva rama maestra. Los únicos cambios que se muestran en el diff son la última confirmación, y al mirar el registro, el parche que se 'omitió' aparece en el historial de confirmaciones.

¿Alguien puede explicar qué está pasando aquí?

git

— mrwooster
fuente

¿Cómo escribes accidentalmente git rebase --skip? ¿Quizás incorrectamente? :)

— manojlds

¡Decir ah! Tenía la intención de escribir --abort, pero por alguna razón desconocida salió como --skip. Realmente no estaba pensando. :)

— mrwooster

el historial de shell es bueno en esto (para que ejecutes algo que no querías).

— Florian Klein

Hace lo que dice, se salta una confirmación. Si tu corresrebase --abort en un conflicto posterior durante el mismo cambio de base, la confirmación omitida también se revertirá, por supuesto.

Si su cambio ya existía en sentido ascendente, Git no podrá aplicar su compromiso (pero generalmente debería omitirlo automáticamente, si el parche es exactamente el mismo). Se omitirá su propia confirmación, pero el cambio seguirá existiendo en el HEAD actual, porque ya se aplicó en sentido ascendente.

Realmente debería asegurarse de no eliminar un cambio importante suyo;) (use el reflog para volver al estado anterior al rebase)

— Knittl
fuente

Entonces, ¿por qué la confirmación sigue apareciendo en el registro? ¿Y por qué la confirmación que falta ahora aparece en la diferencia?

— mrwooster

Sí, el conflicto ya se había resuelto en sentido ascendente ... por alguna razón, git rebase muestra viejos conflictos de fusión ... ¿otra cosa que me confunde? ... ¿Esto significa que se saltó el conflicto, pero aplicó el parche que resolvió el ¿conflicto?

— mrwooster

Omitió su propia confirmación, que tenía el mismo cambio que una confirmación en sentido ascendente. Omitió su confirmación, pero el cambio aún se realizó (porque ya existía en sentido ascendente)

— Knittl

@mittal no, no creo que --skipsea el camino a seguir. Skip omitirá una confirmación por completo, eliminando todos los cambios realizados en esta confirmación.

— Knittl

@mittal: piense git rebaseen copiar confirmaciones de una rama a otra rama. Entonces, cuando omite una confirmación, el contenido original de la confirmación se omite y el parche no se aplica (por lo que todos los cambios realizados en cualquier archivo no se incluirán en su rama de destino). La forma más sencilla es configurar un repositorio de git simple con dos ramas, varias confirmaciones en cada una de ellas y luego intentar rebasar y omitir una confirmación (puede usar git rebase --interactivepara especificar qué confirmaciones se copiarán ( pick) o se omitirán ( skip)

— knittl