f in x
Git Branching: Create, Merge, Delete, and Resolve Conflicts — Hands-On Guide
> cd .. / HUB_EDITORIALE
Analisi dei dati e metriche

Git Branching: Create, Merge, Delete, and Resolve Conflicts — Hands-On Guide

[2026-06-04] Author: Ing. Calogero Bono

Have you ever worked on a shared project, made changes, and then found someone overwritten your work? If you're here, you know that feeling. Git branching is the solution: it lets you isolate changes, experiment fearlessly, and work in parallel without stepping on each other's toes. We, at Meteora Web, use it daily to manage dozens of projects — from WordPress sites to Laravel platforms. This guide teaches you how to create, merge, delete branches, and handle conflicts. No abstract theory: real commands, real examples, and a procedure you can apply right now.

What is a branch and why you need it

A branch in Git is a movable pointer to a specific commit. Think of a tree: the trunk is the main branch (usually main or master), side branches are for features, bugfixes, or experiments. Working on a separate branch means your changes don't affect others' work until you decide to merge them. This is essential in teams, but also as a solo developer: you might have a stable version (main) and another where you test a risky new feature. If it fails, delete the branch — no harm done.

The concrete advantage: zero accidental overwrites, ability to work on multiple fronts simultaneously, and a clear history of what was done and when. We apply it to our clients' code too: every change has its branch, every merge is tracked. If something breaks, you know exactly which branch caused it.

View existing branches

Before creating, know where you are. Use:

git branch

Shows all local branches. The active branch has an asterisk (* main). To see remote ones too:

git branch -a

Creating a branch

Creating a branch is immediate. The basic command:

git branch branch-name

Creates a new branch pointing to the same commit you are on now. To switch to it immediately, combine:

git checkout -b branch-name

Or, with Git 2.23+, the modern way:

git switch -c branch-name

Practical example: you need to add a "Contact" section to your site. Create a branch feature/contact and start working. Meanwhile, main stays clean, deployable.

A rule we follow: branch names should be descriptive. Use feature/, bugfix/, hotfix/ as prefixes. Avoid generic names like mods or temp — after a week you won't remember what they contained.

Choosing where to start

If you want to create a branch from a specific commit (not the latest), pass the commit hash:

git branch branch-name <commit-hash>

Useful for hotfixes on a previous version already in production.

Working on a branch

Now you're on branch feature/contact, make your changes, add, commit. Git records commits on that branch, not on main. You can switch between branches with:

git switch main

Git updates the working directory files to reflect the state of the chosen branch. Caution: if you have uncommitted changes, Git might block you. Either commit or use git stash to temporarily put them aside.

Merging a branch

When the feature is ready, you want to bring changes into main. Two main scenarios.

Fast-forward merge

Occurs when main has had no new commits since your branch was created. Git can simply move the main pointer forward. Command:

git switch main
git merge branch-name

If no divergence, you'll see "Fast-forward". History is linear.

Merge with merge commit (three-way merge)

If main received other commits while you worked, Git performs a three-way merge: it combines changes from main, your branch, and the common ancestor. A merge commit is created with two parents. Command is the same, but Git automatically creates the merge commit (unless you use --no-ff to force it or --ff-only to fail if not possible).

We, at Meteora Web, always use git merge --no-ff branch-name on shared projects. Even if fast-forward is possible, we create an explicit merge commit. This keeps track that that group of commits belonged to a specific feature. Browsing history becomes clearer.

Resolving merge conflicts

Conflicts happen. Git cannot decide which change to keep. It occurs when two branches modified the same lines of the same file. The error message is clear: "Automatic merge failed; fix conflicts and then commit the result."

Identify conflicts

Use git status to see conflicted files. Inside the file you'll find markers like:

<<<<<<< HEAD
code from current branch (main)
=======
code from the branch being merged (feature/contact)
>>>>>>> branch-name

HEAD is your current branch, the other section is the incoming one.

Resolve manually

Open the file in an editor. Decide which version to keep or combine both. Remove conflict markers. Save. Then:

git add resolved-file
git commit

Git shows a pre-filled message you can edit. Done — merge completed.

Graphical tools: If you prefer visual interface, use git mergetool which opens tools like Meld, Beyond Compare, or your editor with diff3 support.

Strategy to avoid conflicts

  • Update your branch often: run git merge main on your feature branch regularly. Resolve conflicts early, not all at the end.
  • Communicate in the team: if you know someone else is modifying the same files, coordinate.
  • Keep branches small and short-lived: a branch that lasts weeks is a ticking time bomb. Better small features and frequent merges.

Deleting a branch

After merging, you can clean up the local branch:

git branch -d branch-name

Git will prevent you from deleting a branch that hasn't been merged (data loss). If you're sure you want to discard it, force with -D (uppercase).

To delete a remote branch (e.g., on GitHub):

git push origin --delete branch-name

Or with shorthand:

git push origin :branch-name

Caution: this only deletes the remote branch. The local one remains, so delete it too.

Prune stale remote references

After deleting many branches, your local remote-tracking branches may have stale entries. To synchronize:

git remote prune origin

In summary — what to do now

  1. Open your terminal in your Git project folder and type git branch to see where you are.
  2. Create a test branch with git checkout -b test-branch, make a change, commit, and switch back to main (git switch main).
  3. Merge the test branch with git merge test-branch. If no conflicts, you've practiced.
  4. Simulate a conflict: create another branch, modify the same lines in the same file, attempt a merge, and resolve the markers manually.
  5. Clean up: delete the test branch (git branch -d test-branch).

Branching is a superpower. Use it and you'll never go back. If you have a legacy project without branches, start now: create a branch for your next change. Your future peace of mind is worth the half-line command.

Sponsored Protocol

Ing. Calogero Bono

> AUTHOR_EXTRACTED

Ing. Calogero Bono

Co-founder di Meteora Web. Ingegnere informatico, sviluppo ecosistemi digitali ad alte prestazioni. AI, automazione, SEO tecnica e infrastrutture web. Scrivo di tecnologia per rendere complesso… semplice.

[ Read Full Dossier ]

Hai bisogno di applicare questa strategia?

Esegui il protocollo di contatto per iniziare un progetto con noi.

> INIZIA_PROGETTO

Sponsored

> MW_JOURNAL

> READ_ALL()