JIYIK CN >

This article will cover the basics of rebasing your local branch when pulling changes from a remote repository branch in Git.

We use the version control system Git to track changes made to files. We commit changes in a local branch in our local repository. This local branch is associated with a remote branch in the remote repository.

Sometimes, we synchronize the changes in the remote repository with the changes in the 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 our local branch (ie) to reapply the unpublished changes on top of the published changes.

We will now illustrate this with an example.

When pulling from a remote repository branch in Git, use git pull --rebaseRebase to rebase the local branch

In a collaborative development environment, we use Git to create a branch in a local repository on our local system. We associate this local branch with a remote branch in a remote repository.

We stage and commit the changes we make to the files in our local branch. Then we publish those changes to the remote branch in the remote repository.

Other members of the team then use the same repository and pull the published changes into their local branches on their systems.

Therefore, we regularly go through the process of pushing local changes to the remote repository and pulling in published changes from the remote repository.

When pulling published changes from a remote branch into our local branch, we can choose to either merge or rebase.

In case of merge, we use command git pull --mergewhich is the default option. When we pull in remote repository changes in merge case, local changes will be merged with remote changes.

Create a merge commit to point to the latest local and remote commits.

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

In case of rebase, no new commits are created.

Suppose we have a branch named in our local repository featurethat is associated with a remote branch of the same name in the remote repository.

Each developer on the team will have featurea local branch on their local system.

Suppose a developer has featurecommitted some changes to a local branch.

Now, suppose that other developers have published featuresome changes to the remote branch of the remote repository.

Therefore, the branch situation now looks like the following figure.

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

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

This assumes that the new commits in the remote branch featureare related to the commits in the local branch (which is usually the case). So when we pull in this case, we rebase instead of merge.

We need to execute the rebase command with --rebasethe -r option git pullto perform the rebase. The syntax of the command is git pull --rebase <remote-repository> <remote-branch-name>.

So in our case, to rebase our local branch featurewe would do the following.

$ git pull --rebase origin feature

Therefore, git pullafter executing the above command, the branch is as shown in the figure below.

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

So, as shown, featureall unpublished commits of the local branch are moved to featurethe tip of the remote branch changes. No new commits are created.

The main advantage of the rebase option is that the project history is cleaner than using the merge option.

Furthermore, as shown in the above figure, we get a linear project history. There are no forks. git logThe history of the project can be easily browsed using the command.

So, we have detailed rebasing local branches when pulling changes from a remote repository in Git.