Skip to content

Git workflow (week one)

How Team Rephrased teammates branch, review, and merge in Rephrased-Games/Rephrased-Game. Use this page before your first pull request. The old demo repo is historical/reference only.

Weekly rhythm

  1. Pull latest main from Rephrased-Games/Rephrased-Game before starting new work.
  2. Create a task branch from main using MCP create_branch or the same naming pattern manually.
  3. Work in Unreal, C++, Blueprints, or wiki Markdown on that branch.
  4. Test the affected gameplay, level, or docs path (PIE on PreProRuneShowcase, your personal playground, or your assigned level).
  5. Tell your coding agent (Cursor, Claude Code, Codex, Antigravity, or another MCP-capable IDE) you are done / want to commit (see Self-review workflow). You compile and PIE.
  6. Open a PR into main using the repo PR template: summary, linked ticket, what changed/why, verification evidence, review checklist, rollback notes, and video/screenshot when relevant.
  7. Lead review before merge. MCP create_branch and local hooks enforce the local branch workflow. Branch protection is still pending GitHub Education/private-repo benefits for server-side enforcement.

Branch naming

Pattern: <category>/<area-or-level>-<short-task>

Category Use for
feature/ New gameplay, levels, systems, or docs
fix/ / bugfix/ Defect fixes
docs/ Wiki or repo documentation only
chore/ Tooling, hooks, non-gameplay maintenance
refactor/ Code/data reshaping without behavior change
test/ Tests and validation tooling
experiment/ Spikes that may not merge

Examples:

  • feature/level1-first-rune-puzzle
  • feature/rune-verb-noun-grammar
  • fix/rune-slot-hover-flicker
  • docs/engineer-onboarding
  • chore/install-review-hook

Pull request checklist

Before you open the PR:

  • [ ] Branch is up to date with main (rebase or merge as your lead prefers).
  • [ ] Project compiles (Development Editor | Win64 for engineers).
  • [ ] You PIE-tested the change (or documented why not).
  • [ ] You told your coding agent to finish the review gate (or noted why not).
  • [ ] Wiki edits under Rephrased Wiki/ have ## Change history entries.
  • [ ] A devlog exists if the session was substantial.

A GitHub Action validates the PR body on open/edit/update and fails if required sections are missing or left placeholder-only. Use the repo PR template. Minimum sections: Title, Summary, Linked ticket, What changed / why, Verification evidence, Review checklist, Rollback notes, and Video / screenshot. GitHub supports dragging images and videos into the PR body or a PR comment. Video/screenshot is required for gameplay, UI, level, camera, VFX, animation, or visual bug changes; use N/A for docs/tooling-only changes.

Devlogs

Write a devlog when you finish a feature slice, fix a blocking bug, or change onboarding/docs that teammates rely on.

Change history

  • 2026-08-27 - Gabriel Li - Updated first-day sandbox wording to PreProRuneShowcase and added the personal playground expectation where relevant.

  • 2026-08-27 - Gabriel Li - Added MCP create_branch and local hook guardrails for no-main and branch-name enforcement; GitHub protection remains the server-side follow-up.

  • 2026-08-27 - Gabriel Li - Added PR-body validation so missing or placeholder-only template sections fail CI.

  • 2026-08-27 - Gabriel Li - Standardized the GitHub PR template sections and video/screenshot expectation.

  • 2026-08-26 — Gabriel Li — Clarified org repo, no-direct-main policy, and temporary manual PR discipline until branch protection is available.

  • 2026-08-14 — Gabriel Li — Related link is First day (engineering) only. Review-gate wording lists all team coding-agent harnesses.
  • 2026-08-13 — Gabriel Li — PR checklist uses MCP review gate language; dropped named-skill steps.
  • 2026-05-23 — Gabriel Li — Week-one Git/PR workflow published from onboarding audit follow-up.