git-workflow-and-versioning

Use the format type: short description, where type is feat, fix, refactor, test, docs, or chore. Add an optional body explaining why the change was made, not what changed, since the diff already shows the what.

Target roughly 100 lines per commit and split anything over 1000 lines. Separate refactoring from feature work into distinct commits, and keep formatting changes apart from behavior changes so each commit does one logical thing.

Trunk-based development keeps main always deployable with short-lived feature branches merged within 1-3 days, while gitflow uses long-lived development branches. DORA research correlates trunk-based development with high-performing engineering teams.

Run git worktree add ../project-feature-a feature/task-creation to create a separate directory on its own branch. Multiple agents can work simultaneously without branch switching, and failed experiments are removed with git worktree remove.

Never commit node_modules, build output like dist or .next, environment files like .env, or secrets. Set up a .gitignore immediately covering these, and scan staged diffs for passwords, API keys, and tokens before committing.

Use git bisect start, mark the bad commit with git bisect bad HEAD and a known-good commit with git bisect good. Git checks out midpoints automatically so you can run your test at each step to narrow down the culprit.