Branching?

[aehlke]

How does the use of this fit into branching strategies?

I drafted some elaborations on this question but would prefer to leave it open ended as I'm still mulling over workflows with this tool. Thanks for your thoughts!

[jeffutter]

For me, I would say it fits pretty naturally with branching. I generally create a new branch for a larger unit of work, create my tickets there and merge the completed tickets back in along with the code when done.

For big pieces of work that would be too large to PR, I may structure my work like this:

• Start with one commit that adds the initial tickets and plans
• As I complete tickets, generally commit one commit per completed ticket (with the code and any updates to the ticket)
• When everything is complete, split the commits out into a few dependent PRs so the code is easier to review.

So far it has been pretty 'natural'. I'm coming here from beads and I found it's workflow to be rather git/branch hostile. The git hooks it installs keep trying to dump my entire database into the middle of a rebase which taints the progression of code in relation to tickets. I think they have a different strategy that stores all the tickets in their own git branch, but IMO that's even worse as there's no relation between the ticket and code. With ticket having everything in markdown alongside the code feels very organic to me.

I'd love to hear other folks takes though!

[aehlke]

Thanks for sharing! I'm thinking over what you've explained.

One challenge I see is using this collaboratively (even among agents, not just with humans?). If a ticket only moves into in-progress in a feature branch, then collaborators would still see that ticket as open. There's no simple way to get a world view of the work in progress, without a presentation layer handling that (aggregating statuses from all branches, which might work well anyhow).

[jeffutter]

👍 Yeah, I agree. I think in beads that's solved with all the hooks and having a separate branch for the tickets.

Personally I haven't been focusing on having agents 'mob' a set of tickets, but rather using a "Ralph Loop" style approach where I just say 'Take a ticket that isn't blocked and work on it until it's done then exit. I launch that and let it go until all the tickets are done while I make some coffee 😆

I'd love to hear if people have workflows that work with more aggressive pacing though.

[aehlke]

I use Codex which is quite slow, so I aggressively parallelize my work across agents.

[snapwich]

i think the intended use of .tickets is for it to be .gitignore'd and then its persistent across all branches. personally i keep .tickets outside the repo in a parent directory which is why i pushed for this: #15

i do think it's a good idea to keep your tickets version controlled somewhere though to prevent data-loss and preserve ticket history, so i version control them in a separate repo. this also has the advantage of not cluttering up your code version history with ticket updates.

[aehlke]

i think the intended use of .tickets is for it to be .gitignore'd and then its persistent across all branches. personally i keep .tickets outside the repo in a parent directory which is why i pushed for this: #15

i do think it's a good idea to keep your tickets version controlled somewhere though to prevent data-loss and preserve ticket history, so i version control them in a separate repo. this also has the advantage of not cluttering up your code version history with ticket updates.

Good points. That sounds in favor of putting the tickets in its own branch, if the desire is to commit it / use it for collaboration with others (or in its own repo...)

[wedow]

Good conversation to have. The intent here is to be more workflow-agnostic. The beads "feature" of dumping the SQLite content into the JSONL file during rebase/switch operations was the breaking point that made me write ticket. I didn't want to force things on anyone after that experience.

That said, my current workflow never really parallelizes whole sets of tickets. I make a branch or worktree first, then do planning and ticket creation, and then let the agents work away on those. All tickets are closed before the branch is merged back to master.

I've seen a handful of good systems now that chunk up tickets across parallel agent sessions to work through them faster but so far they don't compose well into my existing workflows. It's hard to make tools that don't encode core workflow assumptions.

[aehlke]

Thanks @wedow

I'm building a tool for managing agents (like everyone else...) and am evaluating integrating tickets (or a Swift port of it) as the storage for managing tickets and agents (since I need ticket-like management of the agent sessions too). I aggressively parallelize my work (because Codex is so slow...) and also want to be able to collaborate with others better which is why I'm doing this. I mention this because building a tool on top of tickets will mean prioritizing some specific workflows in UI.

It sounds like the best option for my use case may be to have tickets operate in its own branch.