You're about to start a new feature. You know the general workflow—create a branch, write code, open a PR, merge—but you're not sure about all the details. Should you rebase or merge? When should you push? How do you know when the branch is truly ready to merge? What happens after merging?
Checklists turn vague knowledge into concrete action. They ensure you don't skip important steps when you're rushed or distracted. They help new team members learn your workflow quickly. They create consistency across a team, so everyone follows the same practices.
We're going to provide comprehensive checklists for the entire feature branch lifecycle: one for individual developers working on branches, and one for teams establishing feature branch processes. Use these as starting points, then customize them to match your team's specific needs.
Developer Checklist: Working with Feature Branches
This checklist guides individual developers through the complete lifecycle of a feature branch.
Before Creating Your Branch
[ ] Verify you're starting from the right place
# Ensure you're on main and it's current git checkout main git pull origin main
Starting from outdated main creates unnecessary divergence from the start. Always begin with current main.
[ ] Understand the scope of work
Be clear about what this branch should accomplish. Can you describe the feature or fix in one sentence? If not, consider whether the work should be split into multiple branches.
[ ] Check if related work exists
# Look for existing branches that might conflict git branch -a | grep -i "authentication"
If someone else is working on related code, coordinate to avoid conflicting changes.
[ ] Create or reference an issue
Link your branch to a ticket, issue, or work item. This provides context for reviewers and creates traceability.
Creating Your Branch
[ ] Use clear, descriptive naming
# Follow your team's convention git checkout -b feature/user-profile-editing # Or with issue reference git checkout -b feature/PROJ-123-user-profile-editing
Branch names should tell others what's inside without requiring further investigation.
[ ] Push the branch early
# Push even before first commit to establish remote tracking git push -u origin feature/user-profile-editing
This establishes the remote branch, enables CI/CD, and signals to teammates what you're working on.
[ ] Open a draft pull request (optional but recommended)
Create a draft PR immediately. This makes your work visible, allows early feedback, and lets CI start running.
During Development
[ ] Make small, focused commits
# Good: Atomic commit git add auth/validator.js git commit -m "Add email format validation" # Bad: Massive commit git add . git commit -m "Bunch of stuff"
Small commits are easier to review, revert, and rebase if needed.
[ ] Write meaningful commit messages
# Good format git commit -m "Add email validation to registration form Validates email format using RFC 5322 regex. Prevents users from registering with invalid emails. Related to #234" # Avoid git commit -m "fix" git commit -m "update code"
Future you will thank present you for clear commit messages.
[ ] Run tests before committing
# Always run tests first npm test npm run lint # Then commit git add . git commit -m "Your message"
Catching test failures locally is faster than waiting for CI.
[ ] Push frequently
# Push daily or after significant progress git push origin feature/user-profile-editing
Frequent pushing backs up your work, triggers CI, and keeps the team informed of your progress.
[ ] Sync with main regularly
# Daily, at start of work session git fetch origin git rebase origin/main # or git merge origin/main # Resolve conflicts immediately while context is fresh git push --force-with-lease origin feature/user-profile-editing
Daily syncing keeps conflicts small and manageable.
[ ] Keep the branch focused
If you notice unrelated issues, resist fixing them in this branch. Create separate branches for separate concerns.
Preparing for Review
[ ] Clean up commit history
# Interactive rebase to squash and reorder commits git rebase -i origin/main # Combine "WIP" commits, fix typo commits, etc.
Present a logical story to reviewers, not your messy development process.
[ ] Ensure all tests pass locally
npm test npm run test:integration npm run lint
Don't rely solely on CI. Run the full suite locally to catch issues before pushing.
[ ] Update documentation
Did you change an API? Update the docs. Add a new feature? Document how to use it. This shouldn't be an afterthought.
[ ] Review your own changes
# Review the full diff git diff main...feature/user-profile-editing # Check for debug code, console.logs, commented code
Catch embarrassing mistakes before others see them.
[ ] Write a clear PR description
Explain what changed, why it changed, and how to test it. Include screenshots for UI changes. Link to related issues.
After Opening the PR
[ ] Respond to feedback promptly
Aim to respond within 24 hours, even if just to acknowledge comments and say when you'll address them.
[ ] Make requested changes
# Make changes, commit git add . git commit -m "Address review feedback: improve error messages" git push origin feature/user-profile-editing
Each push updates the PR automatically. Keep the conversation moving.
[ ] Re-request review after changes
After addressing feedback, explicitly re-request review. Don't assume reviewers are watching for updates.
[ ] Resolve conversations
As you address comments, mark them resolved. This helps reviewers track what's been handled.
[ ] Keep the branch current during review
# If review takes days, keep syncing with main git fetch origin git rebase origin/main git push --force-with-lease origin feature/user-profile-editing
Long review periods can result in stale branches. Keep them current.
Merging
[ ] Verify all checks pass
Don't merge with failing tests, linting errors, or security issues. If a check fails, fix it.
[ ] Get required approvals
Follow your team's policy. Usually this means at least one approved review from a team member.
[ ] Choose appropriate merge strategy
- Squash and merge: For messy commit history, creates one commit in main
- Rebase and merge: For clean commit history, maintains individual commits
- Merge commit: For significant features you want preserved as a unit
[ ] Write a good merge commit message
If squashing, edit the default message to be clear and complete:
Add user profile editing feature
Allows users to update their name, email, and avatar.
Includes validation, error handling, and audit logging.
Closes #234
[ ] Merge the PR
Click that merge button. Your work is now part of main.
After Merging
[ ] Delete the remote branch
Most platforms offer automatic deletion on merge. If not, delete manually:
git push origin --delete feature/user-profile-editing
Keep the repository clean.
[ ] Update your local repository
# Switch to main and update git checkout main git pull origin main # Delete local branch git branch -d feature/user-profile-editing # Clean up remote references git fetch --prune
This completes the cleanup locally.
[ ] Verify deployment (if applicable)
If your team deploys from main automatically, verify your changes deployed correctly and aren't causing issues.
[ ] Update or close related issues
If your PR closes issues, ensure they're marked as closed and linked to your commit/PR for traceability.
Team Checklist: Establishing Feature Branch Process
This checklist helps teams set up and maintain healthy feature branch workflows.
Setting Up the Repository
[ ] Define branch naming conventions
Document your conventions in CONTRIBUTING.md:
feature/*for new featuresbugfix/*for bug fixeshotfix/*for urgent production fixesdocs/*for documentation- Optional: include ticket numbers
[ ] Configure branch protection rules
For main/production branches:
- Require pull request reviews (specify how many)
- Require status checks to pass
- Require branches to be up to date before merging
- Restrict who can push directly (usually nobody)
[ ] Set up automatic branch deletion
Enable "Automatically delete head branches" after merge in repository settings.
[ ] Create PR template
Add .github/pull_request_template.md:
## Description Brief description of changes ## Type of Change - [ ] Bug fix - [ ] New feature - [ ] Breaking change - [ ] Documentation update ## Testing How were these changes tested? ## Checklist - [ ] Tests pass locally - [ ] Documentation updated - [ ] Commits are clean and well-described
[ ] Configure CODEOWNERS (for larger teams)
Define who reviews changes to specific parts of the codebase:
# CODEOWNERS
/api/ @backend-team
/ui/ @frontend-team
/docs/ @tech-writers
Establishing CI/CD Pipeline
[ ] Set up automated testing
Configure CI to run on every push to feature branches:
- Unit tests
- Integration tests
- Linting
- Type checking
- Security scanning
[ ] Configure preview environments
Set up automatic deployment of feature branches to preview URLs for testing.
[ ] Define required status checks
Specify which CI checks must pass before merging:
- Tests
- Linting
- Build verification
- Security scans
[ ] Set up coverage tracking
Monitor test coverage and optionally require minimum coverage for PRs.
[ ] Configure deployment automation
Define what happens after merging:
- Automatic deployment to staging
- Manual deployment to production
- Release tagging
Creating Team Guidelines
[ ] Document the workflow
Create comprehensive documentation covering:
- How to create branches
- How to keep branches current
- How to request reviews
- How to handle feedback
- Merge strategies
[ ] Define "done" criteria
Establish what "ready to merge" means:
- All tests pass
- Code reviewed and approved
- Documentation updated
- No outstanding review comments
- Branch is current with main
[ ] Set expectations for PR size
Guide developers toward appropriately-sized PRs:
- Ideal: Under 400 lines changed
- Acceptable: 400-1000 lines changed
- Requires justification: Over 1000 lines changed
[ ] Establish review expectations
Define SLAs for code review:
- First response within X hours
- Full review within Y business days
- Number of approvals required
[ ] Create onboarding checklist for new developers
Help new team members get up to speed on your feature branch workflow.
Monitoring and Maintenance
[ ] Track branch metrics
Monitor key indicators:
- Average branch age
- Time from creation to merge
- Number of stale branches
- Merge frequency
[ ] Schedule regular cleanup
Set up automated cleanup or schedule manual reviews:
- Weekly audit of branches older than 30 days
- Automated deletion of merged branches
- Regular pruning of remote references
[ ] Review workflow effectiveness quarterly
Assess whether your process is working:
- Are branches merging quickly?
- Are reviews happening promptly?
- Are conflicts frequent or rare?
- Is the team happy with the workflow?
[ ] Update guidelines based on learnings
As the team grows and changes, evolve your workflow. What worked for 5 people might not work for 50.
[ ] Provide workflow training
For new team members, offer:
- Documentation
- Pairing sessions with experienced developers
- Workflow overview in onboarding
Troubleshooting Common Issues
[ ] Address long-lived branches
If branches routinely live longer than two weeks:
- Examine why (scope too large, review bottlenecks, unclear requirements)
- Break features into smaller increments
- Address review capacity issues
[ ] Handle frequent merge conflicts
If conflicts are constant:
- Increase frequency of syncing with main
- Examine whether code organization creates hotspots
- Consider whether multiple teams need coordination
[ ] Reduce CI/CD pipeline time
If pipelines take too long:
- Parallelize tests
- Use caching effectively
- Run only affected tests
- Consider faster build infrastructure
[ ] Improve review turnaround
If reviews take too long:
- Set clearer expectations
- Ensure adequate reviewer capacity
- Consider whether PRs are too large
- Use draft PRs for early feedback
Making Checklists Work for Your Team
These checklists are starting points. Customize them based on your team's size, product, and culture. A three-person startup needs a lighter process than a 50-person enterprise team.
Start with a minimal checklist and add items as you encounter problems. If you keep discovering bugs in production from untested code, add "run full test suite" to your checklist. If branches regularly go stale, add "sync with main daily."
Make checklists visible. Include them in:
- CONTRIBUTING.md
- Pull request templates
- Team documentation
- Onboarding materials
The best checklist is one that's actually followed. If your checklist is too long or bureaucratic, people will ignore it. Keep it focused on items that genuinely improve quality and prevent problems.
The Connection to Better Development Practice
Checklists externalize knowledge and create consistency. They ensure that good practices happen reliably rather than randomly. When everyone on your team follows the same feature branch workflow, code review becomes more efficient, merges go smoothly, and the repository stays healthy.
At Pull Panda, we focus on making code review effective and enjoyable. Feature branch checklists contribute to this by ensuring branches arrive at code review in good shape—tested, current with main, and clearly described. When developers follow consistent practices, reviewers can focus on the important parts: design decisions, potential issues, and suggesting improvements.
For deeper exploration of the concepts behind this checklist, see our complete guide to mastering feature branches. And to understand how to adapt these practices for different team sizes and workflows, check out our comparison of different branching strategies.