This guide explains how to create, review, and merge Pull Requests.
git push -u origin feat/your-feature-name- Go to your repository on GitHub
- Click "Pull requests" → "New pull request"
- Select:
- base:
main - compare:
your-branch-name
- base:
- Fill out the PR template
- Create the Pull Request
The template will automatically populate. Fill out:
- Description - What changes and why
- Type of Change - Bug fix, feature, docs, etc.
- Testing - How you tested it
- Screenshots - If UI changes (optional but helpful)
- Checklist - Ensure everything is complete
Before merging, your PR must:
-
CI Build Pass
- TypeScript compilation (
npm run typecheckfor frontend) - Production build (
npm run buildfor frontend) - Tests pass (when configured)
- TypeScript compilation (
-
No Merge Conflicts
- Branch is up to date with
main - Resolve conflicts locally if needed
- Branch is up to date with
- PRs can be merged without review
- Review is encouraged but not required
- Complex changes should seek review
Our GitHub Actions workflow runs on every PR:
-
Frontend Build
- TypeScript compilation
- Vite production build
- Note: Lint checks are disabled (shadcn compatibility)
-
Backend Checks
- Python syntax validation
- Import checking
- pytest (when tests exist)
Push to PR branch
↓
GitHub Actions Triggered
↓
┌─────────────────┐
│ Build Frontend │
│ - TypeScript │
│ - Vite build │
└────────┬────────┘
│
┌────────▼────────┐
│ Build Backend │
│ - Python │
│ - pytest │
└────────┬────────┘
│
[Pass?]
/ \
Yes No
/ \
↓ ↓
Merge Fix Issues
Allowed & Retry
Check the Actions tab on GitHub or the status checks on your PR page.
If CI fails:
- Click on the failed check to see logs
- Fix the issue locally
- Push the fix
- CI will re-run automatically
For complex changes, request review:
- Click "Reviewers" on the right side of the PR
- Select team members
- Wait for feedback
- Make requested changes
- Commit with descriptive messages
- Push to the same branch
- Changes appear automatically in the PR
- Re-request review if needed
- Code follows project conventions
- Logic is correct
- Edge cases are handled
- No obvious bugs
- Tests are appropriate
The reviewer/merger decides the merge strategy.
Combines all commits into one clean commit.
When to use:
- Feature has many small "work in progress" commits
- You want clean, logical history in main
Result:
main: A → B → C → D (squashed feature)
Preserves all individual commits.
When to use:
- Each commit is meaningful and complete
- You want full development history
Result:
main: A → B → C → M (merge commit)
↘
feature: D → E → F
- ❌ Force push to main
- ❌ Rewrite history on shared branches
- ❌ Merge broken code
- ❌ Merge without passing CI
GitHub will offer to delete the branch after merge. Click "Delete branch".
Or locally:
git checkout main
git pull origin main
git branch -d feat/your-feature # Delete local branch- Check that the feature works
- Monitor for any issues
- Be ready to revert if needed
If your PR fixes an issue:
- Use "Closes #123" in PR description
- GitHub will auto-close the issue on merge
Update your branch:
git checkout main
git pull origin main
git checkout your-branch
git merge main
# Resolve conflicts if any
git push- Check the error logs in GitHub Actions
- Run the failing command locally:
cd frontend/atla && npm run typecheck cd backend && pytest
- Fix and push
Resolve conflicts locally (see Contributing Guide for steps).
# Push branch and create PR
git push -u origin feat/my-feature
# Update branch with main
git checkout main
git pull origin main
git checkout feat/my-feature
git merge main
# Clean up after merge
git checkout main
git pull origin main
git branch -d feat/my-feature1. Create branch from main
2. Make changes and commit
3. Push to GitHub
4. Open Pull Request
5. Wait for CI (must pass)
6. Get review (optional)
7. Merge to main
8. Delete branch
9. Verify in production
- Contributing Guide - Getting started with contributions
- Branching Guide - Git workflow and branch naming
- Commit Conventions - How to write commit messages