Git Rebase

Git rebase in­teg­rates changes from one branch to another. This Git command offers more pos­sib­il­it­ies 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­sib­il­ity 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 re­pos­it­or­ies and through the use of branches. In these, you can work autonom­ously 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­ni­fic­antly from each other. Git rebase is con­sidered the more soph­ist­ic­ated 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­guishes between a manual and an in­ter­act­ive approach.

To un­der­stand Git rebase’s exact func­tion­al­ity, 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 auto­mat­ic­ally 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­act­ive version of Git rebase offers you more useful options. For example, you can select, modify, move or delete each in­di­vidu­al commit. This gives you the pos­sib­il­ity 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 auto­mat­ic­ally, 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­pletely untouched. This is be­ne­fi­cial because the entire history is preserved. However, this also creates a lot of un­ne­ces­sary merge commits. Git rebase is a linear solution that offers several cus­tom­iz­a­tion options thanks to its in­ter­act­ive approach, but is mainly con­sidered an option for advanced users.

Git rebase has one huge advantage and one potential dis­ad­vant­age. The positive outcome of using this command is the clean and clear history of your project. The com­pletely linear in structure due to Git rebase does away with all forks from the top to the beginning. This makes nav­ig­a­tion easier and keeps the entire project slimmed down. However, this reduction also means that trace­ab­il­ity is no longer ne­ces­sar­ily a given. Commits can get lost, which can lead to merge conflicts, es­pe­cially 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 re­pos­it­ory, but your team members would continue working on a com­pletely different version. It would therefore be very difficult or even im­possible to tie up and syn­chron­ize all the loose ends in the final stages of a task.