Git Rebase

Git rebase in­te­grates changes from one branch to another. This Git command offers more pos­si­bil­i­ties 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 pos­si­bil­i­ty 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 repos­i­to­ries and through the use of branches. In these, you can work au­tonomous­ly 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 sig­nif­i­cant­ly from each other. Git rebase is con­sid­ered the more so­phis­ti­cat­ed 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 dis­tin­guish­es between a manual and an in­ter­ac­tive approach.

To un­der­stand Git rebase’s exact func­tion­al­i­ty, 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 straight­for­ward when using the ap­pro­pri­ate 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 au­to­mat­i­cal­ly 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 in­ter­ac­tive version of Git rebase offers you more useful options. For example, you can select, modify, move or delete each in­di­vid­ual commit. This gives you the pos­si­bil­i­ty 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 au­to­mat­i­cal­ly, 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 com­plete­ly untouched. This is ben­e­fi­cial because the entire history is preserved. However, this also creates a lot of un­nec­es­sary merge commits. Git rebase is a linear solution that offers several cus­tomiza­tion options thanks to its in­ter­ac­tive approach, but is mainly con­sid­ered an option for advanced users.

Git rebase has one huge advantage and one potential dis­ad­van­tage. The positive outcome of using this command is the clean and clear history of your project. The com­plete­ly linear in structure due to Git rebase does away with all forks from the top to the beginning. This makes nav­i­ga­tion easier and keeps the entire project slimmed down. However, this reduction also means that trace­abil­i­ty is no longer nec­es­sar­i­ly a given. Commits can get lost, which can lead to merge conflicts, es­pe­cial­ly 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 repos­i­to­ry, but your team members would continue working on a com­plete­ly different version. It would therefore be very difficult or even im­pos­si­ble to tie up and syn­chro­nize all the loose ends in the final stages of a task.