Branching Strategy

The project follows trunk-based development with main as the production branch.

Rules

• Never push directly to main — enforced by org-level GitHub ruleset
• All changes go through pull requests
• Squash merge only — maintains linear commit history
• Delete feature branches after merge

Branch Naming

Prefix	Use
feat/<description>	New features
fix/<description>	Bug fixes
chore/<description>	Maintenance, tooling, dependencies

Workflow

1. Create branch from main
   git checkout -b feat/my-feature

2. Develop and commit
   git add . && git commit -m "feat: add my feature"

3. Push and create PR
   git push -u origin feat/my-feature
   gh pr create

4. CI runs automatically
   - Lint, typecheck, build (site)
   - Typecheck, test (worker)

5. Preview deploy (Cloudflare Pages)
   - Auto-deploys on PR branch push

6. Review and merge
   - Wait for CI to pass
   - Squash merge to main

7. Production deploy
   - Auto-triggers on push to main
   - Site deploys to Cloudflare Pages
   - Worker deploys to Cloudflare Workers

8. Cleanup
   - Feature branch auto-deleted
   - Preview environment torn down

Commit Convention

The project uses Conventional Commits for automated releases:

Prefix	Type	Version Bump
feat:	New feature	Minor
fix:	Bug fix	Patch
chore:	Maintenance	None
docs:	Documentation	None
refactor:	Refactoring	None
test:	Tests	None

Include a scope for specificity: feat(chat): add typing indicator

Preview Deploys

Pull requests automatically get a preview deployment on Cloudflare Pages. The preview URL follows the pattern:

pr<N>.anshulbisen.sdfsdf.in

Preview environments are torn down when the PR is merged or closed.