CODEWITHSUNDEEP
gitrebasegit-pull
Matt W
Matt W

Reputation: 12423

git pull --rebase explanation

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

Upvotes: 4

Views: 7595

Answers (2)

Mark Adelsberger
Mark Adelsberger

Reputation: 45659

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.

Upvotes: 6

Martin G
Martin G

Reputation: 18109

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.

Upvotes: 1

Related Questions