Repository management linked to the work

Link your GitHub repositories to each project and see branches, commits, pull requests and releases on the work items they deliver.

2 min read

Repositories are where the work becomes code

A repository holds the code, but not the reason for each change. Linking repositories to projects and work items gives every branch and pull request its context: what it delivers, who asked for it and where it is in the release flow.

Good repository practices

  • One documented branching model.
  • Branch names that include the work-item key.
  • A protected main branch: changes only through reviewed pull requests.
  • Small pull requests that describe the change.
  • Releases tagged and linked to what they contain.

What DevGob does with your repositories

  • GitHub repositories linked to each project of the organization.
  • Branches, commits, pull requests, issues and releases linked to work items.
  • Pull request review state and the CI run of its head commit.
  • A tab per branch with its pull requests and runs.
  • Links kept up to date through GitHub webhooks.

What DevGob does not do

DevGob does not host Git repositories: your code stays in GitHub. Azure Repos and GitLab are on the roadmap.

How DevGob helps

DevGob gives each branch and pull request its context: the work item it delivers and the change that takes it to production.

Read it in the documentation

Frequently asked questions

Does my code leave GitHub?

No. DevGob stores references — numbers, titles, states and links — never your source code.

How is GitHub connected?

An administrator of the organization connects GitHub once; then each project chooses its repositories.

Can I link a pull request by hand?

Yes, links can also be added manually from the work item.

DevOps with governance, on one record

DevGob plans the work and governs every change on its way to production: backlog, sprints, committee authorizations, install evidence and an audit trail.