---
description: Green-master git flow — branch from next, releases and hotfixes per GIT_FLOW.md
alwaysApply: true
---

# Git flow (green master)

Follow [docs/GIT_FLOW.md](docs/GIT_FLOW.md) and [docs/GIT_FLOW.pdf](docs/GIT_FLOW.pdf). Summary:

## Branches

| Branch | Use |
|--------|-----|
| **master** | Always green; **tags** (`vX.Y.Z`); merge only |
| **next** | Integration; all feature work merges here first |
| **feature/***, **fix/*** | Fork **next**; delete after merge |
| **hotfix/*** | Fork **master** for **released** bugs; merge → master → tag → merge master into **next** |

## Agent rules

1. **Do not** commit, push, or merge to **master** or **next** unless the user explicitly asks (release, hotfix, or sync step).
2. **Default work:** `git checkout next && git pull`, then `git checkout -b feature/...` or `fix/...`.
3. **Before merge to next:** run relevant tests (`./gradlew :app:testDebugUnitTest` for app changes; backend tests for PHP).
4. **Release:** only after user confirms — merge `next` → `master`, CI green, **tag on master**, then **merge master → next**.
5. **Hotfix (production):** branch from **master**, not next; after tag, **merge master into next**.
6. **Hotfix (next-only bug):** `fix/*` from **next** → merge to **next** only.
7. **Never** force-push `master`; force-push `next` only when the user explicitly requests history rewrite on integration.
8. When working on a named branch, call **SetActiveBranch** with that branch name.
9. **Fast track on `next`:** if committing directly on `next` (alpha sprint, user asked), **one feature per atomic commit** — message names the feature; no mixed RSSH + graphs + docs in one commit. Revert with `git revert <hash>`. See [GIT_FLOW.md §4.1](docs/GIT_FLOW.md#41-fast-track-on-next-alpha-sprint).

## Quick commands

```bash
# Start feature
git fetch && git checkout next && git pull && git checkout -b feature/my-change

# After hotfix on master
git checkout next && git merge master && git push origin next
```

If `next` is missing locally: create from `master` and `git push -u origin next` (maintainer once).

## Dual remote (private primary)

- **`origin`** (`git://f0xx.org/...`) = canonical; fetch/pull/push day-to-day work here.
- **`github`** = publish mirror; push `master` + tags (and optionally `next`) after release — do not treat GitHub as sole remote unless user says so.
- Topic branches: `git push -u origin feature/...` only unless user asks to publish to GitHub.
