Que fait exactement git rebase --skip?

107

Je viens de faire un git pull --rebase origin masteret il y a eu un conflit.

Premièrement, ce conflit était dans un fichier que je n'avais pas touché, et était d'environ 10 commits en retour. Pourquoi cela arrive-t-il?

J'ai alors tapé accidentellement git rebase --skip, et il «a sauté ce patch».

Inquiet d'avoir sauté un commit, j'ai vérifié une nouvelle version de la branche master et j'ai fait une différence entre la branche sur laquelle j'ai fait le rebase et la nouvelle branche master. Les seuls changements qui apparaissent dans la différence sont le dernier commit, et en regardant le journal, le patch qui a été «ignoré» apparaît dans l'historique des commit.

Quelqu'un peut-il expliquer ce qui se passe ici?

git

— Mrwooster
source

Comment tapez-vous accidentellement git rebase --skip. À tort peut-être? :)

— manojlds

Ha! Destiné à taper --abort, mais pour une raison inconnue, il est sorti comme --skip. Je ne pensais pas vraiment. :)

— mrwooster

L'historique du shell est bon pour cela (pour vous faire exécuter quelque chose que vous ne vouliez pas).

— Florian Klein

Il fait ce qu'il dit, il saute un commit. Si vous exécutez rebase --abortun conflit ultérieur au cours du même rebase, le commit ignoré sera bien sûr également annulé.

Si votre changement existait déjà en amont, Git ne pourra pas appliquer votre commit (mais devrait généralement l'ignorer automatiquement, si le correctif est exactement le même). Votre propre commit sera ignoré, mais le changement existera toujours dans HEAD actuel, car il a déjà été appliqué en amont.

Vous devez vraiment vous assurer que vous n'avez pas supprimé un changement important de votre part;) (utilisez le reflog pour revenir à l'état avant le rebase)

— tricot
source

Alors, pourquoi le commit apparaît-il toujours dans le journal? Et pourquoi le commit manquant apparaît-il maintenant dans le diff?

— mrwooster

Oui, le conflit avait déjà été résolu en amont ... pour une raison quelconque, git rebase soulève d'anciens conflits de fusion ... autre chose qui me trouble? ... cela signifie-t-il qu'il a ignoré le conflit, mais appliqué le correctif qui a résolu le conflit?

— mrwooster

Vous avez sauté votre propre commit, qui avait le même changement qu'un commit en amont. Vous avez sauté votre commit, mais le changement a toujours été effectué (car il existait déjà en amont)

— knittl

@mittal non, je ne pense pas que ce --skipsoit la voie à suivre. Skip ignorera complètement un commit, abandonnant toutes les modifications apportées dans ce commit.

— knittl

@mittal: pensez git rebaseà copier des commits d'une branche vers une autre branche. Ainsi, lorsque vous sautez un commit, le contenu original du commit est ignoré et le correctif n'est pas appliqué (donc toutes les modifications apportées à un fichier ne le feront pas dans votre branche cible). Le moyen le plus simple est de configurer un référentiel git simple avec deux branches, plusieurs commits sur chacun d'eux, puis d'essayer de rebase et de sauter un commit (vous pouvez utiliser git rebase --interactivepour spécifier quels commits seront copiés ( pick) ou ignorés ( skip)

— knittl