What is Git rebase and when is it better to use it instead of merge?
Published on 2026-10-20 by frfrand
Rebase de Git explicado con ejemplos: historia lineal, cambios de identificador, diferencias con merge y cómo evitar reescribir ramas compartidas.
Git rebase allows moving or reproducing a series of commits onto another starting point in history. It is commonly used to update a working branch and maintain a more linear sequence, but there is an important warning: it can change commit identifiers.
It does not make your code better by itself. It is a tool for organizing repository history.
The recipe example
Imagine you wrote three steps to prepare a cake based on an old recipe. Meanwhile, someone changed the base recipe. You can try to apply your three steps to the updated version.
This is similar to rebase: Git takes commits from your branch and reapplies them from another base. The result may have the same functional effect, but the generated history is not identical to the previous one.
How does it differ from merge?
A merge combines histories and, in a non-trivial combination, normally creates an integration commit that preserves the relationship between branches.
A rebase reapplies commits, generally resulting in a more linear visual history. It can be convenient for reviewing, but it also causes certain commits to be represented as new objects.
No strategy is universally superior. Some teams value preserving the exact history of integrations, while others prefer a simpler line to read.
Common example
You are working on a branch feature/reservas and want to incorporate recent changes from main:
git fetch origin
git switch feature/reservas
git rebase origin/mainIf there are no conflicts, Git continues. If they appear, you must resolve them and follow the indicated procedure, for example git rebase --continue.
Before using these commands, check that you are on the correct branch and that your local work is saved.
Why do hashes change?
A commit references its parents. If you change that starting point, part of the data that identifies it changes. Even if the code looks the same, it is no longer the same commit.
That is why it is dangerous to rebase a public branch that other people are already using and then force its publication without coordinating. You could force them to reconcile divergent histories or cause confusion with duplicate commits.
What is interactive rebase?
Git allows you to reorganize or combine local commits through an interactive mode. For example, if you made five "adjustment" commits, you could prepare a more readable history before opening a pull request.
This can be useful before sharing the work. But it should not be used as an excuse to erase evidence of important decisions or rewrite other people's changes.
Does rebase resolve conflicts automatically?
No. It can stop when two changes conflict. The difference is that, when replaying several commits, you might have to resolve problems at different steps.
When faced with a situation you don't understand, git rebase --abort can cancel the ongoing operation and return to the state prior to that rebase. It is preferable to stop and review than to introduce uncertain changes.
When is it convenient to use it?
If you work on your own branch, you want to bring changes from the main branch, and your team has a linear history policy, it can be a good option.
If the branch is shared, the team values the real history of integrations or is not comfortable with rewrites, a merge may be more appropriate.
And in ArduMaker?
An application that you deploy from Git in ArduMaker does not need rebase to work. It does need a coherent repository, a clear version reference, and tests before deployment. Rebase is a development flow decision, not an infrastructure requirement.
The conclusion: rebase serves to reapply changes from a different base. Use it when you understand how it affects history and avoid rewriting branches that other people have already downloaded without coordinating.
Sources: Official Git rebase · Rebase in Pro Git.