Git Commit Conventions
Commit Message Format
[PM-XXXXX] <type>: <imperative summary>
<optional body explaining why, not what>Rules
- Ticket prefix: Always include
[PM-XXXXX]matching the Jira ticket - Type keyword: Include a conventional commit type after the ticket prefix (see table below)
- Imperative mood: "Add feature" not "Added feature" or "Adds feature"
- Short summary: Under 72 characters for the first line
- Body: Explain the "why" not the "what" — the diff shows the what
Type Keywords
Invoke the labeling-android-changes skill for the full type keyword table and selection guidance.
Example
[PM-12345] feat: Add biometric unlock timeout configuration
Users reported confusion about when biometric prompts appear.
This adds a configurable timeout setting to the security preferences.Followup Commits
Only the first commit on a branch needs the full format (ticket prefix, type keyword, body). Subsequent commits — whether addressing review feedback, making intermediate changes, or iterating locally — can use a short, descriptive summary with no prefix or body required.
Update error handling in login flowPre-Commit Checklist
Run the perform-android-preflight-checklist skill for the full quality gate. At minimum, before staging and committing:
- Run affected module tests (use
build-test-verifyskill for correct commands) - Check lint:
./gradlew detekton changed modules - Review staged changes:
git diff --staged— verify no unintended modifications - Verify no secrets: No API keys, tokens, passwords, or
.envfiles staged - Verify no generated files: No build outputs,
.idea/changes, or generated code
What NOT to Commit
.envfiles oruser.propertieswith real tokens- Credential files or signing keystores
- Build outputs (
build/,*.apk,*.aab) - IDE-specific files (
.idea/changes,*.iml) - Large binary files
Staging Best Practices
- Stage specific files by name rather than
git add -Aorgit add. - Put each file path on its own line for readability:
git add \ path/to/first/File.kt \ path/to/second/File.kt \ path/to/third/File.kt - Review each file being staged to avoid accidentally including sensitive data
- Use
git status(without-uallflag) to see the working tree state