How to integrate changes between branches with Git rebase

Git rebase integrates changes from one branch to another. This Git command offers more possibilities than Git merge but should be used with caution. Find out more about the command in the following!

A fantastic feature of working with Git is the possibility it offers to work in a team or alone in parallel on different parts of a project. Everyone can make changes, fix problems and then make the knowledge gained usable again for the big picture. This works using local repositories and through the use of branches. In these, you can work autonomously on a change and initially apply no changes to the rest of the project. However, if you then want to integrate the changes from one branch into another, the version control system offers two options.

Git merge and Git rebase are both suitable for merging, but they also differ significantly from each other. Git rebase is considered the more sophisticated solution. This Git command moves a set of commits into a new base commit. This changes the base of that commit, and an entire branch is moved to the top of another branch in the process. To do this, Git rebase rewrites the history of the project as new commits are created for the commits in the original branch. Git rebase distinguishes between a manual and an interactive approach.

To understand Git rebase’s exact functionality, it is worth taking a look at the syntax which shouldn’t take too long. Git Checkout is a command that you can find in our handy Git cheat sheet including a PDF download. Using this we can create and integrate a new branch into the master. In the following example, we’ll call the branch which we want to integrate into the master with Git rebase “new”. This is fairly straightforward when using the appropriate command, with which we must indicate only the target branch. This is what it looks like:

So now the branch “new” is placed at the top of the master branch and the project history is rewritten.

The example shown above is the default version of Git rebase. The command is automatically executed in the currently selected branch and applied to the branch HEAD (in this case “master”). All commits are moved and placed at the top of the new branch. The interactive version of Git rebase offers you more useful options. For example, you can select, modify, move or delete each individual commit. This gives you the possibility to clean up the history according to your wishes and to possibly optimize it. The command looks almost like the standard version, but contains the small addition “--i”:

When you run this command, an editor opens automatically, giving you a listing of all commits and allowing you to customize them to your liking.

For advanced users, Git rebase offers other useful options. These are the most important ones:

In many ways, Git rebase is similar to Git Merge. Both commands integrate changes of one branch into another. However, Git Merge leaves the existing branches completely untouched. This is beneficial because the entire history is preserved. However, this also creates a lot of unnecessary merge commits. Git rebase is a linear solution that offers several customization options thanks to its interactive approach, but is mainly considered an option for advanced users.

Git rebase has one huge advantage and one potential disadvantage. The positive outcome of using this command is the clean and clear history of your project. The completely linear in structure due to Git rebase does away with all forks from the top to the beginning. This makes navigation easier and keeps the entire project slimmed down. However, this reduction also means that traceability is no longer necessarily a given. Commits can get lost, which can lead to merge conflicts, especially when working in a larger team. So, Git rebase is a very effective and useful command, but it should be used with some caution.

This also means that it is advisable to avoid using Git rebase on public branches. Otherwise, you’d merge the main branch into your local repository, but your team members would continue working on a completely different version. It would therefore be very difficult or even impossible to tie up and synchronize all the loose ends in the final stages of a task.