You don’t need to pull before rebasing to an origin branch.

Cygra
2 min readApr 27, 2022

Say you have a release branch checked-out from master. You committed some changes to this branch. At the same time, there are some other changes on the master branch. To incorporate these changes in your release branch and sync with master, you can rebase your branch onto the newest master.

rebase to the newest master

What would you do now?

Some may do this:

  1. git checkout master
  2. git pull
  3. git checkout release/1.0.0
  4. git rebase master

Checkout to the target branch(master), pull the remote changes to local, checkout back, and then rebase.

However, chances are you still have some un-committed changes on your branch, you need to commit your changes or stash them before you switch branche. There may also be some other reasons that you don’t want to switch branches immediately.

hints when switching branches with changes

How can you rebase in this circumstance?

Heres the commands and I’ll explain them below:

  1. (on your release branch) git fetch
  2. git rebase origin/master

Quite simple, right? We don’t need to switch to the target branch and we just need two commands!

First, we use `git fetch` to fetch all the remote changes. Remote-tracking branches are updated. This will not change the local files and branches but it can let the local git repo know what changes has been incorporated to the origin branches.

Then, we can rebase to the remote branch (origin/master) directly.

Notice: the changes will not applied to the local master branch.

--

--

Cygra
0 Followers

Web Developer in Tiktok. Write about git, js, interview, etc.