A Branching Strategy

Branching is going to carry a lot of weight here. Given the size of this codebase and what I am about to do to it, I have to move in small steps. I want to try something, watch it fail, and back out cheaply.

The competing pressure is speed. If I have an idea I want to chase it, and I do not want to spend the afternoon in merge conflicts.

I am one person, which is my advantage. I could do pure trunk-based development and commit straight to rob-main and feel fine about it. But let us keep this as real as we can, because most of you are on a team.

So I switch the model to Fable, which is more reliable when I want it to think outside the box, and ask: I want a clear, deterministic branching strategy. Trunk-based seems right since it is just me. But I also want to experiment, zig and zag, and not trample things or end up in conflicts. What safeguards do you suggest? I do not want to code myself into a corner, I want this maintainable, and I want it to tell a cohesive story. Recommendations only. Do not put anything in place yet.

It comes back with trunk-based on rob-main. Short-lived branches. Do not plan on merging upstream.

Then I push on it. Is there anything deterministic I need to consider, since you are non-deterministic? And I stopped myself, because I am non-deterministic too. So I reframed it: if we were a team of humans, what is your guardrail against someone pushing garbage into the trunk?

The answer is do not rely on people, rely on machinery. Branch protection on rob-main. PRs only. Git hooks through Husky.

And here I had a moment. It is just me. That ceremony is theater for one person. But most of you watching are on a dev team, and for you it is not theater at all. On a large codebase with a large team, this is exactly where the ceremony earns its keep, and Claude will set it up for you. Tell it you have 20 or 50 or 100 developers on a codebase this size and ask for structure and rules. With the GitHub CLI installed it will reach out and configure the workflows too. Especially with something like Fable.

I put the question back and it agreed: PR ceremony on a solo fork is overkill. Drop it.

So I take it, log the decision, and ask for one more thing in docs. Branch strategy, branch naming, and guidance on how big a branch should be. Because it is tempting to let Claude do a lot of work at once, and that is exactly what makes it hard to go backwards. I need a strategy for slicing this into small digestible pieces, since ripping out Copilot is a lot of work.

docs/BranchingStrategy.md:

• Trunk-based on rob-main, with the decision recorded.
• Branch naming. rip/ for removals, which means both things and I love that. Plus idea/ and fix/.
• Surgical tags: pre-chat-removal, copilot-gone, pre-big-idea.
• Working size: one removal target per commit. Green between commits. A session ends with a clean trunk. Big enough to mean something.
• A sprint strategy for slicing the Copilot removal. Leaves first, roots last.

I backed into this on purpose. I need a baseline now, and it will evolve once the actual work starts and the plan turns into a stack of small isolated sprints. I cannot write the overall guidance yet because I do not know the overall scope.

I am not vibing it. I am very visual, and once I see an idea it builds in my head and I chase it. Some of you are going to have ideas too.

Either way: small branches. Next, we start ripping Copilot out.