How to Rebase Local Branch When Pulling Changes From the Remote Repository Branch in Git

Azhar Bashir Khan Feb 02, 2024
How to Rebase Local Branch When Pulling Changes From the Remote Repository Branch in Git

This tutorial will introduce rebasing the local branch when pulling changes from the remote repository branch in Git.

We use Git, a version control system, to keep track of changes done to the files. We commit the changes in the local branch of the local repository. This local branch is associated with a remote branch of the remote repository.

From time to time, we sync the changes of the remote repository with those present in our local repository. We pull the changes from the remote branch into the local branch.

When we pull in the remote branch changes, we can rebase the local branch (i.e.) to reapply the unpublished changes on top of the published changes.

We will now illustrate this with an example.

Using git pull --rebase to Rebase the Local Branch When Pulling From the Remote Repository Branch in Git

In a collaborative development environment, we create branches in the local repository in our local system using Git. We associate this local branch with a remote branch in the remote repository.

We stage and commit the changes done to files in our local branch. We then publish these changes to the remote branch in the remote repository.

Then, other members of the team, who are also working with the same repository, pull in the published changes in the local branches of their systems.

Thus, periodically, we perform this process of pushing local changes to the remote repository and pulling in the published changes from the remote repository.

When pulling in the published changes of the remote branch into our local branch, we have the option to do a merge or to do a rebase.

In case of a merge, we use the command git pull --merge, the default option. When we pull in the remote repository changes in the merge case, the local changes are merged with the remote changes.

A merge commit is created to point to the latest local and remote commits.

In case of a rebase, we use the command git pull --rebase. In a rebase, the unpublished local changes of the local branch are reapplied on top of the published changes of the remote repository.

No new commit is created in the rebase case.

Suppose we have a branch named feature in the local repository associated with a remote branch with the same name in the remote repository.

Each developer in the team would have the feature local branch in their local system.

Suppose one developer has committed a few changes to the local branch feature.

Now, suppose other developers have published some changes to the remote repository’s remote branch feature.

Thus, now the situation of the branches looks as shown in the illustration below.

              P---Q---R feature (local branch)
             /
A---B---C---D---E---G feature (remote branch)

As shown in the illustration above, we now have a forked history. We need to pull in the changes from the remote branch into the local branch to get the published changes.

Suppose the new commits in the remote branch feature are relevant to those in the local branch (which is usually the case). Thus, we would do a rebase instead of a merge when doing a pull in this case.

We need to execute the git pull command with the --rebase option to do a rebase. The syntax of the command is, git pull --rebase <remote-repository> <remote-branch-name>.

Thus, in our case, to rebase our local branch feature, we would do as follows.

$ git pull --rebase origin feature

Thus, after executing the above git pull command, the branches look as shown in the illustration below.

                      P---Q---R feature (local branch)
                     /
A---B---C---D---E---G feature (remote branch)

Thus, as shown in the illustration, all the unpublished commits of the local branch feature are moved on the tip of the remote branch feature changes. A new commit is not created.

The chief advantage of the rebase option is that the project history is much cleaner than with the merge option.

Also, as shown in the illustration above, we get a linear project history. There are no forks present. One easily browse through the project’s history using the git log command.

Thus, we have elaborated about rebasing the local branch when pulling changes from the remote repository in Git.

For more information, please visit -

  1. git-pull
  2. Merging vs. Rebasing

Related Article - Git Pull

Related Article - Git Rebase