Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

5.4.1. Branching Strategies and Merge Conflicts

Common Branching Models:
WorkflowDescriptionBest For
Trunk-basedAll changes go to main; short-lived feature branchesFast-moving teams; CI/CD
Gitflowmain + develop + feature/release/hotfix branchesScheduled release cycles
GitHub flowmain + feature branches + pull requestsWeb applications; continuous deployment
Merge Conflict Resolution:
# Conflict happens during merge
git merge feature-x
# AUTO-MERGING FAILED in file.txt — conflict markers inserted

# Conflict markers in the file:
<<<<<<< HEAD
current branch content
=======
incoming branch content
>>>>>>> feature-x

# Resolve: edit file, remove markers, keep desired content
vim file.txt
git add file.txt                  # Stage resolved file
git commit                        # Complete the merge

# Or use a merge tool
git mergetool                     # Opens configured merge tool
git config --global merge.tool vimdiff

# Abort a merge in progress
git merge --abort

Merge vs rebase: git merge joins two histories with a merge commit (two parents) and leaves the existing commits untouched. git rebase replays your commits on top of the other branch, producing a linear history — but each replayed commit gets a new SHA, which is why rebasing is reserved for branches nobody else has pulled.

Collapsing noisy commits: git merge --squash feature-x stages the branch's combined changes on the current branch without committing; a single git commit then records them as one commit. git rebase -i (below) squashes commits on the branch itself.

Rebasing:
# Rebase rewrites history — use only on private branches
git rebase main                   # Apply current branch commits on top of main
git rebase -i HEAD~3              # Interactive rebase — squash, reorder, edit last 3 commits
# Interactive rebase options:
# pick   — keep commit as-is
# squash — combine with previous commit
# edit   — pause to amend commit
# drop   — remove commit

# After rebasing, push requires force (history changed)
git push --force-with-lease origin feature-x  # Safer than --force

Keeping a fork current: a fork does not follow the original repository on its own. Add the original as a second remote and bring its new commits into your branch:

git remote add upstream https://github.com/org/project.git
git fetch upstream
git rebase upstream/main          # or: git merge upstream/main
git push --force-with-lease origin feature-x   # rebased history needs a forced push; this updates the open PR
See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder•20 professional certifications