Difference between `git rebase -i master` vs `git rebase -i origin/master`

Question

Combining multiple commits before pushing in Git

Based on my understanding, if I use git rebase -i master, then later I still need to git push origin

Answer 1

Before we go any further, run:

git rev-parse master

and:

git rev-parse origin/master

You'll see two SHA-1s. If those two SHA-1 values are the same, the two rebase commands will do the same thing. If not, they will do different things.

How the argument is used

The argument to git rebase has two purposes:

• it selects which commits get rebased, and
• in the absence of an argument, it selects the starting point for the sequence of cherry-picks.

(Remember, the syntax here is git rebase [options] [ []] so master and origin/master in your examples provide an . You must use the --onto option to provide an , and you're not doing so, so the provides it instead.)

To see which commits are selected, you can use git rev-list (or its more-verbose equivalent, git log). The actual commits selected for rebasing are those that are contained in the current branch but are not contained in the . That is:

git rev-list master..HEAD

or:

git rev-list origin/master..HEAD

respectively. (Replace rev-list with log to see them in detail, or log --oneline to see them as one-line descriptions.)

What rebase does

The rebase command works by copying commits, then setting the branch name to point to the new, tip-most copy.

If you use the interactive version, it puts the commit IDs and instructions into a file that you can edit. Otherwise it just goes through all the commit IDs from the above git rev-list commands, in order.

Before starting the sequence of cherry-picks, rebase detaches HEAD at the commit. That is, the commit is the starting point for the copies.

Then, for each commit ID, rebase essentially runs git cherry-pick (if you're using the interactive version there's no "essentially" about it, it actually uses git cherry-pick, with some modifications based on your instruction editing). This copies the original commit to a new one at the new branch-tip. As each commit is copied, the new branch grows to contain them all.

Finally, once all the commits are copied, git rebase changes the originally-current branch name so that it points to the new tip-most commit on the new branch.

Note that nowhere in this process does git care whether the word origin appears in . It simply resolves the argument to its SHA-1 and then runs with that.