.gitconfig

# Tracked git policy for this repository.
#
# Git cannot version `.git/config`, so repository policy that must survive a
# fresh clone lives here and is pulled in with a one-time:
#
#     git config --local include.path ../.gitconfig
#
# (the path is relative to `.git/config`). CONTRIBUTING.md documents this
# next to the `core.hooksPath` step.
#
# WHAT BELONGS HERE: settings that are true for every contributor.
# WHAT DOES NOT: anything naming a specific person, key file, or home
# directory. `user.signingkey` in particular is per-contributor and MUST stay
# in local config — this repository is public.

[gpg]
	format = ssh

[commit]
	gpgsign = true

[tag]
	gpgsign = true

# Release signing policy (enforced by scripts/hooks/pre-push).
#
# This repository is developed with an AI agent that commits under its own
# signing key, so two keys are in play and they are NOT interchangeable:
#
#   * `user.signingkey`             — signs ordinary commits. On a machine
#                                     where the agent works, this is the
#                                     AGENT's key, so agent commits are
#                                     attributable to the agent.
#   * `devflow.releaseSigningKey`   — the human maintainer's key. The ONLY
#                                     key permitted to sign a release tag or
#                                     a push to `main`.
#
# Both signatures carry the same `user.email`, so a tag signed with the wrong
# key LOOKS correct in `git log` and on GitHub. The identity that
# distinguishes them is the key fingerprint, which is why the pre-push hook
# compares fingerprints rather than trusting the signer string.
#
# Set your maintainer key once, locally:
#
#     git config --local devflow.releaseSigningKey ~/.ssh/<your-key>.pub
#
# When unset, the hook does not block — a contributor who never cuts releases
# needs no configuration. When set, it is enforced with no override flag: the
# escape hatch is to sign the tag with the right key.

# git-flow branch model.
#
# `git flow init -d` must NOT be used here: its default production branch is
# `master`, and this repository's is `main`. Initialising with the defaults
# silently configures git-flow against a branch that does not exist, and the
# error only surfaces later, at release or hotfix time.
#
# These names are true for every contributor, so they live in tracked config
# rather than being re-typed per clone. The feature prefix matches both this
# repository's existing branches (`feature/phase-30`) and GSD's
# `git.phase_branch_template` in `.planning/config.json`, so `git flow feature
# start phase-N` and GSD's own branch creation converge on the same name
# instead of producing two branches for one phase.
[gitflow "branch"]
	master = main
	develop = develop

[gitflow "prefix"]
	feature = feature/
	release = release/
	hotfix = hotfix/
	support = support/
	versiontag = v

[alias]
	# Start a clean feature branch in an isolated worktree
	feature-start = "!f() { git worktree add .worktrees/$1 -b feature/$1 develop; }; f"
	# Remove a merged feature worktree
	feature-done = "!f() { git worktree remove .worktrees/$1 && git branch -d feature/$1; }; f"
	# Sync upstream code into current workspace branch
	workspace-sync = "!./scripts/sync-workspace.sh"