Never dig through three tabs for a branch name again
GitGumbo puts your GitLab and GitHub issues on one kanban board where every card carries its merge requests — copy the branch name, copy the title, jump to the MR, flip it in or out of draft. All one click. And the board keeps itself current — you never hit refresh.
That's the real card. Hover it — copy the branch name, copy the title, flip the MR in or out of draft. Nothing is saved.
Everything you can do without leaving the board
Every one of these is a click on the card. None of them opens a new tab, and none of them makes you go and find the merge request first.
Copy the branch name
The big one. No opening the issue, hunting for the MR reference, opening the MR, and digging out the branch. It is on the card, one click, ready to paste into your terminal.
Copy the issue title
Genuinely awkward to get out of GitLab without opening the issue. Here it is a click — straight into your commit message or your standup notes.
Jump straight to the MR
One click from the issue card to the merge request itself. No going via the issue page to find out where the MR lives.
Draft ↔ ready
Flip a merge request into or out of draft without leaving the board. Both directions, one click, on the card.
Assign on drop
Drag an issue into In Review and GitGumbo can mark its merge request ready, assign the issue, and add your reviewers — automatically, as part of the drag.
Start at your desk, move it on from your phone
Kick off work with your coding agent at your desk, then move the issue to In Review from your phone. Every control is full-size and always visible on touch — no hover, and moving a card is a tap, not a drag.
For GitLab teams
GitGumbo’s board view will feel familiar — issue cards on a kanban board, just like GitLab’s issue boards. The difference is that these cards show merge request data: pipeline status, conflicts, review threads, and idle time — with direct, one-click access to each MR. Less clicking between pages, a vastly improved workflow. And the board refreshes itself in place: when a pipeline finishes or a review lands, the card updates where it sits — on Pro, within seconds, without you touching anything.
For GitHub teams
GitHub’s Projects boards treat every pull request as its own separate card. GitGumbo puts each issue’s PRs on the issue — pipeline status, reviews, conflicts, and idle time right where the work lives, with one-click navigation back to GitHub. That view GitHub doesn’t give you.
Fits the way your team already works
A board you have to re-model your workflow around is a board you stop using by Thursday.
Columns don’t have to be labels
Most boards make you express everything as a label. Here a GitLab board organized by status, by person or by milestone is mirrored as it stands — and you can define your own columns too. So “a column per teammate” or “a column per release” is just a board, not a workaround you maintain by hand.
And the columns write back. Drag a card into someone’s column and the issue is reassigned; drag it into a release and the milestone is set — on GitLab and GitHub both. If your GitLab board already uses assignee or milestone lists, GitGumbo can take them as they are.
Everything on the board, over an API
A read-only HTTP API over your projects, issues, merge requests and labels — plus the derived board itself, on GitLab: columns, the issues bucketed into each, and every issue’s linked merge requests, in a single call. That join is the part no provider API will give you.
Mint a token at /settings/api, send it as a Bearer token. The OpenAPI spec is generated from the same schemas the API serves — so it cannot drift — and you can hand it straight to your codegen or your AI client. Included on Pro at 1,000 requests an hour, and Team at 5,000.
Read the API reference →GitLab’s Status field, as columns
GitLab 18.4 gave work items a native Status — To do, In progress, Done — meant to replace juggling labels to track lifecycle. GitGumbo reads it, shows it on every card, and builds your columns from it: a board whose lists are statuses arrives here as it stands, with nothing to set up. On every GitLab tier, not just Premium.
WIP limits that warn instead of blocking
Give a column a limit and its header keeps the count against it — 7/5, amber at the limit, red past it. It never blocks the drag: GitLab doesn’t either, and a board that refuses your work just gets worked around. The ratio steps aside while a filter is on, because a filtered count would be answering a different question.
Know what needs attention
Pipeline status at a glance
A pass/fail dot on every merge request, right on the card. You know a build broke without opening the MR — let alone the pipeline.
Conflicts, threads, drafts, idle time
Merge conflicts, unresolved review threads, draft state, and how long an MR has been sitting untouched — all on the same card, without a click.
Filter and search
Zero in on high-priority work and bugs, or filter by assignee, milestone, pipeline status, conflicts and draft state — or show only what is overdue. Search by title, with no fiddly syntax to type.
Milestones and deadlines
Cards carry their milestone, and on GitLab their due date — a quiet chip that turns amber inside three days and red once the date has passed. You find out an issue is late by looking at the board, not by someone asking.
Sort by staleness
Sort a column by how long its merge requests have been idle, so the ones rotting quietly float to the top instead of scrolling out of sight.
How it works
- 1
Sign in with GitLab or GitHub
Authenticate with your existing account — no extra passwords to manage.
- 2
Add your projects
Pick the repositories you want to track. GitGumbo pulls in all open merge requests automatically.
- 3
Work from the board
Copy a branch name, grab an issue title, open the merge request, flip it in or out of draft — all from the card, without opening GitLab or GitHub. The pipeline, conflict and review signals are right there to tell you what needs doing next.