git-push-workflowlisted

# /git-push-workflow ## Critical Constraints - **NEVER work directly on `main`** — always create a feature branch first - **NEVER force push to `main`** - **NEVER merge to `main` yourself** — always use a pull request (GitHub) or merge request (GitLab) ## Branch Naming - `feature/*` — new features - `fix/*` — bug fixes - `chore/*` — maintenance tasks (dependencies, config) - `refactor/*` — code refactoring - `docs/*` — documentation only ## Branch Workflow 1. `git checkout main && git pull origin main` 2. `git checkout -b <type>/branch-name` 3. Make changes, commit as needed 4. When ready, follow the push steps below ## Commit message format ``` <type>: <subject> ``` - **Types:** `feat`, `fix`, `chore`, `refactor`, `docs`, `test` - Keep subjects under 50 characters, imperative mood ("add" not "added") ## Steps 1. **Detect remote platform** — run `git remote get-url origin`: - If `origin` is not configured, stop and ask the user to set up the `origin` remote before continuing. - If URL contains `github.com` → GitHub (use `gh pr` for PR creation) - If URL contains `gitlab.com` (or your self-hosted GitLab instance) → GitLab (use `glab mr` for MR creation) 2. **Stage and commit** (if there are uncommitted changes): - Stage relevant files — never stage `.env`, credentials, or secrets - If no uncommitted changes, skip to step 3 3. **Squash all branch commits into one:** - Count commits ahead of `origin/main` - If more than one commit: `git reset --