A 15-minute game of Git for your team

Three lengths

1. Fifteen minutes, in a meeting

   60-second days. Twelve days at most, fewer minutes than that, since a day closes the moment every pack is in. Keep three minutes for the scoreboard.

2. An hour, at lunch

   5-minute days: time to think and to talk between days, which is where the conversation about --force happens on its own.

3. A week, between standups

   24-hour days, one pack a day, seven days. The game for a team across time zones: the day's packs resolve together when the day closes, in a random order, so nobody's morning sends first.

The runbook

1. One person opens a room at /play, picks the day length, and adds bots for any seats that will stay empty.
2. Paste the room's link. Whoever opens it takes a seat. There are no accounts: a device gets a made-up handle, and anyone who wants their own name on the scoreboard can link a GitHub account.
3. The host starts the game. Every day, everyone writes a pack: three ops and up to four commands.
4. When someone ships v1.0, CI flips every commit face-up and the scoreboard says who won and what decided it. Any day can be replayed afterwards, which is the part to put on the screen.

Three questions for the three minutes after

• Who pushed without pulling? In the game it costs an op and prints ! [rejected]; in your repository it is the branch that always needs a rebase before it merges. My push was rejected is the two-command fix.
• Who forced, and who had a reflog ready? A sin token here; on a shared branch, an afternoon nobody enjoys. Someone force-pushed over my commit is the way back, including the pull that would quietly lose it.
• Who played blame, and what did CI find? Bugs are hidden on cards until the release flips them, so this is the review conversation: what gets looked at before it ships. Who broke main is the honest version of the command's name.

Seven conventions, each with its page

1. Pull before you push, and set pull.rebase once (why).
2. Never force-push a shared branch, and protect main. On a branch of your own, after a rebase, --force-with-lease (why).
3. Undo on main with a revert, never a reset (why).
4. Resolve conflicts by hand where both sides matter; -X ours or -X theirs only when one side is known to be right (why).
5. Branches live days, not weeks. Small commits, pushed often, so every pull is a fast-forward or close to it.
6. Blame the commit, not the person (why).
7. Write the commit message for whoever reads git log a year from now.

The longer versions are on their way: rebase or merge as a team policy, trunk-based development against GitHub Flow and Gitflow, and branch protection.

What's under it

Nothing you would have to explain away. The rules are Git's, and every command prints Git's output, captured from a real Git (what Git said). There are no turns: everyone writes a pack for the day, and the remote resolves the day's packs together when it closes, in a random order, so being first to send wins nothing. No accounts, no ads, open source under the AGPL. A private space for an org, team leaderboards and a workshop mode are on the roadmap; the feedback box at every scoreboard reaches the maintainer.