Repository navigation
Branches and workflow
How the repository's branches are laid out, how a change reaches main, and why the tests run only when someone asks for them. To run them yourself, see Running the tests.
| Branch | What it holds | Moves when |
|---|---|---|
main |
The trunk: everything built so far, from the seed to the core's first stage | We merge bootstrap into it |
bootstrap |
Where work lands first, each build step's merges, on their way to main
|
Work lands on it |
wip/<topic> |
A throwaway copy of unfinished work, pushed so the test workflow can run on it | Deleted after the run |
flowchart TD
BO["bootstrap"] -->|merge when ready| MA["main"]
BO -.->|push a copy| WI["wip/topic"]
WI -.->|dispatch| CI["Tests workflow"]
There's one remote, origin, which is NexusTomorrow/server. The repository was seeded once from NexusForever's game_rework and is never synced with it, so there's no upstream remote and nothing to pull from one.
The seed came in with its full history, so every original author's commits are still there and still theirs. git log --follow traces a file that came over from NexusForever back through the rename to its first commit; seven very small files, mostly tiny interfaces, changed too much in the rename for git to see it, and show as a delete and an add. Our own work starts where the seed ends.
Repository-wide mechanical commits are listed in .git-blame-ignore-revs: today the line-ending normalization, the formatting pass, the renames that brought the tree to the code standard, and the neutral rename of the wire models. GitHub's blame view skips them on its own; locally, git config blame.ignoreRevsFile .git-blame-ignore-revs does the same.
Nothing is committed to main directly. It moves only when we merge into it, and a ruleset on it refuses force pushes and deletion, with no one able to bypass it.
bootstrap is never rewritten once it's pushed. Its history is public, and rewriting public history breaks every clone of it.
A wip/ branch exists only for a test run. It's pushed, the workflow runs on it, and it's deleted. Nothing is ever merged from one.
Commit messages use an imperative headline, then a blank line. The headline has no full stop and stays within 72 characters; further points go below the blank line as - lines. The code standard says why the blank line matters, and CI checks every commit since main for all three.
The Tests workflow has one trigger: someone with write access dispatches it. Pushes and pull requests don't run it. Once dispatched, it checks the commit messages and scans for em dashes and method words before it builds, so a run fails fast on the cheap checks, then confirms the formatting after the build and runs the tests.
That's deliberate, for a public repository. A workflow that runs on pull requests runs code from anyone's fork on our runners, and dispatching keeps that decision with a person. On top of that:
- the workflow's token can only read the repository;
- every action it uses is GitHub's own and pinned to a full commit, which the repository's settings enforce;
- it runs on GitHub-hosted runners only, never a self-hosted one;
- secret scanning with push protection is on for the whole repository.
Note
A pull request shows no checks until a maintainer runs them. That's the trigger working as intended, not a broken workflow.
Security problems are reported through GitHub's private vulnerability reporting, not as public issues. SECURITY.md in the repository says how.
Releases aren't set up yet. Once they are, a pushed tag will build a GitHub Release: a framework-dependent publish, one database migration bundle per schema, and checksums, versioned by date. A server deploys only tagged releases, which keeps the source it runs public. The server core design has the detail.
| Piece | Path |
|---|---|
| The test workflow | .github/workflows/test.yml |
Commits git blame skips |
.git-blame-ignore-revs |
| How to report a security problem | SECURITY.md |
| How to contribute | CONTRIBUTING.md |