git pull --rebase explanation

Question

Starting point: I have created a branch from master and locally made commits. Other commits have, during my branch work, been PR'd into master...

What I would then do, locally, is git checkout master, git pull, then checkout my branch and git rebase master

My understanding is that - at this point - all the commits I've made while working on my branch will be applied "after" those master commits.

My understand of git pull --rebase is that it does as I've described above. My question is (assuming that is correct) how does the git pull --rebase know which branch I am rebasing on?

In the steps above I have rebased onto the HEAD of master, whereas most git pull --rebase explanations appear to focus on rebasing upon commits made to the same branch (not the original master).

My typical steps, explicitly:

git clone <path>
cd <dir>
git checkout -b feature/my-branch
<make changes>
git add .
git commit -m "some message"
git checkout master
git pull --all
git checkout feature/my-branch
git rebase master
**git push --set-upstream origin feature/my-branch**

Question: Can/Should I change the above steps to:

git clone <path>
cd <dir>
git checkout -b feature/my-branch
**git push --set-upstream origin feature/my-branch**
<make changes>
git add .
git commit -m "some message"
git pull -r

Possible duplicate of [Difference between git pull and git pull --rebase](https://stackoverflow.com/questions/18930527/difference-between-git-pull-and-git-pull-rebase) — MrTux, Feb 22 '18 at 12:27
do `git branch -vv` to see the tracked upstream branch for each branch you have locally — Martin G, Feb 22 '18 at 12:42
Note that `git pull --all` simply passes `--all` to `git fetch`. This is a useless option; don't use it. — torek, Feb 22 '18 at 14:49

score 5 · Accepted Answer · answered Feb 22 '18 at 14:06

In your current procedure, you leave master at origin/master (because you're working on a branch). Then when you pull, the resulting merge is a fast-forward, and you can then rebase your branch onto master to keep a linear history (if you're into that sort of thing).

You could do a --rebase pull, and it would work exactly the same, because you're not in the situation where --rebase is meaningful. When pulling master, --rebase changes what the pull does with commits in master but not in origin/master - and in your scenario there are none.

What --rebase lets you do is not create the branch in the first place but still end with a linear history (if you're into that sort of thing). Let's say instead of

A -- B -- C <--(master)(origin/master)
           \
            D -- E -- F <--(branch)

you instead had

A -- B -- C <--(origin/master)
           \
            D -- E -- F <--(master)

because you did your work directly on master. Now if you did a "normal" pull you would get

A -- B -- C ---- X ---- Y <--(origin/master)
           \             \
            D -- E -- F -- M <--(master)

But if you use git pull --rebase then the pull will rebase the local master onto the newly-fetched origin/master instead, so you get

A -- B -- C -- X -- Y <--(origin/master)
                     \
                      D -- E -- F <--(master)

which is the same linear history you'd get by doing D..F on a branch and rebasing that yourself after pulling X..Y into master.

What you're saying is that if I'm working on a branch which tracks it's remote version, there is no use for 'git pull -r'. I'm looking to understand if I can use 'git pull -r' to rebase my branch to the HEAD of master, without tracking master. The answer appears to be No. What you've described above would appear to require commit permissions on master, which I do not have, hence the requirement to create a branch. — Matt W, Feb 22 '18 at 14:34
@MattW : (1) No, I did not say that there's no use for `-r` when your branch tracks its remote version. In fact I showed exactly what that use is. (2) What you're describing (pulling a branch other than the upstream and rebasing onto it) is in fact possible, contrary to the answer you accepted; it just wasn't clear that's what you were asking. To do this, `git pull -r origin master` — Mark Adelsberger, Feb 22 '18 at 15:01

Martin G · Answer 2 · 2018-02-22T13:35:31.573

1

A branch can be set to track an upstream branch.

git branch --set-upstream my_branch origin/master

This is not needed if you do this when creating the branch:

git checkout -b my_branch origin/master

When the upstream branch is set you can check out my_branch and do git pull -r. For both the above cases it will be rebased on origin/master.

You can list branches together with their tracked upstream branches doing this:

git branch -vv

If you want feature/my-branch to track origin/feature/my-branch i would suggest to change this in your typical steps:

git checkout -b feature/my-branch

to:

git checkout -b feature/my-branch origin/feature/my-branch

Notice that git checkout -b feature/my-branch is equal to git checkout -b feature/my-branch HEAD. In other words, the branch is created to point to the commit you have checked out and with no upstream branch set.

edited Feb 22 '18 at 13:35

answered Feb 22 '18 at 12:44

Martin G

17,357
9
82
98

Thanks. Possibly I'm not clear on 'tracking the upstream'. If I do 'git branch -vv' I get a list of branches which all track a remote branch of the same name. My understanding is that if I set my local branches to track the branch I was on when I created the branch, I would be inadvertantly pushing commits to that source branch. I've updated my question. – Matt W Feb 22 '18 at 13:07
In fact, the answer to the question "When should I use git pull --rebase?" would seem to answer this: "when your changes do not require a separate branch." https://stackoverflow.com/a/2472606/71376 Mine do. Oh well. – Matt W Feb 22 '18 at 14:36

git pull --rebase explanation

2 Answers2