Skip to content

Joining, and connecting your git account

Redeem an invite code to join your organization, then connect the GitHub or GitLab account your work is pushed with.

Reading time
2 min read

How it works

DevBench has no self-serve organizations. You join an existing one by redeeming an invite code the first time you sign in, which is what makes "everyone here is a colleague" true by construction rather than by convention. An owner generates codes on the Team page; a code can carry the role you join as, an expiry and a use limit.

Signing in itself is handled by WorkOS: a password, a code sent to your email, Google or GitHub, or your company's single sign-on, whichever your organization has switched on. DevBench never sees or stores a password, and resetting one, or adding a second factor, happens on that sign-in screen rather than anywhere in DevBench.

After joining, two things are asked for before you can do much:

  • A git connection. DevBench clones your organization's repositories with your own GitHub or GitLab personal access token, and pushes with it. The token is encrypted at rest and never returned by the API. A GitLab token needs the api, read_repository and write_repository scopes, the last one is what lets a workspace push its branch back.
  • Your commit email. Every commit a workspace's box makes is authored as the person who asked for it, so work done on your behalf appears under your name in git log and on your provider. DevBench stays the committer, the way "GitHub committed on behalf of X" reads.

Steps

Following along? Tick each number off as you go.
  1. Ask an owner for an invite code.

    They generate one on Team → Invite codes and copy it.

  2. Open the sign-up page and paste the code into Invite code.

  3. Fill in a username, your email and a password, then submit.

    You land in the organization the code belongs to, with the role the code carries.

  4. Connect your git account when prompted, pick GitHub or GitLab, paste a personal access token.

    DevBench validates the token against the provider before storing it, so a bad paste fails here rather than at your first clone.

  5. Give the email address you use for git commits on the Getting started screen.

    This is required to continue; it is what your commits are authored as.

Worth knowing

  • A GitLab token missing write_repository clones fine and then fails at the first push, which looks like a broken workspace rather than a token scope.

  • Roles are set by the invite code and changed afterwards by an owner on the Team page; you cannot change your own.

Report a problem