Commits & Pull Requests
Write meaningful commits, create high-quality PRs, and run effective code reviews that improve reliability and team velocity.
Simple Explanation (ELI5)
A commit is one clear step in your work. A pull request is asking the team, “Please review my steps before we add them to main.” Good commits and PRs make collaboration easy and safe.
Technical Explanation
Commits should be atomic and logically scoped. PRs aggregate branch commits for review, CI validation, policy checks, and merge. Review quality depends on small diff size, clear context, reproducible test evidence, and explicit risk notes.
Commit Quality Rules
| Good Practice | Reason |
|---|---|
| Small atomic commits | Easier review and rollback |
| Conventional message format | Readable history and changelog automation |
| One concern per commit | Isolates defects and improves traceability |
| No generated noise | Keeps diffs meaningful |
| Link issue/ticket | Business context and audit trail |
Visual: PR Lifecycle
Hands-on Commands
# Stage selected hunks interactively git add -p # Create descriptive commit git commit -m "feat(auth): add JWT refresh token endpoint" # Amend last commit message or staged changes git commit --amend # Squash last 3 commits interactively git rebase -i HEAD~3 # Push updated branch git push origin feature/auth-refresh # If history rewritten, force push safely git push --force-with-lease
PR Checklist
- Clear title and objective.
- Linked issue/ticket.
- Test evidence (screenshots/logs/output).
- Risk and rollback notes.
- No unrelated formatting churn.
Debugging Scenarios
- PR too large to review: Split into stacked PRs by concern.
- Accidental commit message typo: Amend locally before merge.
- Wrong commits included in PR: Interactive rebase and force-with-lease.
- PR checks flaky: Re-run failing job, isolate nondeterministic tests, tag flaky suite.
Real-world Use Case
A fintech team reduced escaped defects by 35% after introducing a mandatory PR template with “risk, tests, rollback” sections. Reviewers caught migration issues before merge because PRs explicitly required backward compatibility notes.
Interview Questions
Beginner
Clear scope and intent, e.g., fix(api): handle null payment token.
To review code, run checks, and maintain quality before merge.
Peer evaluation of code for correctness, readability, and maintainability.
Combines all PR commits into one commit on target branch.
Creates traceability between business requirement and code change.
Intermediate
Amend for correcting latest commit before share; new commit for transparent history on shared branch.
After rebasing your own branch; safer than force because it checks remote state.
Limit diff size, isolate concerns, include tests and clear PR description.
Merge commit preserves branch context; rebase merge keeps linear history.
Use branch protections requiring CI checks, reviews, and status contexts.
Scenario-based
Address feedback in focused commits, update PR summary, request re-review.
Rotate secrets immediately, rewrite branch history, and run secret scan before re-open.
Compare environment differences, pin versions, and reproduce in containerized CI-like setup.
Fetch latest main, rebase/merge, resolve conflicts, rerun tests, push update.
Create separate hotfix branch from main, merge quickly, then rebase big PR.
Summary
Strong commit hygiene and disciplined PR review are core to healthy engineering culture. Keep changes small, context-rich, and fully validated before merge.