git-workflow-and-versioning

Use the format 'type: short description' with types like feat, fix, refactor, test, docs, or chore. Add a body explaining why the change was made, not what changed, since the diff already shows that.

Trunk-based development keeps main always deployable with short-lived feature branches merged within 1-3 days. DORA research links it to high-performing teams, though the commit discipline principles adapt to gitflow or other branching models.

Target around 100 lines per commit or PR for easy review and reverts. Changes near 300 lines are acceptable for one logical change, but anything approaching 1000 lines should be split into smaller commits.

Run 'git worktree add ../project-feature-a feature/task-creation' to create a separate directory per branch. Multiple agents or developers can work simultaneously without branch switching, then remove worktrees after merging.

Use 'git bisect start', mark the bad and known-good commits, and git will checkout midpoints for you to test. You can also use git blame on a file or git log --grep to search commit messages.

Commit generated files only when the project expects them, such as package-lock.json or Prisma migrations. Never commit build output, .env files, or secrets, and ensure .gitignore covers node_modules, dist, and environment files.