Git is used to manage the history of changes as and when you save your code as commits to your local repository, and then merge these changes with the master branch once pull requests have been approved.

The commit history becomes complicated when you pull remote changes, made by other team members, from the master branch to your feature branch. It then loses the linearity of the commit history, making it hard to follow.

This also makes it hard to keep track of the final feature changes when multiple commits exist in a single feature branch. In such a case, if you want to revert a feature at a later date, this makes it difficult to track and revert each one of them.

To resolve this, Git provides a command called rebase, which addresses all such issues. It takes the commits made on your current branch and replays them on a different branch. The commit history on your current branch will be rewritten to retain the granularity of the history.

For example, consider the following diagram as the commit history, where you started the feature branch from the old base and saved your changes with two commits. In the meantime, some other members of your team committed two changes in the master branch. Thus, the old base will now have two branches; one points to master, and the other to feature:

Now, when you rebase your feature branch on to the master, it will rewrite your local commit history, replaying your feature changes to the master branch. You will then see a linear commit history on your local repository along with the changes made by others.