git-workflow

Git Workflow

Parallel workstreams are powerful until they step on each other. This skill prevents that.

Branching Convention

Every Conductor workspace creates its own branch automatically. Name your workspaces descriptively:

workspace: build-projects-home     → branch: build-projects-home
workspace: build-settings-flow     → branch: build-settings-flow
workspace: build-explore-tab       → branch: build-explore-tab

Branch-per-Iteration Rhythm

Whether you're in Conductor or running a single Claude Code session, the rhythm that works on production builds:

1. Always branch from a freshly-pulled main. Never reuse old branches across iterations:

   git checkout main && git pull origin main && git checkout -b feat/<topic>
   

   Reusing branches accumulates stale state, makes diffs unreviewable, and re-introduces fixes you already merged.

2. Open a PR on the FIRST commit, not at the end. A PR is a conversation, not a deliverable. Pushing the first commit and opening a PR immediately:

   • Surfaces the change to anyone watching the repo
   • Lets CI run early (catches build / lint failures before you've layered more on top)
   • Gives reviewers a stake in the iteration before it's locked in

3. Push eagerly. After every meaningful commit, git push. The branch is more valuable on the remote than on your machine. If your laptop dies mid-iteration, the work isn't lost.

4. One topic per branch. If you find yourself fixing two unrelated things, stop and split into two branches. Reviews stay tight; reverts stay surgical.

5. After every merge, the re-sync ritual. Local main needs to be in sync with remote main before you start the next branch — otherwise tools like Xcode that read from your working directory keep showing the old code:

   git fetch origin && git checkout main && git pull origin main
   

   Make this a reflex. It prevents an entire class of "I fixed it but it's still broken on simulator" confusion.