Tools.Fun › Articles › Git Explained: Branching, Merging, and Workflows for Developers

Git Explained: Branching, Merging, and Workflows for Developers

BY TOOLS.FUN  ·  MARCH 28, 2026  ·  7 min read

Git is the version control system used by virtually every software team on the planet. Yet many developers use it mechanically — commit, push, merge — without understanding what's actually happening under the hood. This guide explains Git's core model so you can use it confidently, resolve conflicts without fear, and collaborate effectively on any team.

Related tools: use our Base64 Decoder to decode Git credential tokens, Timestamp Converter to interpret commit timestamps, Password Generator for secure Git remote credentials, and RegExp Tester to build .gitignore patterns.

Git's Core Model: Snapshots, Not Diffs

Unlike older version control systems that stored differences between files, Git stores snapshots of the entire project at each commit. A commit is a point-in-time photograph of all your files, linked to its parent commit(s). This makes branching and merging cheap and fast — operations that were slow and painful in older systems.

Everything in Git is addressed by its SHA-256 hash. A commit's hash is computed from its content, author, timestamp, and parent hash. This means you can't change history without changing all subsequent hashes — which is why force-pushing is dangerous. Use our Hash Generator to understand how content-addressed hashing works.

Commits: The Unit of Work

A commit records who changed what, when, and why. The commit message is not decoration — it's documentation for your future self and teammates. The subject line should complete the sentence "If applied, this commit will...". Keep it under 72 characters. Add a body if the why needs more explanation.

Good: Add rate limiting to the authentication endpoint
Bad: fix stuff, updates, wip

Branches: Parallel Lines of Work

A branch is simply a pointer to a commit. Creating a branch is instantaneous — Git just creates a new pointer. This makes branches cheap to create and disposable when done. Common branch types:

Merging vs Rebasing

Merge combines two branches by creating a new "merge commit" that has two parents. It preserves the full history of both branches exactly as it happened. Rebase replays your branch's commits on top of another branch, rewriting history to appear as if you'd always branched from the latest point. The result is a cleaner, linear history — but you've rewritten commits.

The golden rule of rebasing: never rebase commits that have been pushed to a shared remote branch. Rebasing rewrites history; if others have based work on your commits, rewriting them creates diverging histories that are painful to reconcile.

Merge Conflicts: What They Are and How to Resolve Them

A merge conflict occurs when two branches modify the same part of the same file in incompatible ways. Git marks the conflict in the file with <<<<<<<, =======, and >>>>>>> markers. Your job is to decide which version (or a combination) is correct, remove the markers, and commit the resolution. Use our Diff Tool to compare conflicting versions side by side before resolving.

Pull Requests and Code Review

A pull request (PR) or merge request (MR) is a proposal to merge one branch into another. It's the primary mechanism for code review in team workflows. A good PR is small enough to review in one sitting (under 400 lines changed is a reasonable target), has a clear description of what it does and why, and includes evidence that it works (tests, screenshots).

Git Workflows

Git Flow uses long-lived branches (main, develop, release, hotfix, feature). Rigorous but complex. Best for projects with scheduled releases. GitHub Flow is simpler: branch from main, open a PR, merge to main, deploy immediately. Good for continuous deployment. Trunk-based development is the most streamlined: everyone commits directly to main (or uses very short-lived feature branches), with feature flags controlling what's visible in production.

Modern recommendation: most teams are moving toward trunk-based development with feature flags. Long-lived branches create merge debt — the longer a branch lives, the more painful the eventual merge.

Essential Git Commands

The commands you'll use daily: git status, git add -p (stage interactively), git commit -m "message", git push, git pull --rebase, git log --oneline --graph, git stash / git stash pop, git diff main, git reset --soft HEAD~1 (undo last commit, keep changes staged).

← Back