SICKO MODE: Splitting Branches

Motivation here is — if we're generating 10x the code changes / releases, we're taking on 10x the business risk if we don't also augment our review/derisking processes accordingly. LLMs can generate 30k line code changes like it's nothing, but just one line of hallucination in there could cause incidents.

To mitigate that, I've been adding a few Claude steps into my own workflow before posting a PR:

1. Simplify code related to my current branch
2. Code review the diff of my current branch
3. Split the branch / PR into smaller incremental units, which can be reviewed and merged in series, with the latter parts being what actually releases changes impacting production

1/2 are important, but I mostly want to share learnings around 3, because Claude really unlocks some wild new workflows here.

Use Case 1: Split a Branch in Half

Take this branch and split it into two new branches that can be released incrementally. Base the second branch off the first.

Why? A large code change (400+ lines) will get skimmed in review, take longer to be reviewed, etc. It's also riskier if it touches anything critical alongside smaller changes.

My initial approach here was "split this branch into a series of branches to release incrementally." That didn't work well. Slicing the branch in half seems to be more consistent, and I find it's more intuitive to measure/define where to "cut" my changes, rather than leave that decision to Claude.

You can say: [prompt above]. In the first branch, include changes in some_file.js, log statements, small refactors, and any changes which can be released without user-facing impact. In the second branch, include everything else which would impact production. (or however else you need it cut)

Use Case 2: Create Draft PRs with Conventional Commits

Create draft pull requests from those two branches, using conventional commit naming (eg "fix:", "feat:", "chore:"). In the pull request description, link to both pull requests in a numbered list.

Why? By splitting out the code changes from a large branch, it separates dependencies from their callers. This means some parts are missing from the second branch in review. In this case, the pull request description + sequence number acts as a manifest linking all the changes together, even after they're merged.

NOTE: You may hit a permissions error if you're using a personal access token needing the read:org permission. If so, set the permission here.

Use Case 3: Link Branches to a Task ID

Provide a task ID ("UNI-XYZ") and sequence number in the branch names (eg: "fix/uni-xyz-1-branch-name", "fix/uni-xyz-2-branch-name") and titles of the pull requests (eg: "fix: [UNI-XYZ - Part 1] Pull request 1", "fix: [UNI-XYZ - Part 2] Pull request 2")

Why? This is what allows us to link the branches together with a JIRA task or tag as we split them up.

NOTE: You can copy the prompt and just override the value with: Instead of task ID "UNI-XYZ", use "MY-COOL-ID".

Use Case 4: Move Changes Between Branches

Move all changes from some_file.js in branch fix/uni-xyz-1-branch-name to branch fix/uni-xyz-2-branch-name.

Why? Splitting up the branches sometimes includes things that should be in one or the other. This lets us cherry-pick changes without having to manually jump between them. This one seems simple, but is very powerful — if you've ever done this kind of surgical branch-splitting you'll know it can get messy.

Pulling It All Together

Take this branch and split it into two new branches that can be released incrementally. Base the second branch off the first. Create draft pull requests from those two branches, using conventional commit naming (eg "fix:", "feat:", "chore:"). In the pull request description, link to both pull requests in a numbered list. Provide a task ID ("UNI-XYZ") and sequence number in the branch names (eg: "fix/uni-xyz-1-branch-name", "fix/uni-xyz-2-branch-name") and titles of the pull requests (eg: "fix: [UNI-XYZ - Part 1] Pull request 1", "fix: [UNI-XYZ - Part 2] Pull request 2"). Instead of task ID "UNI-XYZ", use "MY-COOL-ID".

Then, review what it produces and use "Move [specific changes] in branch [first-branch] to branch [second-branch]" to fine-tune.

I'm getting my team onboarded with this flow and refining it myself, but would love to hear feedback on all this from the wider group. Anyone else doing similar things?