Git rebase interactive in simple words

Don’t rebase, it’s hard and if you make a mistake, everyone in the company will be angry with you…

The above sentence was true about 10 years ago. Unfortunately it became ingrained in the minds of programmers and is still often repeated today. This deters many IT specialists from taking advantage of the work enhancements provided by rebase.

Why indeed it used to be like that? Firstly because the UI of the rebase command used to be less polished than it is today, but most of all because the company’s repositories were maintained in a „anything goes” way, where anyone, knowingly or not, could mess around. Today the standard is to use pull requests and block unapproved changes to the main branch. And on my working branch I can mess around all I want, even though I pushed it to the server right after it was created!

Not only can I modify the history on my branch, but I should even - clean it up before publishing a pull request. My contribution to the shared repository should be neat and readable, so I should delete unwanted commits or squash them with others, reorder commits to make history clearer, fix titles, etc.

Give up „oh I forgot commit” or temporary commits like „wip”, „Changes…”, „Maybe it will work…”. Of course they can exist a short while, but they are not welcome for commits submitted for review.

The easiest way is to run git rebase -i along with the ID of the commit which will close the range. E.g. git rebase -i HEAD~5.

Git will open a text editor with the commits we selected - here we can change the order of the commits (just change the order of the lines in the file) or perform operations on the commits.

The available options are listed in the editor, in the comments, the most popular are: remove commits (drop), squash commits (squash and fixup), change the commits description (reword), edit changes (edit).

Tip: Push before modifying history, then you won’t need a reflog to get back to the old version, just git reset --hard origin/branch-name.

Tip2: After overwriting history, always use git push --force-with-lease - Git will stop you if server branch has changed since your last fetch, so you know what you throw away.