Why branches and merges exist
Published on 2026-09-12 by frfrand
Una rama es un puntero de 41 bytes, y eso explica por qué Git cambió la forma de trabajar en equipo. Qué es realmente un conflicto, y la diferencia entre merge y rebase sin religión.
Before Git, creating a branch was an operation. In some systems it involved copying the entire project on the server and could take minutes. The cultural consequence was that almost no one branched: everyone worked on the trunk and prayed.
Git changed that through a very simple design decision.
A branch is a pointer
Literally:
$ cat .git/refs/heads/feature-login a3f91c2e8d4b7a6f9c1e2d3b4a5f6e7d8c9b0a1f
That is the entire branch. A file with a hash inside. 41 bytes.
Creating a branch is writing that file. That is why it is instant, that is why it takes up no space, and that is why Git's workflow pushes you to create one for each thing.
When you make a commit while on that branch, the file is updated with the new hash. The branch "advances". Nothing more.
What a conflict really is
There is a very widespread mistaken idea: that a conflict means Git could not merge.
Git merges almost everything automatically. If you touched file A and another person touched file B, there is nothing to decide. If both touched the same file but in different parts, neither.
A conflict appears only when two people changed the same lines in a different way. There Git could choose one, and it refuses, because choosing wrong is worse than asking.
Viewing a conflict is not a process failure: it is the tool warning you that there is a human decision pending. Teams that have conflicts all the time do not have a Git problem: they have branches that live too long and touch the same things.
Merge and rebase, without religion
Both integrate the work of one branch into another. They differ in what is written afterwards.
merge creates a new commit with two parents. The history remains as it happened: two lines that separated and came together. It is honest and does not rewrite anything.
rebase takes your commits and reapplies them on top of the other branch, as if you had made them afterwards. The history remains in a straight line and reads better. But they are new commits, with new hashes: the originals are left orphaned.
From this comes the only rule that truly matters:
Do not rebase a branch that other people already have. Their copies still point to the old commits, and when trying to integrate, duplicates and confusion will appear.
On your own branch, before sharing it, rebase is excellent: it lets you clean up intermediate commits like "fix", "now yes" and "undo".
A combination that works very well in teams: rebase to tidy up your branch before opening the pull request, merge to integrate it.
The part that helps the most and is least said
Almost all branch problems are solved before they exist, with a habit: short branches.
A two-day branch touches little, integrates without drama and almost never generates conflicts. A three-week branch becomes an integration project in itself.
If a task is large, the answer is not a long branch: it is to split the task into pieces that can be integrated separately, even if they remain behind a switched-off toggle.
