Why does `git rebase` apply all of the commits rather than just applying the last one?

Question

I'm aware of how git rebase works, and I've been using it in production for a while. It replays all of the commits of a branch onto another branch. It rewrites history of your current branch.

I've recently started playing around with git rebase --skip, although I was initially terrified of it. I realize it just skips that commit as if it never happened.

It seems to me that the resulting working directory would be the same in these two cases:

1) all of the commits are skipped except the most recent

2) all of the commits are replayed, such that the commits are resolved in favor of their branch.

Reminder: their is the branch that you are currently on when you rebase.
Other reminder: I'm specifically interested in the working directory. Is this the same?

Is it true that the working directory is the same result?

Answer 1

In general, no. A replay of a commit is very similar to the cherry-pick operation. Not the state of the repository is applied, only the patch (=diff, changeset, ...) corresponding to that commit. If you skip commits, you omit the changeset, which may or may not result in conflicts. Either way, only skipping empty commits yields the same results in general.

However, if you perform an interactive rebase and squash all commits into one, the resulting work tree should be the same. Be sure to know about Undoing a git rebase if necessary. (Or better, perform all rebasing operations in an one-off branch, branched off the original "their" branch. Then, you can always double-check if the results have changed by comparing that rebased one-off branch with the "their" branch, and update the "their" branch only after everything is good.)