Use a separate branch for risky rebasing (version control tip)

For everything you need to know about version control, check out Version control – Everything you need to know, on Programming Duck.

Rebasing can be risky. It creates many more code conflicts than merging. Depending on the kinds of code conflicts and their frequency, this can make rebasing fairly error-prone.

Thankfully, there are ways to undo a rebase. For example, you can view the git reflog (with the git reflog command), find a commit hash from before the rebase started and reset back to that commit. (For more information on resetting rebases see the git rebase tutorial by Atlassian).

However, it’s not always easy. For example, the reflog can get fairly messy after many rebases, making it difficult to look through it. This means that you may have difficulty finding an appropriate commit to reset back to.

As a result, whenever you’re faced with a tricky rebase, consider doing this instead:

  1. Branch off your current branch with git checkout -b new-temporary-branch-name. This creates a new branch which contains the entire history of your current branch.
  2. Perform a rebase on the new branch. If it goes badly, you can just delete it and switch back to the original branch (which won’t have been affected).
  3. If the rebase goes well, then hard reset your original branch a few commits back.
  4. Then, you can either fast-forward merge the new branch into your original branch, or cherry-pick some commits from the new branch into your original branch.
  5. Then delete the new branch.

Final notes

That’s it for this article.

If you have any feedback, or even counter-arguments, please let me know in the comments.

Next, if you want to know more about version control, please see the article Version control – Everything you need to know.

Notify of
Inline Feedbacks
View all comments