151 votes

Que fait exactement git rebase --skip ?

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

Tout d'abord, ce conflit se trouvait dans un fichier que je n'avais pas touché et qui se trouvait à environ 10 commits en arrière. Pourquoi cela se produit-il ?

J'ai ensuite tapé accidentellement git rebase --skip et il a "ignoré ce correctif".

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

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

82voto

knittl Points 64110

Il fait ce qu'il dit, il bennes un engagement. Si vous exécutez rebase --abort lors d'un conflit ultérieur au cours de la même refonte, le commit ignoré sera bien entendu annulé.

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

Vous devriez vraiment vous assurer que vous n'avez pas supprimé un de vos changements importants ;) (utilisez le reflog pour revenir à l'état avant le rebasement)

6voto

beevis Points 63

Je me heurte souvent à ce problème lorsque je sais qu'il ne devrait pas y avoir de conflit et que les conflits énumérés n'ont aucun sens. Par exemple, j'avais plusieurs branches dans l'ordre suivant :

A --> B --> C --> D --> E ...

L'une des modifications de la branche D consistait à ajouter un fichier et je me suis rendu compte qu'il était plus logique d'ajouter ce fichier à la branche B. J'ai donc procédé comme suit

  git switch B
  git checkout B -- path/to/new/file
  git commit --amend --no-edit

Ensuite, j'ai fait

  git switch C
  git rebase B

Cela a bien fonctionné, mais lorsque j'ai fait

  git switch D
  git rebase C

Il y a eu des conflits. J'ai pu les résoudre manuellement, mais j'ai également constaté que je pouvais

  git rebase --skip

et tout allait bien. Puis, lorsque j'ai fait

  git switch E
  git rebase D

les mêmes conflits se sont produits. Là encore, je pouvais soit le résoudre manuellement, soit l'ignorer, avec le même résultat.

J'essaie toujours de comprendre pourquoi ces conflits se produisent parfois et pourquoi il est parfois possible de faire une

  git rebase --skip

dans des situations comme celle-ci.

0voto

PhillipMcCubbin Points 170

Il ne tient pas compte de ce commit. Dans un rebasement interactif, si vous abandonnez des commits et que vous ignorez le conflit de fusion, ce commit sera supprimé.

^ eee pick
| ddd pick
| ccc drop
| bbb drop
| aaa pick

S'il y a un conflit de fusion, ce sera pour le commit : ddd. Si vous avez exécuté : git rebase --skip dirait le git : could not apply ddd. et votre branche ressemblerait à ceci :

^ eee
| aaa

Remarque : eee serait en fait réécrit comme un identifiant de livraison différent.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X