Commit Changes

Stage and commit changes with proper commit message formatting.

Git Executable

If bin/scm-tools-git exists in the project root, use bin/scm-tools-git instead of git for the commit step. All other git commands (status, diff, add, log, etc.) use plain git.

Workflow

•
If brivlo:send_event is available, use brivlo:send_event scm-tools:commit as your first step.
•
Review changes:
bash
```
git status
git diff
git diff --staged
```

•

Stage explicitly:

bash

git add app/models/user.rb
git add spec/models/user_spec.rb

Or interactively: git add -p

•
Verify staging:
bash
```
git diff --staged
```

•

Commit with heredoc:

bash

git commit -m "$(cat <<'EOF'
Subject line here

Optional body explaining why, wrapped at 72 chars.
EOF
)"

•
Verify:
bash
```
git log --oneline -1
```

Git Tool Usage (Safety Rules)

Staging & Unstaging

Task	Do	Don't
Stage	`git add <path>`, `git add -p`	`git add -A`, `git add .`
Unstage	`git restore --staged <path>`	`git reset <path>`

•Stage explicitly; no blanket adds
•Use git add -p to split changes into logical commits

File Operations

Task	Do	Don't
Delete tracked	`git rm [-r] <path>`	`rm <path>`
Rename/move	`git mv <old> <new>`	`mv <old> <new>`

History Safety

•Use git revert <sha> to undo merged history on shared branches
•If you must force push, use --force-with-lease (never plain --force)
•Never run git reset --hard on shared work without confirmation

Commit Message Rules

•Subject line ≤50 characters
•Capitalize the subject
•No period at the end
•Imperative mood — "Add", "Fix", "Update" (not "Added", "Fixed")
•Wrap body at 72 characters — insert line breaks manually
•Explain what and why, not how
•NEVER add branding or footers — no Co-Authored-By, no signatures

Good Examples

code

Add validation for email format
Fix login timeout on slow connections
Update dependencies to patch CVE-2024-1234

Bad Examples

code

Fixed the bug                    # past tense, vague
Updates to the login page.       # third person, period, vague
WIP                              # meaningless

When to Split Commits

If changes span multiple concerns, make multiple commits:

•Separate refactoring from feature work
•Separate test additions from implementation
•Separate dependency updates from code changes

Output

After committing, report:

•What was committed (files, summary)
•The commit hash
•The commit message used