$npx -y skills add fusengine/agents --skill git-flowUse when committing, branching, opening PRs, or deciding merge strategy. Covers GitHub Flow (default), trunk-based, branch naming conventions, squash vs rebase, branch lifecycle, and protected branch enforcement.
| 1 | # Git Flow Best Practices (2026) |
| 2 | |
| 3 | ## Workflow Choice |
| 4 | |
| 5 | | Strategy | When | Verdict | |
| 6 | |----------|------|---------| |
| 7 | | **Trunk-based** (direct main) | Solo dev, prototypes, strong CI | OK if you have automated tests | |
| 8 | | **GitHub Flow** (feature branch → PR → merge → delete) | Teams, OSS, code review | ✅ Default | |
| 9 | | **Git Flow** (develop/release/hotfix) | Heavy release cycles | ❌ Outdated for most projects | |
| 10 | |
| 11 | **fuse-commit-pro default: GitHub Flow.** |
| 12 | |
| 13 | ## Branch Naming Convention |
| 14 | |
| 15 | Format: `<type>/<scope-or-summary>` (kebab-case). |
| 16 | |
| 17 | | Type | Use | Example | |
| 18 | |------|-----|---------| |
| 19 | | `feat/` | New feature | `feat/seo`, `feat/oauth-google` | |
| 20 | | `fix/` | Bug fix | `fix/sniper-loop`, `fix/csv-parser` | |
| 21 | | `chore/` | Maintenance, deps | `chore/bump-deps`, `chore/rename-files` | |
| 22 | | `docs/` | Documentation | `docs/api-reference` | |
| 23 | | `refactor/` | Refactoring (no behavior change) | `refactor/extract-utils` | |
| 24 | | `perf/` | Performance | `perf/db-indexes` | |
| 25 | | `test/` | Tests only | `test/auth-coverage` | |
| 26 | | `ci/` | CI/CD config | `ci/github-actions-cache` | |
| 27 | | `build/` | Build system | `build/vite-config` | |
| 28 | | `style/` | Formatting | `style/prettier-pass` | |
| 29 | |
| 30 | **Rules**: |
| 31 | - kebab-case only (no underscores, no spaces, no caps) |
| 32 | - < 50 chars total |
| 33 | - No personal prefix (`bruno/...`) — collaborators don't know who you are 6 months later |
| 34 | - No issue number alone (`fix/123`) — meaningless once issue closed |
| 35 | |
| 36 | ## Protected Branches |
| 37 | |
| 38 | `main`, `master`, `develop`, `production` → **never commit directly**. |
| 39 | |
| 40 | `fuse-commit-pro:commit` enforces this in Step 0: |
| 41 | - Detects current branch |
| 42 | - If protected → blocks + proposes auto-named feature branch from commit type/scope |
| 43 | - Exceptions: solo prototype (no remote), explicit `--no-branch-check`, or post-commit version bump |
| 44 | |
| 45 | ## Branch Lifecycle |
| 46 | |
| 47 | ``` |
| 48 | 1. git checkout -b feat/<scope> # create |
| 49 | 2. work + commit # multiple commits OK |
| 50 | 3. git push -u origin feat/<scope> # push with upstream |
| 51 | 4. gh pr create # open PR |
| 52 | 5. (review + CI) |
| 53 | 6. gh pr merge --merge --delete-branch # merge + cleanup |
| 54 | ``` |
| 55 | |
| 56 | **Keep branches short-lived** (< 3 days ideally). Long-lived branches accumulate conflicts and lose context. |
| 57 | |
| 58 | ## Merge Strategy |
| 59 | |
| 60 | | Strategy | When | Result | |
| 61 | |----------|------|--------| |
| 62 | | **Merge commit** | fuse-commit-pro default | Branch commits (incl. the bump commit) land on `main` intact, no rewrite | |
| 63 | | **Rebase merge** | Small atomic commits worth preserving, no merge commit wanted | Linear history, individual commits kept | |
| 64 | | **Squash merge** | *not used here*: the release tag points at the bump commit, squash would orphan it | 1 commit per feature, but incompatible with fuse-commit-pro's post-merge tagging | |
| 65 | |
| 66 | **fuse-commit-pro recommendation**: real merge commit via `gh pr merge --merge --delete-branch` (see `commands/commit.md` Step 7). |
| 67 | |
| 68 | ## CI Gate Before Merge |
| 69 | |
| 70 | **Cardinal rule: never merge before CI checks are resolved; never assume "zero CI" without verifying.** |
| 71 | |
| 72 | **Known race condition** ([cli/cli#7401](https://github.com/cli/cli/issues/7401), confirmed by GitHub CLI maintainers): checks take a few seconds to register on a freshly-created PR. Calling `gh pr checks --watch` immediately after `gh pr create` can error out — exit code 1, `no checks reported on the '<branch>' branch` — even though checks are about to appear. The GitHub API gives no way to tell "genuinely zero checks" apart from "not registered yet," so the client must either sidestep the race (native auto-merge) or poll for registration before watching. |
| 73 | |
| 74 | Determine which of the three cases applies from what actually exists on the PR — never from assumption. The key branch point is **whether the repo enforces *required* status checks in branch protection**, not merely whether auto-merge is available: `gh pr merge --auto` only ever waits for *required* checks. On a repo where checks run but aren't marked required (e.g. this repo — CodeQL + Analyze execute but aren't required), `--auto` merges **immediately without waiting**, silently reproducing the exact race this section exists to close. Check first with `gh pr checks <pr> --required` (empty output / `no required checks reported on the '<branch>' branch` → no required checks configured) before picking a branch: |
| 75 | |
| 76 | 1. **Repo has required status checks in branch protection** → the only case where `--auto` actually gates. GitHub waits server-side for the *required* checks to appear and pass — no race, regardless of their state at call time: |
| 77 | ```bash |
| 78 | gh pr merge <pr> --auto --merge --delete-branch |
| 79 | ``` |
| 80 | Also requires "Allow auto-merge" enabled in repo Settings → General (otherwise `GraphQL: Auto merge is not allowed for |