Branching Strategies · Resolving Conflicts · PR Workflow & Code Review · Advanced Git

What you'll learn

• 1Compare trunk-based vs Git Flow
• 2Use short-lived feature branches
• 3Adopt naming conventions: feature/, bugfix/, hotfix/
• 4Decide when to use release branches
• 5Read <<<<<<<, =======, >>>>>>> conflict markers
• 6Resolve a merge conflict step by step
• 7Choose between merge and rebase intentionally
• 8Use VS Code's merge editor
• 9Write a good PR title and description
• 10Keep PRs small and focused
• 11Leave specific, kind, actionable review comments
• 12Respond to feedback without ego
• 13Squash commits with interactive rebase
• 14Cherry-pick a commit onto another branch
• 15Recover deleted commits with reflog
• 16Find which commit introduced a bug with bisect

Branching Strategies

Pick a branching strategy that fits team size and release cadence. Compare trunk-based with Git Flow, and adopt sane naming conventions.

1. Trunk-based Development

• main is always deployable
• Short-lived feature branches (< 1 day) merged via PR
• Use feature flags for in-progress work
• Best for small/medium teams shipping daily

2. Git Flow

• main = production
• develop = integration of completed features
• feature/X branches off develop, merges back
• release/X branches for staging, hotfix/X for emergencies
• Best for slower release cycles (monthly+)

3. Naming Conventions

4. Cleaning Up

# Delete merged branches locally
git branch --merged | grep -v '\*\|main' | xargs git branch -d

# Prune deleted remote branches
git fetch --prune

Resolving Conflicts

Conflicts are part of working with others. Learn to read conflict markers, choose between merge and rebase, and use VS Code's three-way merge tool.

1. What a Conflict Looks Like

<<<<<<< HEAD (current branch)
const greeting = "Hello, world!";
=======
const greeting = "Hi, world!";
>>>>>>> feature/branch

• <<<<<<< HEAD — your current branch's version
• ======= — the divider
• >>>>>>> branch-name — the incoming branch's version

2. Resolve

1. Open the conflicted file in your editor
2. Decide what to keep — yours, theirs, or a combination
3. Remove all conflict markers
4. git add <file>
5. git commit (merge commit message is auto-filled)

git status                    # see conflicted files
git diff --name-only --diff-filter=U   # only conflicts
# ... edit each one ...
git add path/to/file
git commit

3. Merge vs Rebase

4. Tooling

• VS Code shows "Accept Current / Incoming / Both" buttons inline
• git mergetool — opens your configured merge tool
• git rerere — remembers resolutions for similar future conflicts

PR Workflow & Code Review

Open clear, reviewable pull requests. Write good PR descriptions, structure commits, leave actionable review comments, and respond gracefully to feedback.

1. Anatomy of a Good PR

• Title — what changed, in one line ("Fix login redirect on Safari")
• Why — what problem this solves; link to issue if any
• What — short summary of the approach
• How to test — concrete steps for reviewers
• Screenshots — required for any visible change

## What
Fixes the login redirect loop when Safari blocks 3rd-party cookies.

## Why
Users on Safari got bounced back to /login after sign-in. Closes #123.

## How
- Switched from cookie-based session check to /api/me
- Added retry on first 401

## Test
1. Open in Safari with cross-site cookies blocked
2. Sign in
3. Confirm you stay on /dashboard

2. Keep It Small

• Aim for < 400 lines of diff
• One topic per PR
• Refactor and feature change in separate PRs
• Big PRs sit unreviewed forever

3. Reviewing Well

• Comment on the code, not the person
• Prefer questions over commands ("What about X case?")
• Label suggestions: nit:, suggestion:, blocking:
• Approve when it is good enough, not perfect
• Use GitHub Suggestions to propose small fixes inline

4. Receiving Reviews

• Assume good intent
• Disagree with reason, not emotion
• Push fixes as new commits (don't force-push during review)
• Mark threads resolved when addressed

Advanced Git

Reach for the power tools when you need them: interactive rebase, cherry-pick, reflog for recovery, and bisect for hunting a regression.

1. Interactive Rebase

git rebase -i HEAD~5    # the last 5 commits

# pick   abc1234 Implement feature
# squash def5678 Fix typo
# squash 901234a Fix another typo
# reword 5678abc Final touches
# drop   123abc5 Unrelated commit

Use pick, squash, reword, fixup, drop, edit to reshape history before opening a PR. Only on your own branches!

2. cherry-pick

git cherry-pick <hash>             # apply a single commit
git cherry-pick <hash1>..<hash3>   # range
git cherry-pick -x <hash>          # add original SHA in message

Great for hotfixes: cherry-pick a bug fix from main onto a release branch.

3. reflog — Time Machine

git reflog                     # see every HEAD movement
git reset --hard HEAD@{4}      # jump back to an earlier state

4. bisect — Find the Bad Commit

git bisect start
git bisect bad                 # current commit is bad
git bisect good v1.0.0         # this older one was good
# git checks out the midpoint — test the code
git bisect good                # if it works
# OR
git bisect bad                 # if it fails
# repeat until git points at the offender
git bisect reset