GitHub Workflow using /branch and /merge Questions

[seldaneg]

Can someone please give me an idea of how I can do my workflow with GitHub using /branch and /merge? I am willing to set up anything eg GitHub actions. My workflow right now is this: I make a Plan document in Plans folder and I use 5-6 instances of Codex to review the plan, iterate on it til its final. Once I'm satisfied, I have another agent implement it. Currently I have been having the agent implement it directly into my main branch, but I don't like this idea and I get that its not safe, so I want to start using /branch and /merge

My specific questions

1. Should I make the Plan on my main branch, commit it, make an Issue referring to it, then use /branch to write the code

2. When I /merge, is this making a PR that I can then review? or is it doing rebasing right into main? Does Merge remove the worktree directory so it's 100% completing that branch of work?

3. If my Coder instance (or my computer) crashes for whatever reason, and I already started a /branch, how can I get Coder agent to "Resume" from that branch? I don't mean resume the exact conversation, I mean continue the work in that branch. Do I have to cd to that directory and run Coder from there? Or do I just run from my root directory and run /branch again? I wasn't sure about this one

[zemaj]

Yeah /branch and /merge are super powerful and have improved my throughput massively.

Here's what I recommend;

1. Keep your checked out main/default branch clean - ie commit or stash anything uncommitted changes. You don't HAVE to do this but it makes the rest of the process simpler.
2. When you start Code just use /branch straight away. I tend to open 4-6 windows during a coding session each in their own branch. You'll see the directory they're in, in the top status bar. They're effectively git worktrees based on the HEAD of the branch you launched them from. Any uncommitted files are copied across as well in case you forget to use /branch before you start work.
3. Do all your work in the branch, plan, edit, test etc... you can always resume at any point just by going into that folder and starting code in it. Or you can ask Code to work in the worktree and give it that path.
4. Once you're done you can use /merge I usually ensure all my changes are committed before I use /merge - this will allow the system to do a quick merge into your original branch. If there's any issues at all then Code will handle it and it's given a series of steps to follow to ensure the merge is clean. At the end the worktree is deleted, but only if it's been cleanly merged into your branch so no files are ever lost.

You can also just ask Code to merge that worktree in your default branch. If you get stuck Code can find the worktree for you, just tell it what you're looking for.

But yeah they're just git worktrees. The new /undo command makes them less important for single tasks (you can now rewind to any previous user message). But they're still pretty vital if you want to have Code running multiple tasks on the same repo.

[seldaneg]

" I usually ensure all my changes are committed before I use" -- can you just confirm this is how you do this? If I have a worktree active and I want to commit those changes, do I run the command below from the root directory? Or do I cd to the worktree and run it from there? Or do I ask Code to do it?

git add -A && git commit -m “ALPHA MILESTONE 510” && git push. <-- this is the command I have been using for saving and committing directly to my main branch

[zemaj]

I just say "please commit" or "please commit all changed files" - usually Code figures it out :)

But otherwise yes that last command looks good. You don't need the git push. You can do git commit -a -m "msg" (this -a adds all files)

Your working dir will be the worktree, so no need to cd.