Depends on whether you can keep things separated logically. I have 3 git worktrees open, each working on a different area.
Generally its feature a, feature b and a refactoring branch of some kind.
My workflow is:
1. Add ticket in gitlab describing bug or feature in as much detail as possible along with acceptance criteria like expected unit tests or browser based tests.
2. In a work tree create a branch based on the id of that ticket in gitlab.
3. Start Claude, tell it to use a skill to pull that ticket, research and make a plan.
4. Review the plan, ask questions, refine.
5. Approve plan and let cluade cook.
6. Have Claude run a set of linters/tests/code quality checks and ground until done.
7. Start a new Claude instance, ask it to review changes made. Provide feedback to first Claude instance for changes.
8. Commit and push, creating a draft mr/pr in gitlab.
9. Review the actual code changes myself using gitlab. Comment on things not right.
10. Get Claude to use another skill to pull comments and work to resolve them. Also feed back any CI failures.
11. Manually close comments and push again. Repeat until done and ready for co-worker review.
I can only keep 3 threads like this going at once. Sometimes it’s only 1 or 2, depending on complexity. Smaller is better. Try to stay atomic and avoid feature creep in each mr.
Oh please, TFA has a title of "Flowers after the beating" - its a direct reference to domestic abuse which attempts to equate Microsofts behaviour and that of a domestic abuser.
Username checks out, but you might want to check with your mother about how she feels about this comparison.
TFA brings up abuse not stndef.
An analogy is "a thing which is comparable to something else in significant respects" and stndef is right to point out that microsoft behavior, while abusive, is not comparable to domestic abuse "in significant respects". Not even close.
The TFA title is sensational for effect and in very poor taste.
Generally its feature a, feature b and a refactoring branch of some kind.
My workflow is:
1. Add ticket in gitlab describing bug or feature in as much detail as possible along with acceptance criteria like expected unit tests or browser based tests.
2. In a work tree create a branch based on the id of that ticket in gitlab.
3. Start Claude, tell it to use a skill to pull that ticket, research and make a plan.
4. Review the plan, ask questions, refine.
5. Approve plan and let cluade cook.
6. Have Claude run a set of linters/tests/code quality checks and ground until done.
7. Start a new Claude instance, ask it to review changes made. Provide feedback to first Claude instance for changes.
8. Commit and push, creating a draft mr/pr in gitlab.
9. Review the actual code changes myself using gitlab. Comment on things not right.
10. Get Claude to use another skill to pull comments and work to resolve them. Also feed back any CI failures.
11. Manually close comments and push again. Repeat until done and ready for co-worker review.
I can only keep 3 threads like this going at once. Sometimes it’s only 1 or 2, depending on complexity. Smaller is better. Try to stay atomic and avoid feature creep in each mr.
reply