
Joining the power: Rebase and Merge strategies
In the world of Git, merging the work of multiple developers can be as delicate as managing the Rings of Power.
Two fundamental tools for this are merge and rebase, two different approaches with the same goal: to integrate the changes from one branch into another. How do you choose the right strategy? Let’s find out together!
Merge: the alliance of peoples
When there’s a need for an alliance to fight a common enemy, it’s necessary to unite the peoples, preserving and respecting the origins of each species that is part of the alliance pact.
We could say that the git merge
command is the equivalent of a good pact between peoples as it preserves the history of all participating branches, creating a new commit and merging the developments made in each branch (therefore creating an army made up of different species in our analogy).

How does it work?
When you run:
git merge branch-feature
Git takes the changes from the branch-feature
branch and merges them into the branch you’re currently on, creating a new merge commit that links the two histories.
Pros and cons
✅ Keeps the history clear and readable, highlighting when and how changes were integrated.
✅ It’s safe: it doesn’t modify the history of existing commits.
❌ It can generate a more complex history with too many merge commits, especially in teams with intense parallel development.
When to use merge?
It’s good to consider using merge when you want to preserve the history of changes made on different branches, when working in teams, when you want to keep individual contributions visible and distinguishable, and when managing long-lived branches like main and develop.
Rebase: The Power of the One Ring
The git rebase
command is like the One Ring: so powerful and dangerous that it can bend history, creating a more linear and clean flow of the past.

How does it work?
Only Sauron knows well how the One Ring works, as for the git rebase
command when you run
git rebase main
Git takes all the commits from your branch and repositions them on top of the latest version of main
, creating a history without forks.
Let’s imagine that each commit is one of the rings of power: the merge keeps all the rings separate but under a single owner, leaving visible each of their stories and how they intertwined.
The rebase, on the other hand, is as if Sauron had forged the rings again to insert them into a perfect timeline under the dominion of the One Ring, reorganizing the past without leaving traces of the initial divergences.
Pros and cons
✅ Keeps the history clean and linear, without unnecessary merge commits.
✅ Facilitates reading the log of changes.
❌ Can be risky: by modifying history, if not used correctly, it can cause issues with remote repositories.
When to use rebase?
Rebase is the right choice when working solo in a branch and wanting to keep history clean, when you need to integrate changes from main
before doing a merge, and when you want to avoid unnecessary merge commits.
⚠️ Caution: rebasing on branches shared with other developers could rewrite history in a problematic way for the team!
Alliance or One Ring? Merge or Rebase?
Merge | Rebase |
---|---|
Git Merge allows you to merge different branches. | Git Rebase allows you to integrate changes from one branch into another. |
The Git Merge log shows the complete history of merge commits. | The Git Rebase log is linear. Since the commits are rebased, the history is altered to reflect this change. |
All commits on a feature branch are combined into a single commit on the main branch. | All commits are rebased, and the same number of commits are added to the main branch. |
Merge is preferable when the destination branch is shared. | Rebase is preferable when the destination branch is private. |
Merge preserves history. | Rebase rewrites history. |
Conclusion: the real power is wisdom
Like every powerful tool, both merge
and rebase
must be used with care and wisdom. Merge is ideal for teams that want a transparent and readable history, while rebase is perfect for those who want a cleaner, more compact history. The choice always depends on the context and development style.
In the end, the decision must be made based on the situation and is always in the hands of the individual. There is no magic formula: just like Frodo with the One Ring, it’s up to you to decide whether to preserve history or rewrite it.
“All we have to decide is what to do with the time that is given us.” Gandalf says this to remind us that, even in the face of a difficult and uncertain situation, true wisdom lies in the ability to make conscious and responsible choices, making the best use of the opportunities we have, without regrets for what we cannot control.