Git Branching Basics

Git branching lets you work on features, fixes, or experiments in isolated lines of development without touching the main codebase. Branches make parallel work safe: you can develop, test, and review before merging into the shared branch.

This page is a compact, practical guide to git branching explained for developers who want simple, reliable workflows.

Concept explained

• A branch is a movable pointer to a commit. The default branch is commonly named main or master.
• Creating a branch doesn't copy files – it creates a new pointer and lets commits advance that pointer.
• Branches let teams isolate work: feature branches, bugfix branches, release branches.
• Merging integrates changes from one branch into another. Two typical strategies: merge (creates a merge commit) and rebase (rewrites commits onto a different base).

tip

Common branch naming patterns:

• feature/<short-name> (new feature)
• fix/<issue-id> (bugfix)
• chore/<task> (non-functional change)

Step-by-step example

Follow this minimal workflow to create a feature branch, push it, and merge it back.

1. Start on the main branch and update it:

git checkout main
git pull origin main

2. Create and switch to a feature branch:

git checkout -b feature/add-login

3. Work, stage, commit:

git add .
git commit -m "Add basic login flow"

4. Push the branch to the remote and set upstream:

git push -u origin feature/add-login

5. Open a pull request (or merge request) on your git host, review, then merge into main. Locally, update main and clean up:

git checkout main
git pull origin main
git branch -d feature/add-login        # deletes local branch after merge
git push origin --delete feature/add-login  # optional: delete remote branch

Example: resolve a simple merge conflict

If a merge produces conflicts:

git checkout main
git merge feature/add-login
# edit conflicted files, then:
git add conflicted-file
git commit

Variations & gotchas

• Merge vs rebase:
  • Merge preserves history and records the merge commit.
  • Rebase creates a linear history by replaying commits onto a new base.
    caution

    Avoid rebasing commits that have already been pushed and shared with others – rewriting shared history causes problems for collaborators.

• Fast-forward merges: if main hasn't diverged, merging may fast-forward and avoid a merge commit.
• Feature branches for long-lived work require frequent rebasing or merging from main to reduce conflicts.

Common mistakes

• Committing directly to main for new features – loses isolation.
• Rebasing public/shared branches – forces others to rebase their work.
• Deleting a branch before the merge is confirmed on the remote.
• Forgetting to set git push -u and later pushing to the wrong remote/branch.

Best practices

• Keep branches focused and short-lived (one logical change per branch).
• Use clear branch names (see tip above).
• Push early and often to back up work and enable CI/previews.
• Use pull requests for discussion and code review.
• Update your branch from main regularly to surface conflicts early.

tip

Set your local Git to prefer main name and helpful defaults: git config --global init.defaultBranch main

When to use / when not to use

When to use branching:

• Building a feature, hotfix, or experiment.
• Collaborating with teammates and using code review.
• Running CI/CD per-branch (previews/testing).

When not to use branching:

• Small one-line edits on non-critical repos may be fine via direct commits, but use branches when in doubt.

Key takeaways

• Branches are cheap pointers that isolate work from main.
• Use short-lived, focused branches and clear names.
• Prefer merging for shared history; only rebase private branches.
• Push branches early so CI and teammates can review and test.