67

Does anyone know what is the difference? Seems to me, it is the same. But when I run it, it didn't do the same thing:

git rebase origin/branch - ok rebases from remote branch

git rebase origin branch - makes conflicts

4 Answers 4

88

@Mar's answer is right and perfectly solved this question, just add one comment.

if you want to rebase a branch based on remote master branch, git rebase origin/master is not enough, it will not get new commits directly from origin/master. You need to git fetch before git rebase origin/master.

or you can use another way to rebase a branch.

  1. switch to master git checkout master
  2. git pull origin master
  3. switch back to your own branch git checkout {your branch}
  4. git rebase origin/master

then, your branch is updated to newest commits.

Sign up to request clarification or add additional context in comments.

7 Comments

is there a difference in 4th step with : git pull origin/master --rebase ?
Just learned this one but git checkout {your branch} can actually be git checkout - if the last branch you were on was yours
@nerdlyist the same logic as cd -.
@thoroc that is awesome
git checkout {your branch} -> git rebase origin/master -> git push I think it does the same thing, am I right?
|
55
git rebase <upstream> <branch> 

is equal to

git checkout <branch> git rebase <upstream> 

By default <branch> is HEAD.

[1] https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

Comments

15

The last step should be: git rebase origin/master

Comments

3

First we should normalize/simplify these arguments so that we can compare them side-by-side.

First one:

$ # git rebase origin/branch $ git rev-parse --symbolic-full-name origin/branch refs/remotes/origin/branch 

Okay so the full refname is refs/remotes/origin/branch.

Second one:

$ # git rebase origin branch $ git rev-parse --symbolic-full-name origin refs/remotes/origin/main 

Now this is made up since I don’t know what origin would be for you. But origin is likely to be the “main branch” (main/master/develop/trunk) of the remote. [1] [2]

The use of branch here is just a branch so we don’t have to expand it to refs/heads/branch.

Now we can compare them:

  1. git rebase refs/remotes/origin/branch
  2. git rebase refs/remotes/origin/main branch

We see that (1) is git rebase with one argument and (2) is git rebase with two arguments. Many Git commands do different things based on how many positional arguments you provide. We need to check the synopsis (man git rebase): [3]

SYNOPSIS git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase> | --keep-base] [<upstream> [<branch>]] git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] git rebase (--continue|--skip|--abort|--quit|--edit-todo|--show-current-patch) 

So we’re looking at the first “form”: [<upstream> [<branch>]]. Here <upstream> is optional. And <branch> is an optional positional argument as well (nested inside the former).

The man page says that

If <branch> is specified, git rebase will perform an automatic git switch <branch> before doing anything else. Otherwise it remains on the current branch.

So the first one will not switch branches and will go ahead and rebase on refs/remotes/origin/branch:

git rebase refs/remotes/origin/branch 

While the second one will switch to branch and rebase on the different (could be different) “upstream” called refs/remotes/origin/main:

# What it does git checkout branch git rebase refs/remotes/origin/main 

So they look very similar but can end up doing very different things.

Notes

  1. refs/remotes/origin is an alias for refs/remotes/origin/HEAD. This symbolic ref points to the “default branch” of the remote called origin (see git remote set-head)
  2. So note that origin in this context is not the remote called origin. It is a ref, namely a remote-tracking branch.
  3. git version 2.47.0

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.