How to rebase local branch onto remote master

Question

I have a cloned project from a master branch from remote repository remote_repo. I created a new branch and I committed to that branch. Other programmers pushed to the master branch in the remote_repo.

I now need to rebase my local branch RB onto remote_repo's master branch.

How to do this? What commands to type to a terminal?

Offcenter

Answer 1

First fetch the new master from the upstream repository, then rebase your work branch on that:

git fetch origin            # Updates origin/master
git rebase origin/master    # Rebases current branch onto origin/master

Update: Please see Paul Draper's answer for a more concise way to do the same - recent Git versions provide a simpler way to do the equivalent of the above two commands.

Lawerencelawes

this is the only answer that actually does what was asked – Tyrannous

@Tyrannous No, it is the same as Paul Drapers answer but in long form, I think. – Lamonica

@Lamonica Note that Paul Draper wrote his answer about half a year after kayaker243's comment (and almost two years after this answer). – Lawerencelawes

I get the following: Your branch and 'origin/b1' have diverged, # and have 3 and 2 different commits each, respectively. Seems like another git pull is needed. Is this correct or am I missing something here? – Pershing

@Pershing No, there's no git pull needed. It means that since the last time you fetched from the origin repository, you did three commits. You later fetched again and git noticed that apparently other people did two commits since you last fetched. So now you can either rebase your branch on top of origin's branch (that's what this question is about and what my answer describes), or you can merge your local branch and the one from origin using git merge. – Lawerencelawes

I started a follow up question here: superuser.com/questions/667146/… – Pershing

- git rebase master # will do the same job as the second command? - after the two commands, my local master and RB has the same version of code, right? But i want master to be intact as remote master (without any RB commits) – Show

@Show No, git rebase master will not do the same job as the second command (git rebase origin/master) since master and origin/master may well point to different commits (especially given that the first command was git fetch origin, which may modify origin/master). – Lawerencelawes

@FrerichRaabe I by chance just did git rebase origin and not git rebase origin/master. What will happen? – Toshikotoss

Is the origin here refered to an upstream repo or a fork? – Appalachia

@reversiblean origin refers to any other Git repository. – Lawerencelawes

@FrerichRaabe say for example I have upstream (read-only) and origin (fork). Should I rebase over upstream or the origin? – Appalachia

My problem is to later push my rebased feature-branch to remote. I get endless errors which I fail to resolve. I usually give up, - delete the feature branch on the remote repo, then push it again from my local. That's not very nice. Could you please elaborate just a little more on how to finalize the rebase by pushing the feature-branch to remote? – Murdock

@FrerichRaabe I understand that origin = remote_repo as if previously he could have done git remote add origin https://github.com/whoever/remote_repo.git? – Mclaren

@FrerichRaabe I have the same issue. Are both of these commands run on the local branch or one on local master and the other on local branch? – Surrejoinder

@Surrejoinder Both commands are run while having the same branch checked out: the branch which you want to rebase onto the remote master branch. – Lawerencelawes

Thanks for this answer. Was really helpful to me and helped me to easily resolve my conflicts – Acetify

For most modern repos you'll find you'll need to swap master for main. – Haman

Please add to your answer which branch you are (or have just checked out) when you issue these commands. – Thievish

Answer 2

git pull --rebase origin master

Police

(Equivalent to Frerich's answer) – Police

isn't this slightly different than Frerich's answer, in that this will commit changes from origin master onto local master, whereas Frerich's answer leaves local master untouched? (pull vs. fetch) – Anarch

No, in Frerich's answer, the rebase modifies the local master. A pull --rebase is the same thing as a fetch followed by a rebase – Syphilis

FYI you can do interactive rebases with git pull --rebase=interactive origin master – Cohosh

@Syphilis - I checked the git-pull documentation, and I can't see anything that supports the claim that the local master is modified. If I'm on a branch named dev and run git pull --rebase origin master, only branch dev is going to be modified, not master. The --rebase flag documentation states that it attempts to rebase the current branch on top of the upstream branch after fetching and nothing about modifying local tracking branches. – Saturninasaturnine

@studro I was assuming you were calling pull --rebase while on the local master. Otherwise, I would have been wrong. – Syphilis

Ahh right - that make sense. Thanks. I was just a little confused as I think the original question implies that they were on a local branch (RB I think they called it?) other than master. – Saturninasaturnine

Is there a way to do an interactive rebase using this one liner? – Syndrome

My problem is to later push my rebased feature-branch to remote. I get endless errors that I can't resolve. I usually give up - delete the remote branch and push it again from my local, but that's not very nice. Can you please elaborate just a little more on how to finalize the rebase by pushing it to remote? – Murdock

I got invalid upstream 'origin/master' when I tried Frerich's answer, but this answer works. I think it was because I only cloned a single branch. – Stokehole

And if you want to update the master branch then, without checking out to it, use: git fetch origin master:master – Laoag

When I used the proposed 1 liner command from @PaulDraper I got: Your branch and 'origin/XXX' have diverged, and have 17 and 5 different commits each, respectively. (use "git pull" to merge the remote branch into yours) What does this mean exactly? Should I do a git pull? – Harmonica

I prefer this one because git fetch origin brings all remote branches, even incomplete ones, while I only need a specific branch. And a one-line is preferred – Lacrosse

Please add to your answer which branch you are on (or have checked out) when you issue this command. – Thievish

Answer 3

After committing changes to your branch, checkout master and pull it to get its latest changes from the repo:

git checkout master
git pull origin master

Then checkout your branch and rebase your changes on master:

git checkout RB
git rebase master

...or last two commands in one line:

git rebase master RB

When trying to push back to origin/RB, you'll probably get an error; if you're the only one working on RB, you can force push:

git push --force origin RB

...or as follows if you have git configured appropriately:

git push -f

Gaza

when trying to push back to origin/RB, you'll probably get an error. If youre the only one working on RB, you can git push --force origin RB. source: #8940477 – Mallarme

Ah.... I have exactly this. my "RB" is rebased correctly, but I get endless errors when trying to push it after the rebase. Aside from push --force origin RB - is there a "nicer" (non forced) way to do it? I just try to understand gits perception here - and fail. – Murdock

@MottiShneor No, there is no nice way. If someone else pushes to the branch in the mean time, their changes will be lost! If you want to be nice to the git commit history, you should rather merge master into your branch, which is safe (you can do git push without -f). – Bibi

Thanks for this answer. This has helped me a lot. A lot. – Ursel

git push --force-with-lease is a safer way to push changes after a rebase. It basically checks if another member of your team has made a commit before pushing your changes. See #52824192 – Cornet

Answer 4

Note: If you already have experience with rebase then use the one liner below for a fast rebase option.

The one-liner solution:

This assumes you are on your working branch and you are the only person working on it.

git fetch && git rebase origin/master

Resolve any conflicts, test your code, commit and push new changes to the remote branch.

The longer solution for those new to rebase:

Step 1: This assumes that there are no commits or changes to be made on YourBranch at this point.

First we checkout YourBranch:

git checkout YourBranch
git pull --rebase

What happened? We just pulled all changes made by other developers working on YourBranch and rebased your changes on top of this rebased version.

Step 2: Resolve any conflicts brought up by the rebase.

Step 3: Rebase your local master on the remote master:

git checkout master
git pull --rebase

What happened? We just pulled all the latest changes from the remote master and rebased our local master on the remote master. I always keep the remote master clean and release ready! I also prefer to work on master or other branches locally. I recommend this approach until you become comfortable with git changes and commits.

Note: Step 3 is not needed if you are not maintaining local master, in which case you can do a fetch and rebase remote master directly on your local branch, as in the single-step solution above.

Step 4: Resolve any conflicts brought up by the rebase.

Step 5: Rebase your (rebased) local YourBranch branch on the (rebased) local master:

git checkout YourBranch
git rebase master

What happened? We just rebased our local YourBranch on the local master branch, both of which we had previously rebased on the remote versions.

Step 6: Resolve any conflicts, if any. Use git rebase --continue to continue the rebase after adding the resolved conflicts. At any time you can use git rebase --abort to abort the rebase.

Step 7:

git push --force-with-lease 

What happened? We just pushed our changes to the remote YourBranch. --force-with-lease will determine whether there are any incoming changes for YourBranch from other developers while you rebasing. If there are such changes, git will fetch them to update your local YourBranch before pushing to the remote. This is more advisable than a plain force push, which will not fetch incoming changes from the remote.

Yahoooo...! You have successfully done a rebase!

You might also consider using:

git checkout master
git merge YourBranch

When and Why? This merges YourBranch into master if you and your co-developers are finished making changes to YourBranch. This makes YourBranch up-to-date with master when you want to work on this branch later.

                            ~:   (๑ơ ₃ ơ)♥ rebase   :~

Corduroys

What is this for: "Pulls all the latest changes from master and rebases master on latest master.". Rebase master on master? Dont you just need to pull the latest master? – Tenfold

@JohnLittle Thanks for pointing out. I mean Pulls latest changes from remote master to local master. I always prefer keeping remote master clean and release ready always!. I will update my description. – Corduroys

The git push --force-with-lease is the tricky bit and what nobody talks about when rebasing as you'll get a your branch is X ahead and Y behind origin which if you try to pull and push again will make a huge mess of things. – Cohligan

Thank you so much for the step 7, this always confused me in rebasing since you need to merge anyway in the end and the initial question is always "should i merge or rebase"! Also the push with --force-with-lease top stuff. – Catcher

git fetch && git rebase origin/master or git pull --rebase origin master ? – Boole

@Boole git fetch && git rebase origin/master are two separate commands; where git fetch retrieves latest changes from master without merging and git rebase origin/master is to perform the actual rebase on top of latest master. Where as git pull --rebase origin master is combination of both these commands. I would suggest to use separate commands which gives a bit of more control especially when you're new to rebasing. But you can opt for other one for convenience. – Corduroys

Answer 5

Step 1:

git fetch origin

Step 2:

git rebase origin/master

Step 3:(Fix if any conflicts)

git add .

Step 4:

git rebase --continue

Step 5:

git push --force

Canescent

No explanation as to which branch to start on. Not a good answer. – Angadresma

Please don't do this if you don't know exactly what is implies. Force pushing is not a good idea. – Jonme

!!! please don't do git push --force can be very very dangerous. datree.io/resources/git-push-force – Voigt

Most of the answers including the highest rated one is force pushing. If you will not force push you will not have the history lined up properly over master or whatever the branch you are rebasing on. – Reflate

Should've been git fetch origin master – Cachou

by the way, "git push --force" is a "must" otherwise if you use simple "git push" you'll have dublicated commits – Magnitogorsk

Answer 6

1.Update Master first...

git checkout [master branch]
git pull [master branch]

2.Now rebase source-branch with master branch

git checkout [source branch]
git rebase [master branch]
git pull [source branch] (remote/source branch)
git push [source branch]

IF source branch does not yet exist on remote then do:

git push -u origin [source branch]

"et voila..."

Exeter

I like the step-by-step nature of this answer. It helps break down what exactly is happening. – Lapierre

Answer 7

git fetch origin master:master pulls the latest version of master without needing to check it out.

So all you need is:

git fetch origin master:master && git rebase master 👌

Azzieb

Doesn't git fetch update master without needing to check it out too? Except that git fetch doesn't git merge the updates right? So if we checkout master it won't have the latest updates. So isn't it shorter to do while on feature branch, git fetch then git rebase origin/master? We can't do git rebase master because that will try to rebase from master in workspace, we need origin/master to get from the unmerged but sitting in local. – Keane

Answer 8

If the current branch has a lot of commits and they are needed to be squashed, fixed, and rewritten before rebasing, then interactive rebase is the correct answer. When software engineers say "rebase on top of master", what they usually mean is "do interactive rebase on top of origin/master and make sure it looks great and unnecessary commits are squashed, and commit messages are corrected".

First, check git status and make sure to start in feature branch.

If not in feature brach, try git checkout feature Then

git fetch origin
git rebase -i origin/master

Rarely, a commit history is ready to be rebased as is when rebase on top of master is requested. In most cases, the existing commits are first revised using the interactive rebase.

Ens

Answer 9

simple solution:

git checkout master && git pull

git checkout branch

git rebase master -> resolve conflicts if any

git add .

git rebase --continue

git push --force-with-lease origin branch

Voigt