PR Workflow: From Branch to Merge

Most Git “collaboration pain” comes from missing expectations:

• how to name branches
• what a PR should contain
• how conflicts/reviews are handled
• what merge method the team expects

This tutorial gives a practical PR workflow you can apply immediately.

Learning outcomes

You’ll be able to:

• describe PR contents clearly
• keep branches up-to-date with main
• resolve conflicts without losing changes
• understand merge strategies (merge commit vs squash)

1) Branch naming and scope

Example pattern:

• feature/<short-topic>
• bugfix/<short-topic>
• chore/<tooling-change>

Keep branches focused: one PR should usually solve one problem.

2) Writing a strong PR description

Use a structure like:

• What: 1–3 bullet summary
• Why: context/background
• How to test: exact commands/steps
• Risk: what could break, and how to rollback

Example (template):

## What
- Add retry logic to startup health check
- Improve log messages for permission failures

## Why
Production restarts were caused by misconfigured /var/log permissions.

## How to test
1) Run locally: npm test
2) Run service: ./start.sh
3) Verify logs: check /health endpoint and journalctl

3) Sync your branch with main

Before requesting review, update your branch.

# fetch remote updates
git fetch origin

# update local main
git checkout main
git pull --ff-only origin main

# return to feature branch and rebase
git checkout feature/my-change
git rebase main

If your team doesn’t want rebases, do a merge instead:

git checkout feature/my-change
git merge main

4) Conflict resolution (clean approach)

When rebase/merge stops:

1. open conflicted files
2. decide final content
3. stage resolved files
4. continue

For rebase:

# see what’s conflicted
git status

# after editing
git add path/to/file

# continue rebase
git rebase --continue

For merge:

git status
# after editing
git add path/to/file

# finish merge
git commit

5) Keeping reviews efficient

Good review requests:

• ask specific questions (“Is the rollout plan safe?”)
• limit reviewers to those who matter
• include test steps and logs

6) Merge strategies (what they mean)

Merge commit

Preserves branch history.

• Pros: full history kept
• Cons: “extra” merge commit nodes

Squash merge

Creates one new commit on main.

• Pros: clean main history
• Cons: loses intermediate commits (branch history becomes compressed)

Rebase + fast-forward (team dependent)

Often used to keep history linear.

• Pros: linear history
• Cons: requires consistent policy

7) Post-merge verification

After merge:

• check CI status
• deploy to staging (or run smoke tests)
• confirm logs/metrics

Next steps

Next in the DevOps track:

• GitHub Actions CI pipeline basics
• Secrets, environments, and artifacts
• Terraform apply workflows