# pousse ## When to use - User asks to "commit", "push", "git add", or "save to git" - After completing code changes and the user expects a commit - Do **not** run commit/push without user validation of the commit message ## Workflow 1. **Stage all changes**: `git add -A` 2. **Propose commit message**: Build the message using the structured format below; show it to the user and wait for validation. 3. **Commit**: After validation, run `git commit -m "..."` with the approved message (use a single quoted multi-line string or `-F` with a temp file if the message is long). 4. **Push**: Run `git push` (or `git push origin ` if the context specifies a branch). Do not trigger CI if the user's rules forbid it. ## Commit message format Use this structure. Every commit must follow it. Sections can be omitted only when not applicable (e.g. no bug fix → no **Root causes:** or **Correctifs:**). ```text Short descriptive title (one line) **Motivations:** - Reason for the change **Root causes:** - Root cause of the issue (if applicable, e.g. for fixes) **Correctifs:** - What was fixed **Evolutions:** - New features or improvements **Pages affectées:** - List of modified files or modules ``` - Prefer bullet points under each section; no need for totals (e.g. "X files modified"). - Write the body in the same language as the project (e.g. French if the repo uses French). - Do not use `--no-verify` unless the user explicitly requests it and it is documented. ## Commands (summary) ```bash git add -A git status # optional: show what will be committed # Propose message → get user validation git commit -m "Title **Motivations:** - ... **Correctifs:** / **Evolutions:** / **Pages affectées:** ..." git push ``` ## Notes - On Windows, use Git Bash for shell commands when specified by the user. - Do not run in background; run commands so the user sees the full output. - If the user's rules say "do not trigger CI", use the push method that avoids triggering CI (e.g. push to a branch that does not run CI, or follow project docs).