Pull Requests
A pull request (PR) proposes merging one branch into another. It creates a discussion thread and triggers CI checks before any code lands in main.
# 1. Create a branch locally
git switch -c feature/add-search
# 2. Push it to GitHub
git push -u origin feature/add-search
# 3. Open a PR on github.com (or via CLI)
gh pr create --title "feat: add search" --body "Closes #42"PR Best Practices
- Keep PRs small and focused — one feature or fix per PR.
- Write a clear description explaining why, not just what.
- Link the related issue (
Closes #123). - Request specific reviewers, not the whole team.
Code Review
Good code review comments are specific and constructive:
Good: "This loop runs O(n²). We could use a Map here to bring it down to O(n). See [line 42]."
Avoid: "This is wrong."
Protected Branch Rules
In GitHub Settings → Branches, set rules on main:
- ✅ Require pull request before merging
- ✅ Require status checks to pass (CI)
- ✅ Require at least 1 approving review
- ✅ Dismiss stale reviews on new pushes
- ✅ Restrict who can push
Useful GitHub CLI Commands
gh pr list # list open PRs
gh pr checkout 42 # check out PR #42 locally
gh pr review --approve # approve current PR
gh pr merge --squash --delete-branch # merge and clean up
gh issue create --title "Bug: ..." # open a new issueSemantic Commit Messages
Follow the Conventional Commits spec so changelogs can be generated automatically:
feat: add OAuth2 login
fix: handle null user in session middleware
docs: update deployment guide
chore: upgrade eslint to v9
refactor: extract payment service