GitHub hygiene, check-in and check-out

If the project is the building, GitHub is the keys. Lose the keys, lose the building.

More importantly, GitHub is what makes multi-agent and multi-human collaboration possible. Without it, every change overwrites someone else's, every what-changed question takes ten minutes, every rollback is a panic.

The five operations you need (no more)

You do not need to be a Git wizard. You need five operations, executed cleanly, every time. Beyond these five, you can stay in dangerous-water territory for a long time without ever drowning.

• Commit
  Save a snapshot with a message. One concept per commit. If you cannot describe the last change in one sentence, your commit was too big.
• Push
  Send your local snapshots to GitHub. Until you push, only your laptop has them.
• Pull
  Pull the latest snapshots from GitHub before you start. The single most common cause of merge pain is starting from stale code.
• Branch
  A parallel line of work that does not affect main yet. Branch when the change is risky, or when more than one person (or agent) is editing.
• Merge
  Bring a branch back into main. Done well, it is a one-click action. Done badly, it is the moment work disappears.

The discipline (the part most people skip)

The five operations are easy. The discipline of using them well is what separates a team that ships from a team that constantly recovers.

• Commit early, commit often
  A commit is free. Take one every time you finish a small thing. Five small commits beat one big one every time.
• Pull before you start
  Five seconds before the work begins. Saves an hour of recovery later.
• Branch when the change is risky
  Anything experimental, anything you might throw away, anything where two people will collide.
• Never force-push to main
  Force-push rewrites history. On a shared branch, it silently overwrites your teammates' work.

Working with your team: checking in and checking out

GitHub is what makes multi-human and multi-agent collaboration possible. The rules are the same whether the second builder is a person or an agent.

• Main is the source of truth
  Nobody edits main directly. Not you, not an agent. Main is what is live, and it only changes by merging a branch that has been tested.
• Check out: pull, then branch
  Start every piece of work by pulling main and creating a branch named for the change. That is checking out: you now have your own line of work and nobody else's edits can collide with yours.
• Check in: push, then pull request
  When the change works on its preview URL, push the branch and open a pull request. A pull request is asking for the check you cannot give yourself. Merge it, and the change is live.
• Two builders, one file
  The one thing Git cannot fix: two people or two agents editing the same file on the same branch at the same time. Give them separate branches, merge in turn, resolve the conflict once. Nobody overwrites anyone.

Claude worktrees: several builds at once

A worktree is a second copy of your repo, on its own branch, in its own folder. Claude Code can open one per session. That means the developer agent can build the dashboard in one worktree while a second session hardens the login in another, and neither sees the other's half-finished files.

The rule that keeps it sane: one worktree, one branch, one plan. When a worktree's build passes QA, merge its branch and remove the worktree. Never two worktrees on the same branch. This is the mechanism multi-delegating (Protocol 11) runs on.

The five operations live in your daily flow. The first merge conflict is behind you, in safety, and you have run two builds at once and merged them in turn. Future merge conflicts feel like a Tuesday, not a crisis.