Managing a product spread across several GitHub repositories

A modern product rarely lives in a single repository. The front end, the API, the mobile app and the infrastructure each have their own pace, their own reviews and often their own teams. The code is clearer for it; project management, on the other hand, gets harder.

The “one repository, one board” trap

The usual reflex is to track each repository separately, with its own issues. Before long, a single change ends up split into three tickets in three different places, and nobody has the big picture anymore.

The problem isn’t technical: the way the code is split doesn’t match the way the work is split. A customer doesn’t ask for “a change to the API”; they ask for a feature.

Start from the product, not the code

The opposite approach is to create one project per product, then attach the repositories that make it up. Tickets describe what you ship; repositories say where the work will happen.

• A ticket can involve several repositories at once.
• The board can be filtered by repository when a team wants to focus on its own part.
• Specs and mockups live at project level, not scattered across each repository.

Three habits that help

Name tickets from the user’s point of view rather than the component’s. Keep a single source of truth for statuses: if a ticket is “In review”, it is in review for everyone. And regularly go through the tickets with no repository: they are often decisions to make rather than code to write.

This is how Grepo is organized by default: one project, several repositories, a single board.