GitHub Account Strategy for Group Development

GitHub account strategy is one of those things that seems simple until your team grows and suddenly you have three personal accounts, two team accounts, and SSH keys everywhere. The decisions you make early about how to organize GitHub access will save you pain later.

OpenClaw supports both single-account and multi-account setups. Here is how to think through the choices.

TL;DR: Single team account is simpler for smaller teams. Multiple accounts work better when personal and professional work need clear separation. Use SSH config with per-project keys and OpenClaw auth profiles to manage access cleanly.

Single GitHub Account for Teams

The simplest model: one GitHub account per team, shared by everyone who works on that team's repos.

This works well for small teams, startups, or anyone where the team is small enough to coordinate access directly. You add collaborators to the organization, they get access to repos, and you manage permissions from one place.

The advantage is simplicity. One set of credentials to manage, one identity in the GitHub UI, one place to handle billing and settings.

The disadvantage is that everything is visible under the team account. Commit history shows the team identity. PRs come from the team account. This is fine for many teams but some organizations prefer individual attribution.

Multiple GitHub Accounts

Personal vs team accounts is the most common reason for multiple GitHub accounts. You might want your personal projects under your personal account and team work under the team account. The two stay completely separate.

This is the model most individual developers end up with. Personal account for side projects, OSS contributions, and experiments. Team account for client work or company repos.

The challenge with multiple accounts is authentication. GitHub identifies you by SSH key or token. One SSH key belongs to one account. If you try to push from a repo owned by account A using an SSH key registered to account B, it will not work.

SSH Key Management Per Project

The solution is per-project or per-account SSH keys and a SSH config file that routes traffic correctly.

Your SSH config at ~/.ssh/config can specify which identity to use for which host and domain.

Host github.com-personal HostName github.com User git IdentityFile ~/.ssh/id_personal IdentitiesOnly yes

Host github.com-team HostName github.com User git IdentityFile ~/.ssh/id_team IdentitiesOnly yes

Then in each project, set the remote to use the right alias.

git remote add origin git@github.com-team:org/repo.git

When you clone or set up a new project, use the right SSH alias. The SSH config routes the connection to the right key, which GitHub uses to identify the right account.

This keeps everything cleanly separated. Personal projects use personal keys. Team projects use team keys. No conflicts.

OpenClaw Auth Profiles

OpenClaw has auth profiles that let you configure which GitHub credentials to use for which context. This is useful when OpenClaw acts on your behalf with gh CLI or git operations.

In TOOLS.md or a dedicated auth config, you can specify which profile to use per project. When OpenClaw runs git operations in project-a, it uses the team profile. When it runs in your personal side project, it uses the personal profile.

This matters because OpenClaw might run git commands in the background, push changes, or create PRs. If it uses the wrong account credentials, the operations fail or get attributed to the wrong identity.

Set up auth profiles explicitly. Tell OpenClaw which credentials belong to which project. The configuration lives in your workspace files, typically in TOOLS.md or a dedicated openclaw config.

Access Control Best Practices

With multiple accounts and collaborators, access control becomes important.

Use GitHub organizations to group repos and manage permissions at the org level. Within an org, use teams to grant access to specific repos. Do not manage individual collaborator access on each repo if you can avoid it, teams are easier to reason about.

Use the principle of least privilege. If someone needs read access to a repo, give them read access. Do not make them admin because it is easier. Access should match the role.

Rotate SSH keys and tokens periodically. If a key is compromised, you want to know about it and be able to revoke it quickly. Use GitHub's key age and last-used data to audit your keys.

Use deploy keys for machine-to-machine access. If a server needs read access to a repo, use a deploy key rather than a personal SSH key. Deploy keys are scoped to one repo and can be revoked individually.

Working with Contractors and Short-Term Contributors

If you work with contractors or short-term contributors, give them access that matches their engagement length. A three-month project should not have two-year access grants. Use GitHub's access expiration feature if your plan supports it.

When the engagement ends, revoke access immediately. This is not about trust, it is about reducing surface area. A former contractor with active access to your repos is a risk, even if they are trustworthy.

For short-term work, consider using forks instead of granting direct access. The contributor works on their fork, opens PRs from the fork, and you merge when ready. No persistent access needed on your side.

Organizing Your Own Setup

If you are setting this up for yourself with a mix of personal and team work, here is a practical starting point.

One personal GitHub account for your own projects and OSS. One SSH key associated with that account. One team account for team work, separate SSH key, separate git remote aliases per team.

Configure your SSH config with clear host aliases. Name them by purpose, not by account name. github.com-personal and github.com-clientname is clearer than github.com-personal and github.com-work.

In your workspace, annotate which project uses which git remote. A small note in each project README or in the daily log helps when you come back to a project after a break.

OpenClaw picks up on this through context. If your workspace files describe the setup, the agent will use the right credentials without you having to re-explain it every session.

Sources: GitHub SSH Docs | GitHub Organizations