What exactly does git rebase --skip do?

Question

It does what it says, it skips a commit. If you run rebase --abort at a later conflict during the same rebase, the skipped commit will be reverted too of course.

If your change already existed upstream, Git will not be able to apply your commit (but usually should skip it automatically, if the patch is exactly the same). Your own commit will be skipped, but the change will still exist in current HEAD, because it was already applied upstream.

You should really make sure you did not remove an important change of yours ;) (use the reflog to go back to the state before the rebase)

I frequently bump into this myself when I know there shouldn't be any conflict and the listed conflicts don't make any sense. As an example, I had several branches in order like this:

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

One of the modifications in branch D was to add a file and I realized that it made more sense to add that file at branch B. So I did

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

Then I did

  git switch C
  git rebase B

This worked fine but when I did

  git switch D
  git rebase C

There were conflicts. I was able to fix it manually, but I also found that I could

  git rebase --skip

and everything was fine. Then when I did

  git switch E
  git rebase D

the same conflicts occurred. Again, I could either fix it manually or skip it with the same result.

I am still trying to get my head around why these conflicts sometimes occur and why it sometimes works to do a

  git rebase --skip

in situations like this.