Git Branch Management: From Creation to Merge

Once you have mastered commits, you have mastered Git "save" feature. Branches are Git "parallel universe" feature — pushing multiple independent development lines in the same project, then merging them together at the end.

Why You Need Branches

Imagine you are building a website and need to add a user login feature. It will take three days and involves changing several files.

Without branches, your half-written code sits in the working directory. Then your boss says there is an urgent bug to fix. What do you do? Delete the login code, fix the bug, and write it all over again? Painful.

With branches, you create a login branch and work on it. When the bug fix comes in, switch back to main. The two efforts do not interfere. When login is done, merge it back.

Git branches are implemented extremely efficiently. Creating a branch just creates a pointer, taking almost no space. This is one of the biggest differences between Git and other version control systems. In older VCS like SVN, creating a branch meant copying the entire codebase. In Git, a branch is a 41-byte text file.

Basic Operations

See what branches exist:

git branch

The current branch has an asterisk. Create a new branch:

git branch login

Switch to it:

git checkout login

Or create and switch in one command:

git checkout -b login

Make changes and commits on the login branch as usual. These only affect the login branch — main remains untouched.

When done, switch back to main:

git checkout main

Merge login in:

git merge login

Now main has all the changes from login.

If login is no longer needed, delete it:

git branch -d login

Merge Conflicts

Merging is not always smooth. If both main and login changed the same line in the same file, Git does not know which one to keep. This is a conflict.

Open the conflicted file and you will see markers like this:

<<<<<<< HEAD
content from main branch
=======
content from login branch
>>>>>>> login

HEAD represents the current branch (main), and below it is the branch being merged in. You need to manually decide what to keep — one side, both, or something new. Delete the markers, save the file, then:

git add conflicted-file
git commit

The conflict is resolved.

Modern IDEs and merge tools provide better visual interfaces for conflict resolution. VS Code, IntelliJ, and specialized tools like Beyond Compare or Kaleidoscope can make conflict resolution much more intuitive than editing raw text markers.

Honestly, conflicts are the most frustrating part of Git. But think of it this way: conflicts are actually a good thing. They mean Git found a potential problem and lets you decide instead of guessing.

Merge Strategies

Git offers several merge strategies:

• Fast-forward merge: When the target branch hasn't diverged, Git simply moves the pointer forward. Clean history, no merge commits.
• Three-way merge: When both branches have new commits, Git creates a merge commit that connects both histories.
• Squash merge: Combines all commits from the feature branch into a single commit on the target branch. Keeps the target branch history clean.
• Rebase merge: Replays feature branch commits on top of the target branch. Creates linear history.

merge vs rebase

There are two ways to integrate branches: merge and rebase.

Merge preserves the full history by creating a new "merge commit." The advantage is a truthful history; the disadvantage is that with many branches, the history graph gets complicated.

Rebase "replays" your branch commits on top of the target branch latest commit. The advantage is a clean, linear history; the disadvantage is that it rewrites history, which can cause problems on shared branches.

My advice: use rebase on your own feature branches to keep them clean, and use merge when integrating into main for a clear merge record.

The rebase command:

git checkout login
git rebase main

This replays login branch commits on top of main latest commit.

When to Prefer Rebase

Rebase is ideal when:

• You want a clean, linear history
• Working on a personal feature branch that hasn't been shared
• Preparing a branch for PR review

When to Prefer Merge

Merge is better when:

• You want to preserve the exact history of collaboration
• Multiple people work on the same branch
• The branch is already public/shared

Deleting Branches

After merging, the login branch is no longer needed:

git branch -d login

-d is a safe delete. If the branch has not been merged, Git will warn you. Use -D to force delete.

Best practice: delete feature branches after merging. A cluttered branch list makes it harder to navigate the repository and can cause confusion about which branches are still relevant.

Real-World Branch Strategy

In practice, branches are not created randomly. There is usually a set of rules.

The simplest approach: main is always stable. New features get a feature/feature-name branch. Bug fixes get a hotfix/description branch. Merge when done and delete.

In team collaboration, each person has their own branch. When a feature is done, they submit a Pull Request for review before merging to main.

One critical rule: never commit directly to main. main only accepts merges from other branches. This keeps main stable.

A Practical Tip

Sometimes you are in the middle of coding and need to switch branches, but your current changes are not ready to commit. Use git stash:

git stash

This "hides" your current changes and restores a clean working directory. After switching branches:

git stash pop

Your changes come back.

For more control over stashes, use git stash list to see all saved stashes, and apply a specific stash with git stash apply stash@{n}. You can also name stashes for easier identification: git stash save "work in progress on login feature".

Branch Naming Conventions

Good branch names communicate intent. Common patterns:

• feature/user-login — for new features
• bugfix/fix-payment-crash — for bug fixes
• hotfix/security-patch — for urgent production fixes
• docs/update-readme — for documentation updates
• refactor/payment-module — for code refactoring
• experiment/new-ui-approach — for experimental work

Using a consistent prefix makes it easy to scan the branch list and understand what each branch is for.

Wrapping Up

Branches are Git most core feature and the foundation of team collaboration. Understanding branches means you understand half of Git design philosophy.

Branches might feel cumbersome at first, especially conflict resolution. But once you get used to them, you will find it impossible to work on anything moderately complex without them.

The key principles to remember:

1. Create branches for every new piece of work
2. Keep branches short-lived and focused
3. Delete branches after merging
4. Use meaningful branch names
5. Protect your main branch through branch protection rules on GitHub or GitLab

Before you move on to the next Git tutorial, I want you to practice branch management hands-on. Create a throwaway repository, create three branches, make different changes on each, merge them together, and deliberately create a conflict between two branches and resolve it. This thirty-minute exercise will teach you more than reading ten articles about branches. The commands only become muscle memory when your fingers actually type them while your brain deals with the consequences of a merge gone wrong. If you are working on a team that uses a forking workflow rather than shared branches, the same principles apply — just adapted to Pull Requests. Fork the repository, clone your fork, create a branch in your fork, make changes, push the branch, and open a Pull Request. This workflow is the backbone of open-source collaboration on platforms like GitHub and GitLab, and understanding it deeply will serve you well whether you are contributing to a personal project or collaborating on software used by millions of people around the world. An additional technique that many experienced Git users overlook is the power of git worktree, which allows you to have multiple working directories associated with the same repository simultaneously. This means you can work on a hotfix in one directory while keeping your feature development in another, switching between them instantly without stashing or branch-switching overhead. For developers who frequently juggle multiple tasks — maintaining a production release while developing a new feature, for instance — worktrees can be a genuine productivity multiplier that eliminates the friction of context switching.

As projects grow in complexity, disciplined branch management becomes the foundation that keeps team collaboration productive rather than chaotic.

A technique that experienced Git users often overlook is the use of git worktree, which allows you to have multiple branches checked out simultaneously in separate directories. Instead of stashing changes and switching branches when you need to hotfix production while developing a feature, you can simply open a second terminal in a worktree directory. This is particularly valuable for long-running feature branches where you need to compare behavior across versions side by side. Another underused convention is the branch cleanup discipline: merging via pull requests creates a permanent record, but deleting merged branches promptly prevents the namespace from becoming polluted. A simple git fetch --prune on a regular basis keeps the remote tracking references in sync with what actually exists.