Defame1297
3920dfab20
Closes four PR #135 review findings in skill content. #2 — plugins/git/config.example.json was deleted inf5e4d0d, but four git-plugin files still told the agent to read it. The file only ever carried branching_pattern, commit_style and rebase_strategy, so the `base_branch` and scope instructions were wrong even before the deletion. Each site now describes what the skill actually does: base is `main` under GitHub Flow or `develop` when Gitflow is inferred, the Gitflow fallback keys off the repo's own branches, the orchestrator contract's `base` defaults to the inferred base branch, and the commit scope is inferred from the changed files. N6 — gitea-prs was the one gitea skill with no permission-scope caveat on a 404. Added one alongside the existing issue/PR number-space guidance rather than replacing it: a 404 is only evidence of "that number is an issue" once write:repository scope is confirmed. N4 — plugins/kyberforge/bin/README.md pointed at `.mcp.json`, but all six plugin-root .mcp.json files were deleted inc96ca9c(ADR-0018). ${CLAUDE_PLUGIN_ROOT} itself is still live, so the sentence now points at .apm/hooks/hooks.json, which kyberforge's own hook already uses. N7 — not applied. The finding claimed a marketplace field override emits a verbose BuildDiagnostic that `apm pack -v` surfaces, so "silently wins" was wrong. apm 0.28.0 does construct the diagnostic in marketplace/output_mappers.py, but nothing renders it: _render_marketplace_result in commands/pack.py iterates `warnings` only, and BuildReport.diagnostics has no consumer. Confirmed on a fixture — neither `apm pack -v` nor APM_LOG_LEVEL=DEBUG prints the override, and --check-versions reports [matches]. The existing wording in configure.md and marketplace.md is correct, so both are unchanged. Version bumps required by check-skill-version-bump.sh: git-branches 1.0.4 -> 1.0.5, git-commits 0.1.6 -> 0.1.7, gitea-prs 0.1.4 -> 0.1.5. bin/README.md is outside any skill directory and needs no bump. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NwD8Egs5r4ndqeFLmhusX2
31 lines
1.1 KiB
Markdown
31 lines
1.1 KiB
Markdown
---
|
|
source_keys:
|
|
- nvie-gitflow-post
|
|
- atlassian-gitflow-tutorial
|
|
- gitflow-cheatsheet
|
|
---
|
|
|
|
# Branch patterns
|
|
|
|
Which pattern is in play decides the base branch, the branch name prefix, and whether merges are
|
|
allowed to fast-forward. Default to GitHub Flow — simpler, and what CI/CD-oriented repos expect.
|
|
Fall back to Gitflow only when the repo already carries `develop` or `release/*` branches.
|
|
|
|
## GitHub Flow
|
|
|
|
- Base: `main`
|
|
- Feature branches: `feature/<feature-name>` or `fix/<bug-name>`
|
|
- Merge: fast-forward where possible, to keep history linear
|
|
- Delete the branch after merge
|
|
|
|
## Gitflow
|
|
|
|
- Base: `main` (production) plus `develop` (integration)
|
|
- Feature branches: `feature/<feature-name>`, cut from `develop`
|
|
- Release branches: `release/X.Y.Z`, cut from `develop`, merged to both `main` and `develop`
|
|
- Hotfix branches: `hotfix/X.Y.Z`, cut from `main`, merged to both `main` and `develop`
|
|
- Merge: always `--no-ff`, so the branch structure survives in the history
|
|
|
|
The two are not mixable. A `--no-ff` merge into a GitHub Flow repo leaves merge commits nobody
|
|
expects; a fast-forward merge of a Gitflow release branch erases the release boundary.
|