Git: Multi-Forge Production Workflow

Perform git operations, manage branches, handle multi-remote setups, create PRs/MRs, cut releases, and maintain audit-grade change history across GitHub, GitLab, and Forgejo. The goal is clean, signed, traceable history that satisfies both engineering standards and compliance requirements (PCI-DSS 4.0).

Target versions (May 2026):

• git: 2.53.x (current stable). Git 3.0 expected late 2026 (reftable default, SHA-256 default)
• GitHub CLI (gh): 2.91.0
• GitLab CLI (glab): 1.90.x
• Forgejo CLI (fj): 0.5.0 (latest verified May 2026, released 2026-04-16; the project moves fast - verify the current release at codeberg.org/forgejo-contrib/forgejo-cli). Rust-written, official community CLI. Covers PRs (incl. AGit), issues, repos, releases, tags, actions.
• Forgejo: v15.0 line current at May 2026 recheck; verify the stable branch before upgrade advice. Critical RCE (CVE-2025-68937) patched in v13.0.2+.
• prek: 0.3.x (Rust, recommended) or pre-commit: 4.6.0 (Python, largest ecosystem)
• git-filter-repo: 2.47.x
• gitleaks: 8.30.x (secret scanning)
• cosign: 3.x (Sigstore, for tag/release signing context)

This skill covers five domains depending on context:

• Operations - commits, branches, merges, rebases, stashing, bisect, reflog, recovery
• Remotes & forges - multi-remote setups, GitHub/GitLab/Forgejo differences, mirroring
• PR/MR workflow - feature branches, review flow, merge strategies, release cutting
• Security - commit signing, credential management, hooks, secret scanning, history scrubbing
• Compliance - PCI-DSS 4.0 change management, audit trails, branch protection as controls

When to use

• Creating commits (message style, signing, authorship)
• Managing branches (creation, cleanup, protection, naming)
• Working with remotes (push, pull, fetch, multi-remote sync)
• Creating PRs/MRs (title, description, review process, merge strategy)
• Cutting releases (tagging, changelog, GitHub/Forgejo releases)
• Resolving merge conflicts or rebasing
• Recovering from mistakes (reflog, reset, revert, cherry-pick, bisect)
• Configuring git (aliases, hooks, attributes, credentials, signing)
• Scrubbing sensitive data from history (filter-repo)
• Setting up branch protection rules or rulesets
• Multi-forge workflows (mirroring, token management, SSH keys)
• PCI-DSS change management evidence

When NOT to use

• CI/CD pipeline design - use ci-cd; this skill handles git operations within pipelines, not pipeline architecture
• PR/MR code review - use code-review; this skill creates PRs, doesn't review code in them
• Full application security audit - use security-audit; this skill covers secrets in git history and git-specific security, not application-level vulnerability assessment
• Docker image tagging strategy - use docker; this skill handles git tags, not container tags
• Post-session or post-merge documentation sweeps (README, changelog, runbooks) - use update-docs

AI Self-Check

AI tools consistently produce the same git mistakes. Before performing any git operation, verify against this list:

• Read before rewrite. Never Edit/Write files without Reading them first. Never git commit without checking git status + git diff.
• No destructive ops without confirmation. reset --hard, push --force, branch -D, clean -fd, checkout . - all require explicit user approval. Propose safer alternatives first (--force-with-lease, revert, new branch).
• Authorship correct. Check the project's instruction file for author overrides. Many setups have a local git config that's wrong for the remote (e.g., Forgejo identity vs GitHub identity).
• Commit message format. Follow the project's convention (check recent git log). Default: conventional commits (type(scope): description).
• No secrets in commits. Check git diff --cached for API keys, tokens, passwords, .env files, private keys before committing. If found, unstage immediately.
• No AI attribution in commits. Never add Co-Authored-By lines or any mention of AI tools in commits. No exceptions unless the project explicitly requires it.
• Instruction-file policy respected. Follow the repo's policy for AGENTS.md or other instruction files. Never commit local agent state directories like .claude/, and never mention local-only tooling files in commit messages.
• No tool-specific paths in commits. .claude/, .cursor/, .superpowers/, .worktrees/, docs/local/, PLAN.md, SECURITY-AUDIT.md are local artifacts. Verify .gitignore covers AI tooling artifacts BEFORE staging (.claude/, .cursor/, .codex/, PLAN.md)
• Branch target correct. Verify you're on the right branch before committing. Verify the PR/MR targets the right base branch.
• Requester authorized for admin changes. In shared chats, do not commit or push infrastructure, Kubernetes, secrets, firewall, or other admin changes from a participant who is not authorized to approve them. Stop and ask the authorized owner first.
• Remote target correct. Multi-remote setups exist. Check which remote(s) to push to. Some projects push to multiple remotes (e.g., Forgejo + GitHub).
• Signing configured. If the project requires signed commits, verify signing works before committing (git log --show-signature -1).
• No --no-verify. Never skip pre-commit hooks unless the user explicitly asks. Hooks exist for a reason - fix the underlying issue instead.
• No interactive flags. Never use -i (interactive) flags (git rebase -i, git add -i) in automated contexts - they require TTY input.
• Tags pushed separately. git push doesn't push tags by default. Always git push --tags or git push origin <tag> explicitly.
• Feature branch up to date. Before creating a PR/MR, rebase onto the latest base branch to avoid merge conflicts.
• Lock files regenerated after conflict resolution. After resolving conflicts in dependency files (package.json, Cargo.toml, go.mod, pyproject.toml), re-run the package manager to regenerate the lock file. Never manually merge lock files. Then regenerate: npm install, yarn install, go mod tidy, or cargo generate-lockfile.
• Force-push safety. If force-push is needed, always use --force-with-lease (refuses if remote has unfetched commits). Plain --force requires explicit user approval and team coordination.
• Version info dated. When citing tool versions, include a date so readers know when to re-check. Stale version numbers cause silent breakage.
• Forge-CLI subcommands verified. Before scripting fj/gh/glab/tea commands in a runbook, hooks, or CI, confirm the subcommand and flags exist on the target version (<cli> <cmd> --help). These CLIs add, rename, and remove subcommands across minor versions; docs lag behind the binary.
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• Ref safety checked: branch, remote, upstream, and worktree path are verified before history edits
• Recovery path known: reflog, backup branch, or bundle exists before destructive history oper