Home / Use cases / Monorepo task tracking
Monorepo task tracking
In a monorepo, the biggest tracking pain is keeping an external tool in step with many branches and teams. grite puts the issues in git, so they branch when you branch and merge when you merge.
The problem
- ▸Issues in an external tracker drift out of sync with fast-moving feature branches.
- ▸Cross-team coordination in a monorepo means many parallel edits, which strain a hosted tracker's conflict handling.
- ▸Reconstructing what work happened on a branch means cross-referencing the tracker against git history by hand.
How grite solves it
- ▸Because issues live in git refs, they follow the same history model as your code — an issue opened on a branch is there when that branch merges.
- ▸CRDT merge lets many teams and agents edit the task graph in parallel with no conflicts, at monorepo scale.
- ▸The append-only WAL is an immutable record, so the work associated with any branch is auditable straight from git.
Issues follow the branch
$ git checkout -b feature/payments $ grite issue create --title "Wire up refunds" --label payments issue 5c22 · created $ git checkout main && git merge feature/payments # issue 5c22 merges in with the branch, no conflict
Questions
+ Do issues really branch with the code?
Yes. grite stores its log in a git ref, so it participates in git's branching and merging. CRDT semantics guarantee the merge is clean and order-independent.
+ Does this scale to a large monorepo?
The WAL is a compact, content-addressed event log and merges are deterministic, so many parallel editors converge to the same state without a central bottleneck.
Try it in your repo
One install, one grite init, and the task graph lives with your code.