Come funziona il merge in Git?

Question

Accepted Answer

**Il merging** combina i cambiamenti da un branch all'altro — tipicamente riportando un feature branch completato nel branch principale. Git gestisce la maggior parte dei merge automaticamente, ma comprendere i tipi di merge e i **conflitti** è importante. ## Merge di base ```bash git switch main # be on the branch you want to merge INTO git merge feature-x # merge feature-x's changes into main ``` Si passa al branch **target** (quello che riceve i cambiamenti) e si merge il branch **source** al suo interno. ## Fast-forward vs merge commit ```text FAST-FORWARD merge → if main hasn't changed since the branch was created, Git just MOVES main's pointer forward to the branch's latest commit (no merge commit, linear) MERGE COMMIT (three-way merge) → if BOTH branches have new commits, Git creates a new "merge commit" combining them (has two parents) → preserves that a merge happened → git merge --no-ff forces a merge commit even when fast-forward is possible ``` Git fa un fast-forward quando possibile (semplicemente avanzando il puntatore) o crea un **merge commit** (con due parent) quando entrambi i branch hanno diverguto. ## Merge conflicts ```text A CONFLICT happens when both branches changed the SAME lines differently — Git can't auto-decide which to keep, so it asks YOU to resolve: ``` ```text <<<<<<< HEAD the version from the current branch (main) ======= the version from the branch being merged (feature-x) >>>>>>> feature-x ``` ```bash # resolve: edit the file to the desired result, remove the markers, then: git add # mark the conflict resolved git commit # complete the merge # git merge --abort # or cancel the merge entirely ``` I **conflitti** si verificano quando entrambi i branch modificano le stesse righe — Git le marca e tu scegli manualmente il risultato corretto, poi effettui lo stage e il commit. ## Perché è importante Comprendere il merging è essenziale perché combinare i cambiamenti tra branch è una parte fondamentale e costante dei workflow Git collaborativi, quindi conoscere come funziona (inclusi i conflitti) è una conoscenza necessaria nel lavoro quotidiano. **Il merging** è come il lavoro completato (tipicamente i feature branch) si integra nel branch principale — l'atto routinario di portare insieme i cambiamenti che accade continuamente nello sviluppo in team. Comprendere la differenza tra un **fast-forward merge** (Git semplicemente avanza il puntatore quando il target non ha diverguto, mantenendo la storia lineare) e un **merge commit** (un merge a tre vie che crea un nuovo commit con due parent quando entrambi i branch hanno nuovi commit, registrando che un merge è avvenuto) chiarisce come Git integra i cambiamenti e l'aspetto della storia risultante. Soprattutto, comprendere i **merge conflict** — che si verificano quando entrambi i branch modificano le stesse righe diversamente, quindi Git non può decidere automaticamente e ti chiede di risolvere — è una conoscenza pratica cruciale: i conflitti sono una parte normale, inevitabile della collaborazione, e sapere come riconoscere i marker di conflitto (`<<<<<<<`, `=======`, `>>>>>>>`), modificare il file al risultato corretto e completare il merge (stage e commit) è un'abilità essenziale che spesso è fonte di ansia per chi non la comprende. Poiché integrare i cambiamenti dei branch tramite merging è fondamentale e costante nello sviluppo collaborativo, e poiché comprendere i tipi di merge e in particolare la risoluzione dei conflitti è necessario per combinare il lavoro correttamente (un compito routine e inevitabile), comprendere come funziona il merging — merge di base, fast-forward vs merge commit, e risoluzione dei conflitti — è una conoscenza Git essenziale e frequentemente applicata, una competenza centrale per la collaborazione dove la risoluzione dei conflitti in particolare è una necessità pratica che ogni sviluppatore deve affrontare con sicurezza.