|
| 1 | +# Multiple users in GCM |
| 2 | + |
| 3 | +We're sometimes asked, "Does GCM support multiple users?" The answer is a bit complex (though ultimately, it's "yes"). |
| 4 | + |
| 5 | +## Foundations: Git and Git hosts |
| 6 | + |
| 7 | +Git itself doesn't have a strong concept of "user". There's the `user.name` and `user.email` which get embedded into commit headers/trailers, but these are arbitrary strings. GCM doesn't interact with this notion of a user at all. You can put whatever you want into your `user.*` config, and nothing in GCM will change at all. |
| 8 | + |
| 9 | +Git hosting providers (like GitHub or Bitbucket) _do_ have a concept of "user". Typically it's an identity like a username or email address, plus a password or other credential to perform actions as that user. You may have guessed by now that GCM (the Git **Credential** Manager) does work with this notion of a user. |
| 10 | + |
| 11 | +## People, identities, credentials, oh my! |
| 12 | + |
| 13 | +You (a physical person) may have one or more user accounts (identities) with one or more Git hosting providers. Since Git doesn't really understand what a "user" is, it's not particularly natural to work with multiple identities against a single hosting provider. By default, Git naturally assumes one identity per domain. If you have multiple identites on one domain (or a single identity on multiple domains!), this one-to-one assumption doesn't hold. |
| 14 | + |
| 15 | +There are good reasons for having multiple identities on one domain. You might use one GitHub identity for your personal work, another for your open source work, and a third for your employer's work. You can "fool" Git into letting you assign a different credential to different repositories hosted on the same provider. HTTPS URLs include an optional "name" part before an `@` sign in the domain name, and you can use this to force Git to distiguish multiple users. This name doesn't need to be your actual username on the hosting service, though it might help you remember which credential you're using for that repository. |
| 16 | + |
| 17 | +## Setting it up |
| 18 | + |
| 19 | +As an example, let's say you're working on multiple repositories hosted at the same domain name. |
| 20 | + |
| 21 | +| Repo URL | Identity | |
| 22 | +|----------|----------| |
| 23 | +| `https://example.com/open-source/library.git` | `contrib123` | |
| 24 | +| `https://example.com/more-open-source/app.git` | `contrib123` | |
| 25 | +| `https://example.com/big-company/secret-repo.git` | `employee9999` | |
| 26 | + |
| 27 | +When you clone these repos, include the identity and an `@` before the domain name in order to force Git and GCM to use different identities. If you've already cloned the repos, you can update the remote URL to incude the identity. |
| 28 | + |
| 29 | +(Reminder: the name you choose _does not_ have to be related to your identity on the Git hosting service. GCM will not use it directly; this is only a way to have Git request distinct identities when it calls GCM.) |
| 30 | + |
| 31 | +### Example: fresh clones |
| 32 | + |
| 33 | +```shell |
| 34 | +# instead of `git clone https://example.com/open-source/library.git`, run: |
| 35 | +git clone https:// [email protected]/open-source/library.git |
| 36 | + |
| 37 | +# instead of `git clone https://example.com/big-company/secret-repo.git`, run: |
| 38 | +git clone https:// [email protected]/big-company/secret-repo.git |
| 39 | +``` |
| 40 | + |
| 41 | +### Example: existing clones |
| 42 | + |
| 43 | +```shell |
| 44 | +# in the `library` repo, run: |
| 45 | +git remote set-url origin https:// [email protected]/open-source/library.git |
| 46 | + |
| 47 | +# in the `secret-repo` repo, run: |
| 48 | +git remote set-url origin https:// [email protected]/big-company/secret-repo.git |
| 49 | +``` |
| 50 | + |
| 51 | +## One last thing |
| 52 | + |
| 53 | +[Azure DevOps has some additional, optional complexity](azrepos-users-and-tokens.md) which you should also be aware of if you're using it. |
0 commit comments