1

I'm learning about rebase and saw a workflow of doing a rebase on a feature branch and then merging it into master (as an example):

git checkout feature
git rebase master
git checkout master
git merge feature

However I saw another similar option of the last command being (instead of 'git merge feature'):

git rebase feature

How does the last part differ in this instance? Won't the result be the same linear timeline of the feature commits on top of master?

SwissCodeMen
  • 4,222
  • 8
  • 24
  • 34
sir-haver
  • 3,096
  • 7
  • 41
  • 85
  • The last part won't do anything since feature was rebased onto master. – evolutionxbox Aug 06 '22 at 16:32
  • Are you sure about it? master was rebased into feature, not the other way around, so master shouldn't change right? – sir-haver Aug 06 '22 at 16:36
  • 2
    @sir-haver You have not understood the `rebase` command. The command `git rebase xxx` means: rebase the branch I'm on now, _onto_ xxx. It does not change xxx in any way. So for example if feature split off from master, and master had some commits and rebase had some commits, then `git switch feature; git rebase master` changes the split-off point. That's effectively _all_ it does. – matt Aug 06 '22 at 16:37
  • It would depend on your settings for your workspace. Since your feature branch is based off of the latest master, a merge of feature into master would default to a fast forward merge. If you did a rebase instead, it would effectively be the same since there are no _new_ commits from master that isn't already in the feature. – Jeff Mercado Aug 06 '22 at 16:44

2 Answers2

5

You may be learning about rebase, but I don't think you've quite understood it yet.

The command git rebase xxx means: rebase the branch I'm on now, onto xxx. It does not change xxx in any way.

This is confusing, because git merge xxx means exactly the opposite: it means, merge xxx into the branch I'm on now.

So for example if feature split off from master, and master had some commits and rebase had some commits, then git switch feature; git rebase master changes the split-off point. That's effectively all it does.

If we start with this:

A -- B -- C -- D -- E (master)
           \
            X -- Y -- Z (feature)

Then git switch feature; git rebase master results in this:

A -- B -- C -- D -- E (master)
                     \
                      X' -- Y' -- Z' (feature)

(Note the use of the "prime" marker on the moved commits, because you cannot actually move a commit; these commits are copies of the original X, Y, and Z.)

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • 1
    By adding more parameters, it is possible to give much more general rebase instructions. See my essay at https://stackoverflow.com/a/68636306/341994 – matt Aug 06 '22 at 16:43
  • The way I was interpreting the question, the question was replacing the fourth command (the merge) with the rebase instead. For that sequence of commands, a merge and rebase would do the same thing (a fast forward). – Jeff Mercado Aug 06 '22 at 16:45
  • @JeffMercado That's why I say the OP has not understood rebase yet, and why I explain it as I do. – matt Aug 06 '22 at 16:53
  • @matt First of all thanks a lot for your answer, but I never thought that 'git rebase xxx' would change xxx anyhow. Your detailed and well explained answer shows me what I initially thought, what I didn't understand is the difference in the fourth command, but Jeff answers that in this instance it would be the same thing (fast forward). I hope I'm not confusing but it seems right, thanks guys – sir-haver Aug 06 '22 at 17:01
  • @sir-haver No, you said "master was rebased into feature, not the other way around". That shows the misunderstanding I'm trying to correct. Nothing at all was done to `master` and you can't rebase "into" anything. More generally it seems to me that if you understood rebase you would never have asked this question in the first place. – matt Aug 06 '22 at 17:05
  • @matt Oh right right, my terminology is incorrect, it's just the way I'm visualizing it but you're right I see my mistake – sir-haver Aug 06 '22 at 17:10
  • Exactly, I'm trying to get you to visualize it correctly. :) – matt Aug 06 '22 at 17:57
  • 1
    I never use the single argument version `git rebase xxx` syntax, because I also find it unclear even after having used git since 2005. I always use the two arguments version to be explicit (and independent from which branch which is the current branch), e.g. `git rebase main feature` or the three arguments version, e.g. `git rebase --onto aaa bbb ccc` – hlovdal Aug 12 '22 at 23:08
  • 1
    @hlovdal I am just the same! – matt Aug 13 '22 at 00:23
0

How does the last part differ in this instance?

In this case, there is no difference. Any of these statements could be the 4th command and the results would be the same:

git merge feature
# or
git rebase feature
# or
git reset --hard feature
# or
git checkout -B master feature

Since we're rebasing in a playful manner, note the 4 commands could be reduced to two too2:

git rebase master feature
git switch -C master feature

2 Did I really just do that?

TTT
  • 22,611
  • 8
  • 63
  • 69