git-workflow-and-versioning

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

Target around 100 lines per commit and split anything approaching 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. Gitflow uses long-lived development branches, which accumulate merge risk; the commit discipline principles apply to either model.

Git worktrees let you check out multiple branches in separate directories simultaneously, so agents or developers work in parallel without branch switching. Use 'git worktree add ../project-feature feature/name' and remove it after merging.

Commit generated files only when the project expects them, like gradle-wrapper.jar or libs.versions.toml. Never commit build output, local.properties, secrets, or IDE configs; cover these with a .gitignore including build/, .gradle/, and *.apk.

Use git bisect: mark a bad commit with 'git bisect bad HEAD' and a known-good one with 'git bisect good <commit>', then git checks out midpoints for you to test. Combine with git log --grep and git blame to narrow down changes.