- [ ] **State your “one logical change per commit” rule.**
→ *Document in `README` → “Git Workflow”: small, atomic commits with clear scope; avoid mixing refactor + feature in one commit.*
- [ ] **Question:** What is your commit frequency?
→ *Agree on “commit early, commit often,” but push after tests pass or when you need collaboration. Even some rule of thumb: like at least one push per day, and one commit per hour. Note this in `README`.*
- [ ] **Run checks before committing.**
→ *Set up `pre-commit`/linters/tests locally; document install steps in `CONTRIBUTING.md`. No pushing code that fails local checks.*
- [ ] **No broken main/dev.**
→ *Enable branch protection so `main` (and `dev` if used) will be stable and a safe place to fall back if shit hit the fan; record rules in `README`.*
- [ ] **Question:** When do you squash or rebase, if ever?
→ *Define policy (e.g. “squash on merge to main; rebase feature branches on latest `dev` before MR”). Add to `README`.* (No rebase and squash processes often easier to flow.)
- [ ] **Force-push policy.**
→ *Disallow force-push on protected branches; allow on personal feature branches only when necessary (e.g. after interactive rebase). Note rule in `README`.*
- [ ] **WIP work & drafts.**
→ *Use `draft:` merge requests or a `wip/…` branch prefix. What does it mean for your project? Document in `CONTRIBUTING.md`.*
- [ ] **Link work to issues.**
→ *Reference issues in commits/MRs (`Fixes #123`, `Refs #456`). Make this mandatory in `README` → “Git & Issue Integration.”*
- [ ] **Review-before-merge.**
→ *Require 1–2 approvals on MRs to protected branches. State who can approve (role-based) in `CONTRIBUTING.md`.*
- [ ] **Secrets & large files.**
→ *Use secret scanning; never commit credentials. For big/binary assets store externally. Add `.gitignore` entries and note rationale in an issue if nonstandard.*
- [ ] **Line endings & file norms.**
→ *Add `.editorconfig` / `.gitattributes` for LF/CRLF normalization and binary hints. Commit these and mention in `CONTRIBUTING.md`.*
- [ ] **Question:** What happens when the pipeline is red?
→ *Define ownership: the last pusher or assignee fixes it immediately; no merging while red. Document in `README`.*
- [ ] **Cleanup cadence.**
→ *Delete merged branches weekly; open an issue labeled `workflow-improvement` if clutter persists.*