| 1 | --- |
| 2 | title: Workspaces |
| 3 | description: Workspaces, their names and icons, renaming and deleting one, members, owners and the roles that add to a member, member privileges, requiring two-factor authentication, and access tokens that belong to a workspace. |
| 4 | --- |
| 5 | |
| 6 | A workspace owns repositories and is the first part of their address: |
| 7 | `g1t.sh/<workspace>/<repo>`. There is one kind. A workspace for just you and |
| 8 | one for a company are the same thing with a different number of members, so |
| 9 | there is no separate notion of an organization. |
| 10 | |
| 11 | ## Create a workspace |
| 12 | |
| 13 | Your account does not own repositories itself: a workspace does, and |
| 14 | repositories go in it. Every new account gets a workspace of its own, named |
| 15 | for its username and on the free plan, unless its invite brings it into |
| 16 | someone else's workspace; see |
| 17 | [your first workspace](/guides/authentication/#your-first-workspace). |
| 18 | Signed in without a workspace, g1t shows **Create your workspace or ask to |
| 19 | join one** in place of Mission control: the invitations waiting for you, |
| 20 | and the form below. |
| 21 | |
| 22 | To create another: |
| 23 | |
| 24 | 1. Open [g1t.sh/workspaces/new](https://g1t.sh/workspaces/new). |
| 25 | 2. Choose its name in URLs: lowercase letters, digits and single hyphens. |
| 26 | An owner can [change it later](#rename-a-workspace), and old addresses |
| 27 | redirect for 90 days. |
| 28 | 3. Optionally give it a display name. |
| 29 | |
| 30 | From the API, `POST /workspaces` with `slug` and `name`, or the |
| 31 | `workspace` tool's `create` action: |
| 32 | |
| 33 | ```sh |
| 34 | curl -X POST https://api.g1t.sh/workspaces \ |
| 35 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 36 | -H "Content-Type: application/json" \ |
| 37 | -d '{"slug": "acme", "name": "Acme"}' |
| 38 | ``` |
| 39 | |
| 40 | You can belong to up to ten workspaces. `GET /user`, or the `account` tool's `whoami` action, lists the |
| 41 | ones you belong to. |
| 42 | |
| 43 | A new workspace is free, and **each person can own one free workspace**. |
| 44 | While you own a free workspace, the page shows **You already own a free |
| 45 | workspace** in place of the form, with **Start the plan** on it; the API |
| 46 | answers `402` (`payment_required`). Start the plan on it, or delete it, |
| 47 | then create the new one. Several free workspaces from before are kept, but |
| 48 | each needs the plan (or deleting) before you can create another. See |
| 49 | [one free workspace per person](/guides/usage-and-billing/#one-free-workspace-per-person). |
| 50 | |
| 51 | Usernames and workspaces share one set of names, so a name means the same |
| 52 | thing wherever it appears. Your username is reserved for you: only you can |
| 53 | create a workspace with that name, and nobody can register a username that |
| 54 | is already a workspace. The names `g1t` and `g1t-agent` belong to |
| 55 | [g1t's agent](/guides/working-with-g1t/), and nobody can register them. |
| 56 | |
| 57 | ## Display name, slug and icon |
| 58 | |
| 59 | A workspace has two names: |
| 60 | |
| 61 | | | Example | Where it appears | Changes | |
| 62 | | --- | --- | --- | --- | |
| 63 | | **Display name** | `Flagon Industries` | The sidebar, the top of its page, mission control and link previews | Any time, up to 80 characters; spaces and capitals are fine | |
| 64 | | **Slug** | `flagon` | Every address: `g1t.sh/flagon/<repo>`, clone URLs, API paths and `g1t.page` app addresses | By an owner, once a day at most; the old one redirects for 90 days. See [rename a workspace](#rename-a-workspace) | |
| 65 | |
| 66 | Without a display name, the slug is shown. Where an address is shown, the |
| 67 | slug is in monospace beside the name. Owners change the display name and |
| 68 | description (up to 160 characters) on **Settings → General**, or with |
| 69 | [`PATCH /workspaces/{workspace}`](/reference/api/workspaces/update-workspace/) |
| 70 | (MCP: `workspace` `update`), which takes `name` and `description` and |
| 71 | changes only the fields given. It needs the `workspace:admin` scope, and |
| 72 | is recorded in the [audit log](/guides/audit-log/): |
| 73 | |
| 74 | ```sh |
| 75 | curl -X PATCH https://api.g1t.sh/workspaces/flagon \n -H "Authorization: Bearer $G1T_TOKEN" \n -H "Content-Type: application/json" \n -d '{"name": "Flagon Industries", "description": "Rockets, and the software that flies them."}' |
| 76 | ``` |
| 77 | |
| 78 | Neither changes the slug; that is a [rename](#rename-a-workspace). |
| 79 | |
| 80 | A workspace also has an icon. Without |
| 81 | one, g1t draws its first letter in a colour of its own. To upload one, an |
| 82 | owner opens **Settings → General** and picks an image: |
| 83 | |
| 84 | - PNG, JPEG, WebP or GIF, at most 1 MB. Square images look best. |
| 85 | - An image is checked by its contents, not its name. SVG is refused, |
| 86 | because it can carry script. |
| 87 | - **Remove** goes back to the letter. |
| 88 | |
| 89 | The icon then shows wherever the workspace does, and on its link previews |
| 90 | (PNG and JPEG icons only). Each image is served from |
| 91 | `g1tusercontent.com/avatars/<sha256>`, an address named after its contents, so an icon |
| 92 | that changes gets a new address and nothing shows the old one. |
| 93 | |
| 94 | You can upload a picture of yourself the same way, under |
| 95 | [Settings → Profile](https://g1t.sh/settings/profile). |
| 96 | |
| 97 | ## Rename a workspace |
| 98 | |
| 99 | Renaming changes the slug, the first part of every address under the |
| 100 | workspace. The display name is separate; change it on its own under |
| 101 | **Settings → General → Workspace details**. Only owners can rename a |
| 102 | workspace. |
| 103 | |
| 104 | 1. Open the workspace's **Settings → General** and go to **Address**. |
| 105 | 2. Type the new slug. The field shows the new address, `g1t.sh/<new>`, and |
| 106 | whether the name is available. |
| 107 | 3. Choose **Change address**, read what changes, type the new slug to |
| 108 | confirm, and choose **Change address** again. |
| 109 | |
| 110 | You land on the workspace's settings at its new address. Repositories, |
| 111 | issues and the rest move with it within a few seconds. |
| 112 | |
| 113 | ### What changes |
| 114 | |
| 115 | | | Before | After | |
| 116 | | --- | --- | --- | |
| 117 | | Pages | `g1t.sh/old/<repo>` | `g1t.sh/new/<repo>` | |
| 118 | | Git remotes | `https://g1t.sh/old/<repo>.git` | `https://g1t.sh/new/<repo>.git` | |
| 119 | | API paths | `https://api.g1t.sh/repos/old/<repo>` | `https://api.g1t.sh/repos/new/<repo>` | |
| 120 | | MCP tool arguments | `"owner": "old"` | `"owner": "new"` | |
| 121 | | Production apps | `https://<project>-old.g1t.page` | `https://<project>-new.g1t.page` | |
| 122 | | Previews | `https://<project>-git-<branch>-old.g1t.page` | `https://<project>-git-<branch>-new.g1t.page` | |
| 123 | |
| 124 | These stay the same: the display name, description and icon, members and |
| 125 | roles, access tokens, secrets and variables, integrations, webhooks, |
| 126 | issues and pull requests, and billing, plans and credit. |
| 127 | |
| 128 | ### What redirects, and for how long |
| 129 | |
| 130 | For 90 days after a rename, the old name keeps working: |
| 131 | |
| 132 | | | Behaviour | |
| 133 | | --- | --- | |
| 134 | | Web pages | Answer with a permanent redirect (301) to the same page under the new name, query string included. | |
| 135 | | `git clone`, `fetch`, `pull` and `push` | Redirected to the new remote. Git follows it, but prints a warning each time until you update the remote. | |
| 136 | | API and MCP | A call that names the old slug runs under the new one. | |
| 137 | | `g1t.page` apps | Production and preview addresses under the old name redirect to the new ones. | |
| 138 | |
| 139 | Update your remotes now rather than relying on the redirect: |
| 140 | |
| 141 | ```sh |
| 142 | git remote set-url origin https://g1t.sh/<new>/<repo>.git |
| 143 | ``` |
| 144 | |
| 145 | Update anything else that has the old name written into it, too: links in |
| 146 | READMEs and docs, CI configuration, API clients and MCP clients. |
| 147 | |
| 148 | ### Limits |
| 149 | |
| 150 | - A workspace can be renamed once every 24 hours. |
| 151 | - For 90 days the old name is held for the workspace. Nobody else can take |
| 152 | it, and you can rename back to it. |
| 153 | - After 90 days the redirects stop, and anyone can create a workspace or |
| 154 | register a username with the old name. Links and remotes that still use |
| 155 | it then reach whatever has the name, or nothing. |
| 156 | - The new name follows the same rules as a new workspace: lowercase letters, |
| 157 | digits and single hyphens, up to 39 characters, not a reserved word, and |
| 158 | not another workspace's slug or someone else's username. |
| 159 | |
| 160 | ## Data residency |
| 161 | |
| 162 | Data residency says where the git data of the workspace's new repositories |
| 163 | is stored. The section appears in **Settings** once g1t can store |
| 164 | repositories in the EU. Until then it is not shown, and every repository is |
| 165 | stored wherever g1t stores repositories. |
| 166 | |
| 167 | | Setting | What it does | |
| 168 | | --- | --- | |
| 169 | | Anywhere | New repositories are stored wherever g1t stores repositories. The default. | |
| 170 | | EU only | New repositories are stored in the EU. If EU storage cannot take one right now, the repository is not made, and you are told why. It is never stored somewhere else instead. | |
| 171 | |
| 172 | To change it: |
| 173 | |
| 174 | 1. Open the workspace, then **Settings**. Only owners see the page. |
| 175 | 2. Under **Data residency**, choose **Anywhere** or **EU only**. |
| 176 | 3. Select **Save**. |
| 177 | |
| 178 | The setting applies to repositories made after you save it, however they |
| 179 | are made: from the site, with the API, by pushing to a new address, or by |
| 180 | importing. Repositories the workspace already has stay where they are. To |
| 181 | move them, contact support; a move keeps each repository's address, history |
| 182 | and settings, and pushes to it wait a few minutes while it happens. |
| 183 | |
| 184 | Data residency covers the git data: commits, branches, tags and files, |
| 185 | including pull requests' working copies, which are stored with their |
| 186 | repository. Issues, pull requests, comments and settings are not affected. |
| 187 | A repository [transferred](/guides/transferring-repositories/) to another |
| 188 | workspace stays where it is stored. |
| 189 | |
| 190 | Changing the setting is recorded in the |
| 191 | [audit log](/guides/audit-log/) as `workspace.residency_changed`. |
| 192 | |
| 193 | ## Delete a workspace |
| 194 | |
| 195 | Deleting a workspace takes everything in it with it, in one step: its |
| 196 | repositories, projects, apps, members' access and tokens. Only an owner can, |
| 197 | signed in as a person, typing the workspace's slug to confirm. |
| 198 | |
| 199 | It is not gone at once. For **30 days** g1t keeps all of it, so that a |
| 200 | deletion you did not mean, or did not make, can be undone: an owner writes |
| 201 | to support@g1t.sh, and support restores the workspace as it was. After 30 |
| 202 | days it is purged for good. |
| 203 | |
| 204 | 1. Open the workspace's **Settings → General** and go to **Danger zone**. |
| 205 | It lists what will go with the workspace: its repositories, projects, |
| 206 | live apps and members. |
| 207 | 2. Choose **Delete workspace**, read what happens, type the workspace's |
| 208 | slug to confirm, and choose **Delete workspace** again. You are taken |
| 209 | back to your own home. |
| 210 | |
| 211 | The one thing that can stand in the way is billing: see |
| 212 | [what billing needs](#what-billing-needs). Repositories you want to keep in |
| 213 | another workspace, [transfer](/guides/transferring-repositories/) first; |
| 214 | their old addresses keep redirecting after the workspace is gone. |
| 215 | |
| 216 | From the API, call |
| 217 | [`DELETE /workspaces/{workspace}`](/reference/api/workspaces/delete-workspace/) |
| 218 | with the slug in `confirm`; over MCP, the `workspace` tool's `delete` |
| 219 | action. |
| 220 | |
| 221 | Some workspaces can never be deleted, by anyone, such as Flagon's, which |
| 222 | runs g1t. Their Danger zone says so instead of offering the button. |
| 223 | |
| 224 | ### What billing needs |
| 225 | |
| 226 | | | | |
| 227 | | --- | --- | |
| 228 | | Money owed | Charged to the workspace's card at once, with no minimum charge. With no card, add one or pay from **Billing** first. | |
| 229 | | An unpaid invoice | Pay it from **Billing** first. | |
| 230 | | Prepaid credit | It would be lost: spend it, or write to support@g1t.sh about a refund, first. | |
| 231 | | Usage this month still being metered | Storage and git operations are charged when the month closes. You can delete the workspace from the 1st of next month. | |
| 232 | | The g1t plan | Ends at Stripe at once, not at the end of the period. | |
| 233 | | An enterprise account | A workspace billed through one is moved off it by g1t first: write to support@g1t.sh. | |
| 234 | |
| 235 | A comped workspace owes nothing; only its plan is ended. |
| 236 | |
| 237 | ### What happens |
| 238 | |
| 239 | At once, when an owner deletes it: |
| 240 | |
| 241 | | | | |
| 242 | | --- | --- | |
| 243 | | Members | Lose access, and the workspace leaves their list. Their own accounts are not touched: a person with no workspace left can still sign in, and create or join one. | |
| 244 | | Access tokens | The workspace's own tokens stop working. Personal tokens are not affected. | |
| 245 | | Repositories | Deleted with it: git refuses them, and their pages answer 404. Agents and workflow runs stop. Ones deleted on their own earlier stay deleted. | |
| 246 | | Projects and apps | Hidden. Its apps are taken offline and nothing builds. Custom domains are kept for a restore. | |
| 247 | | Its pages | Answer 404, and it drops out of search. | |
| 248 | | Billing | What it owes is charged, and its plan ends, as [billing needs](#what-billing-needs). Nothing more is charged. | |
| 249 | | The audit log | Records the deletion. | |
| 250 | |
| 251 | Within 30 days, support can restore it: its members, tokens, repositories, |
| 252 | projects and apps come back as they were, and its apps go back up as its |
| 253 | limit allows. Its plan does not come back by itself: an owner starts it |
| 254 | again from **Billing**. A repository deleted on its own before the |
| 255 | workspace was stays in **Recently deleted**. |
| 256 | |
| 257 | After 30 days it is purged: |
| 258 | |
| 259 | | | | |
| 260 | | --- | --- | |
| 261 | | Repositories | Purged, their git data with them, including any that were in Recently deleted. | |
| 262 | | Projects, apps and custom domains | Removed. | |
| 263 | | Webhooks, integrations, secrets and variables | The workspace's own are removed. | |
| 264 | | Memory and guardrails | The workspace's own are removed. | |
| 265 | | Statements, invoices and the ledger | Kept, for accounting. | |
| 266 | | The audit log | Kept as [long as its account keeps it](/guides/audit-log/#how-long-it-is-kept), with the purge as its last entry: once the plan ends with the workspace, that is 7 days, unless an enterprise pays for it or longer was arranged. With no owners left, ask support@g1t.sh for an export. | |
| 267 | | Old addresses | Redirects for repositories transferred out keep working. The workspace's own pages answer 404. | |
| 268 | |
| 269 | ### The name afterwards |
| 270 | |
| 271 | A deleted workspace's slug is never given to another workspace or used as |
| 272 | someone else's username. While it can still be restored, the slug is held |
| 273 | for it. Links and git remotes that still use it keep |
| 274 | meaning what they meant: a transferred repository's old address keeps |
| 275 | redirecting to it, and nobody can take the name in the meantime. |
| 276 | |
| 277 | The one exception: when the slug is your own username, you may create a |
| 278 | workspace with that name again once the old one is purged. It starts empty, on standard billing terms, |
| 279 | and a repository made in it at an old address ends that address's redirect. |
| 280 | |
| 281 | ## Members and roles |
| 282 | |
| 283 | <a id="members-and-owners"></a> |
| 284 | |
| 285 | | Role | Can | |
| 286 | | --- | --- | |
| 287 | | Member | Create repositories (as the [member privileges](#member-privileges) allow), see the workspace's usage and billing, and get the workspace's [base permission](/guides/access-and-roles/#the-base-permission) on every repository in it: Read for a new workspace, which an owner can raise to Write to let members push, merge pull requests, plan work and put g1t to work. Admin on the repositories they create. | |
| 288 | | Owner | Everything a member can, and manage members and owners, the base permission, the member privileges, two-factor requirement, the workspace's access tokens, its details, and billing: the plan, card checks, prepayment and limits. Admin on every repository, and the only ones who can transfer and delete them unless the member privileges allow admins; see [access and roles](/guides/access-and-roles/). | |
| 289 | |
| 290 | A workspace can have any number of owners, and always has at least one. |
| 291 | |
| 292 | ### Roles that add to a member |
| 293 | |
| 294 | An owner can give a member one or both of these roles. Each adds to what |
| 295 | the member already has; an owner has both already. |
| 296 | |
| 297 | | Role | Adds | |
| 298 | | --- | --- | |
| 299 | | **Billing manager** | Manages the workspace's billing as an owner does: the plan, budget and spend limit, AI credit and auto-reload, the card, billing details and invoices. Gives nothing on repositories. | |
| 300 | | **Security manager** | Read on every repository, and seeing and managing every security alert and security setting on them: dismissing and reopening alerts, custom patterns, reviewing push protection bypass requests, and the workspace's security settings. | |
| 301 | |
| 302 | Neither passes to an agent working for the person. |
| 303 | |
| 304 | ### Change someone's role |
| 305 | |
| 306 | On **People**, an owner opens the **⋯** menu beside a member: |
| 307 | |
| 308 | 1. **Make owner** or **Make member** changes their role. |
| 309 | 2. **Billing manager** and **Security manager** turn each role on or off. |
| 310 | 3. **Transfer ownership…** hands the workspace to that member: they become |
| 311 | an owner and you a member, in one step. To add an owner without stepping |
| 312 | down, choose **Make owner** instead. |
| 313 | 4. **Remove from {workspace}…** takes them out. Their roles on its |
| 314 | repositories and their place in its teams go too. |
| 315 | |
| 316 | Owners see a shield beside each member: green when two-factor |
| 317 | authentication is on, amber when it is off. |
| 318 | |
| 319 | The last owner cannot be made a member, removed, or leave: make someone |
| 320 | else an owner first, or [delete the workspace](#delete-a-workspace). |
| 321 | |
| 322 | ### Leave a workspace |
| 323 | |
| 324 | Anyone can leave a workspace they belong to: at the bottom of **People**, |
| 325 | choose **Leave {workspace}** and confirm. Your roles on its repositories |
| 326 | and your place in its teams go with you at once. The only owner cannot |
| 327 | leave. |
| 328 | |
| 329 | ### Add people |
| 330 | |
| 331 | Whoever creates a workspace is its owner. Nobody is added to a workspace |
| 332 | without saying yes: an owner invites people, and each person accepts or |
| 333 | declines. |
| 334 | |
| 335 | This is an invitation to join one workspace. It is not the same as an |
| 336 | invite to g1t, which only lets someone make an account: |
| 337 | |
| 338 | | | Invite to a workspace | Invite to g1t | |
| 339 | | --- | --- | --- | |
| 340 | | Where | The workspace's **People** page, **Invite to** *workspace* | [Settings → Invites](https://g1t.sh/settings/invites) | |
| 341 | | What they get | An invitation to join the workspace, to accept or decline | One new account, in no workspace but its own | |
| 342 | | Without an account | The invitation lets them sign up first, while g1t is invite-only | It lets them sign up | |
| 343 | | When | Always | Only while g1t is invite-only | |
| 344 | |
| 345 | To invite someone to g1t without adding them to your workspace, use |
| 346 | [Settings → Invites](/guides/authentication/#making-invites); the People |
| 347 | page links there while g1t is invite-only. |
| 348 | |
| 349 | On the workspace's **People**, `g1t.sh/<workspace>/-/people` (in the |
| 350 | sidebar): |
| 351 | |
| 352 | 1. Under **Invite to** *workspace name*, type a username, a name or an email address. |
| 353 | As you type, people on g1t are offered by username and name, with their |
| 354 | pictures; hover over one for their card. Only usernames, names and |
| 355 | pictures are shown, never anyone's email address. |
| 356 | 2. Choose the **Role** they join with: **Member** or **Owner**. |
| 357 | 3. Select **Invite**. |
| 358 | |
| 359 | - **By username**: they get a |
| 360 | [workspace invitation](/guides/authentication/#workspace-invitations) in |
| 361 | their inbox and by email, and join with that role when they accept at |
| 362 | [g1t.sh/invitations](https://g1t.sh/invitations). If they decline, you |
| 363 | are told in your inbox. It costs nothing. |
| 364 | - **By email address**: g1t emails an invite that only that address can |
| 365 | use. With a g1t account, it is a workspace invitation like the one above |
| 366 | and costs nothing. Without one, the invitation also lets them make the |
| 367 | account first; while g1t is invite-only that uses one of the workspace's |
| 368 | granted invites, or else one of yours (see |
| 369 | [invites](/guides/authentication/#invites)), and once anyone can sign up |
| 370 | it costs nothing. The new account is then invited to the workspace, and |
| 371 | joins when it accepts. The page never says which it was. |
| 372 | |
| 373 | The email names you and the workspace and links to the invite's page. |
| 374 | Someone new signs up right there, with the invited address filled in; once |
| 375 | the address is confirmed (straight away when they opened the page from |
| 376 | that email, which proves the address is theirs, otherwise with the code g1t |
| 377 | emails them), they are asked to accept or decline the invitation. Someone |
| 378 | with an account signs in and accepts on the page. Accepting lands them in |
| 379 | the workspace, with a one-time welcome. See |
| 380 | [using an invite](/guides/authentication/#using-an-invite). |
| 381 | |
| 382 | Pending invitations are listed under the members, with the person or |
| 383 | address, the role, until when it works (30 days), a link to copy and |
| 384 | **Revoke**: one waiting to be used, one whose new account is **confirming |
| 385 | their email**, and one **waiting for them to accept**. Converting an |
| 386 | outside collaborator to a member sends them an invitation the same way. |
| 387 | Through the API, use |
| 388 | [`POST /workspaces/{workspace}/invitations`](/reference/api/invites/invite-member/) |
| 389 | with a `username` or an `email` and a `role` (the `workspace` tool's |
| 390 | `invite_member` action over MCP); the person answers with |
| 391 | [`POST /user/invitations/{id}/accept`](/reference/api/invites/accept-invitation/) |
| 392 | or [`/decline`](/reference/api/invites/decline-invitation/). |
| 393 | |
| 394 | To give someone a role on one repository without making them a member, |
| 395 | add them as an [outside collaborator](/guides/access-and-roles/#outside-collaborators). |
| 396 | |
| 397 | **A free workspace cannot add people.** Until it starts the g1t plan, it |
| 398 | cannot add members, send invites, or invite outside collaborators, and an |
| 399 | invite sent before waits until the plan is on. Its members stay. People |
| 400 | shows **Start the plan to invite people** with the button in place of the |
| 401 | form, and the API and MCP answer `402` (`payment_required`). See |
| 402 | [who a free workspace can add](/guides/usage-and-billing/#who-a-free-workspace-can-add). |
| 403 | |
| 404 | ### Members through the API |
| 405 | |
| 406 | | Route | MCP tool and action | What it does | Who | |
| 407 | | --- | --- | --- | --- | |
| 408 | | `GET /workspaces/{workspace}/members` | `workspace` `list_members` | Its members, owners first: `role` (`owner` or `member`), `org_roles` (`billing_manager`, `security_manager`) and, for owners, `two_factor`. | Members | |
| 409 | | `PATCH /workspaces/{workspace}/members/{username}` | `workspace` `update_member` | Change `role` and `org_roles` (a list that replaces theirs). | Owners | |
| 410 | | `DELETE /workspaces/{workspace}/members/{username}` | `workspace` `remove_member` | Remove someone. Your own username is leaving. | Owners | |
| 411 | | `POST /workspaces/{workspace}/transfer_ownership` | `workspace` `transfer_ownership` | Hand it to `username`: they become an owner, you a member. | Owners | |
| 412 | | `DELETE /user/memberships/{workspace}` | `workspace` `leave` | Leave it. | You | |
| 413 | |
| 414 | Each is for people, signed in or with a personal access token; never an |
| 415 | agent. A change that would leave no owner answers `409`. |
| 416 | |
| 417 | ```sh |
| 418 | curl -X PATCH https://api.g1t.sh/workspaces/acme/members/grace \ |
| 419 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 420 | -d '{"org_roles": ["security_manager"]}' |
| 421 | ``` |
| 422 | |
| 423 | ## Member privileges |
| 424 | |
| 425 | What members can do beyond their role on each repository. Owners set them |
| 426 | in the workspace's **Settings → Member privileges**, |
| 427 | `g1t.sh/<workspace>/-/settings#member-privileges`, and can always do all of |
| 428 | it themselves. |
| 429 | |
| 430 | | Setting | Default | When on | |
| 431 | | --- | --- | --- | |
| 432 | | **Members can create public repositories** (`members_can_create_public_repositories`) | On | Any member can create a public repository. | |
| 433 | | **Members can create private repositories** (`members_can_create_private_repositories`) | On | Any member can create a private repository. | |
| 434 | | **Repository admins can change visibility** (`members_can_change_repo_visibility`) | On | A member with Admin on a repository can make it public or private, if they could create one of that kind. | |
| 435 | | **Repository admins can delete and transfer repositories** (`members_can_delete_repositories`) | Off | A member with Admin on a repository can delete it, or transfer it to a workspace where they can create one. | |
| 436 | | **Repository admins can add outside collaborators** (`members_can_invite_outside_collaborators`) | On | A member with Admin on a repository can give a role on it to someone outside the workspace. | |
| 437 | |
| 438 | When one is off, only owners can do it; the refusal says so. Someone who is |
| 439 | not a member, an outside collaborator with Admin, never gets these. |
| 440 | Forking private repositories is not a setting: g1t has no personal forks |
| 441 | to allow or refuse. |
| 442 | |
| 443 | Through the API, `GET /workspaces/{workspace}` returns each by its name, |
| 444 | and [`PATCH /workspaces/{workspace}`](/reference/api/workspaces/update-workspace/) |
| 445 | sets any of them (`workspace` `update` over MCP). Each change is in the |
| 446 | [audit log](/guides/audit-log/) as `workspace.member_privileges_changed`. |
| 447 | |
| 448 | ## Require two-factor authentication |
| 449 | |
| 450 | An owner can require everyone with access to the workspace, its members |
| 451 | and its outside collaborators, to have |
| 452 | [two-factor authentication](/guides/authentication/#two-factor-authentication) |
| 453 | on. |
| 454 | |
| 455 | 1. Turn it on for your own account first. |
| 456 | 2. Open **Settings**, `g1t.sh/<workspace>/-/settings#two-factor`. Under |
| 457 | **Authentication security**, it says how many members do not have it on, |
| 458 | and who. |
| 459 | 3. Turn on **Require two-factor authentication** and choose **Save**. |
| 460 | |
| 461 | From then on, someone without it keeps their place but cannot use the |
| 462 | workspace: its private repositories, pages and API answer as if they were |
| 463 | not a member, and every page shows them a notice with a link to turn it |
| 464 | on. Turning it on gives everything back at once. Nobody can join or accept |
| 465 | an invitation to the workspace without it. |
| 466 | |
| 467 | Through the API, `two_factor_requirement_enabled` on |
| 468 | `PATCH /workspaces/{workspace}`. Recorded as `workspace.two_factor_required` |
| 469 | and `workspace.two_factor_not_required`. |
| 470 | |
| 471 | ## The workspace's page |
| 472 | |
| 473 | A workspace's own page, `g1t.sh/<workspace>`, has its icon, name, address |
| 474 | and description at the top, then its overview: your |
| 475 | [pinned projects](#pinned-and-recent-projects), then the most active ones, |
| 476 | the pull requests in progress across them, and **All projects**. Members |
| 477 | also see a **Usage** card with this month's spend, and who belongs. |
| 478 | |
| 479 | The workspace's other pages each have a heading of their own and a row in |
| 480 | [the sidebar](#the-sidebar), lit while you are on them. The trail in the |
| 481 | top bar, such as *acme / Projects*, leads back to the workspace's page. |
| 482 | |
| 483 | | Page | Address | Who | | |
| 484 | | --- | --- | --- | --- | |
| 485 | | **Overview** | `g1t.sh/<workspace>` | Everyone | The page above. | |
| 486 | | **Projects** | `/-/projects` | Everyone | Every project you can see. See [the Projects page](#the-projects-page). | |
| 487 | | [**Packages**](/guides/packages/) | `/-/packages` | Everyone | What the workspace publishes. A visitor opens it from **Packages** on the workspace's page. | |
| 488 | | [**Teams**](/guides/teams/) | `/-/teams` | Members | Groups of members given roles on repositories together, mentioned as `@workspace/team` and asked to review together. Each team has its own page at `/-/teams/<team>`. | |
| 489 | | **People** | `/-/people` | Members | Who belongs. Owners add and remove people here. | |
| 490 | | **Insights** | `/-/insights` | Members | Coming soon: how the whole workspace delivers. | |
| 491 | | **Settings** | `/-/settings` | Owners | How the workspace is set up and connected (below). | |
| 492 | |
| 493 | Each person sees the projects they can read: a member whose base permission |
| 494 | is None, an [outside collaborator](/guides/access-and-roles/#outside-collaborators) |
| 495 | or a visitor sees the public ones and those shared with them, without the |
| 496 | workspace's people, deployments or settings. |
| 497 | |
| 498 | Older addresses still work: `/-/members` opens People, and |
| 499 | `g1t.sh/<workspace>?tab=projects` (or `repositories`, `packages`, |
| 500 | `teams`, `people`, `insights` or `settings`) opens that page. |
| 501 | |
| 502 | ### The Projects page |
| 503 | |
| 504 | The Projects page, `g1t.sh/<workspace>/-/projects`, is made for workspaces with hundreds of projects: |
| 505 | |
| 506 | - **Find a project** matches every word you type in a project's name, its |
| 507 | address or its description. Press <kbd>/</kbd> anywhere on the page to |
| 508 | start typing. |
| 509 | - **Filters**: public or private; [what it is](/guides/projects/#what-a-project-is) |
| 510 | (apps, libraries, and tools, docs or other when the workspace has any); the language its |
| 511 | manifests say it is written in; only projects with |
| 512 | [Deployments](/guides/deployments/) on; and archived projects, which are |
| 513 | left out unless you ask for them. Each choice shows how many projects it |
| 514 | holds. |
| 515 | - **Sort** by recently updated (its settings or its last push, whichever is |
| 516 | later), recently pushed, most active, or name. Most active counts each |
| 517 | push, issue or pull request opened or closed, review, comment and |
| 518 | deployment, and what happened a week ago counts half as much. |
| 519 | - **List** or **grid**, 30 projects to a page. |
| 520 | - The arrow keys (or <kbd>j</kbd> and <kbd>k</kbd>) move between projects, |
| 521 | and <kbd>Enter</kbd> opens one. |
| 522 | |
| 523 | Everything you choose is in the address, so a filtered list can be |
| 524 | bookmarked or shared. |
| 525 | |
| 526 | ## The sidebar |
| 527 | |
| 528 | The sidebar is always about one workspace: the one the switcher at its top |
| 529 | names. On a workspace's pages, and on a project in one of your workspaces, |
| 530 | that is the workspace the page belongs to; on a project somewhere you are |
| 531 | not a member, it stays the one you chose last. Choose the workspace's name |
| 532 | to open its page, or the arrows beside it to switch, or for **Workspace |
| 533 | overview** and **All projects**. |
| 534 | [Explore](https://g1t.sh/explore), public projects from all of g1t, is in |
| 535 | the top bar, beside **Docs**. |
| 536 | |
| 537 | It has two parts, a rule apart. Above the rule is what is yours in every |
| 538 | workspace: **Mission control**, your **Inbox** with how many items are |
| 539 | unread, and the repositories **Shared with you** in workspaces you do not |
| 540 | belong to. Below it, under the workspace's name, is the workspace: |
| 541 | |
| 542 | 1. **Overview**, the [workspace's page](#the-workspaces-page). |
| 543 | 2. Its [projects](#pinned-and-recent-projects), ending with **All projects**. |
| 544 | 3. The places work happens across them: **Agents**, **Context**, |
| 545 | **Memory**, **Security** and [**Packages**](/guides/packages/), with |
| 546 | **Insights**, **Boards** and **Roadmap** soon. |
| 547 | 4. **People**, [**Teams**](/guides/teams/), **Usage**, what g1t's runs have |
| 548 | cost (see [usage and billing](/guides/usage-and-billing/)), **Support** |
| 549 | and **Settings**. |
| 550 | |
| 551 | One row is lit wherever you are: **Teams** on a team's pages, **Packages** |
| 552 | on a package's, and **Settings** on every page it opens. An item with an arrow opens a list of its own in the sidebar: |
| 553 | **Settings** slides over to how the workspace is set up and connected, and |
| 554 | the row at the top, **‹ Settings**, slides back: |
| 555 | |
| 556 | | Settings | Who | | |
| 557 | | --- | --- | --- | |
| 558 | | **General** | Owners | The icon, the display name, a one-line description, the address (the slug), [who can create teams](/guides/teams/#who-can-create-teams), and [data residency](#data-residency). | |
| 559 | | **Repositories** | Members | The workspace's repositories. Owners also see **Recently deleted**, where a [deleted repository](/guides/managing-repositories/#restore-a-repository) can be restored, or purged, for 30 days. | |
| 560 | | **Access tokens** | Members | The workspace's own tokens. Owners create and delete them. | |
| 561 | | **Guardrails** | Members | What agents may do and spend across the workspace. Owners change them. | |
| 562 | | [**Secrets and variables**](/guides/secrets-and-variables/) | Members | What runs and deployments are given. Owners change them. | |
| 563 | | **Runners** | Owners | The workspace's self-hosted machines, their groups and registration tokens. | |
| 564 | | [**Integrations**](/guides/integrations/) | Members | Every tool the workspace connects to, by category: what is connected, what is available, and what is coming. Owners connect and remove them. | |
| 565 | | [**Webhooks**](/guides/webhooks/) | Members | Where the workspace's events are sent. Owners add and change them. | |
| 566 | | **Billing and plans** | Members | [The g1t plan](/guides/usage-and-billing/#the-g1t-plan), [limits](/guides/usage-and-billing/#limits) and the statement. Owners start the plan, check a card, prepay and set limits. | |
| 567 | | **Audit log** | Members | [Every action agents, people and tokens took](/guides/audit-log/). | |
| 568 | |
| 569 | **People** is in the main list, for every member to see; owners add and |
| 570 | remove people there, set the |
| 571 | [base permission](/guides/access-and-roles/#the-base-permission), and see |
| 572 | the **Outside collaborators** tab. Each member's row also shows the |
| 573 | [teams](/guides/teams/) they are in that you can see. |
| 574 | |
| 575 | Opening a [project](/guides/projects/) slides the sidebar over to the |
| 576 | project's own list, with **‹ All projects** at the top to go back. Its |
| 577 | **Settings** opens one level further: **General**, **Deployments**, |
| 578 | **Domains**, **Agents**, **Guardrails**, **Repository**, **Access**, |
| 579 | **Branches and merging**, **Secrets and variables** and **Webhooks**, each |
| 580 | for the roles that can use it. A link straight to any of these pages opens |
| 581 | the sidebar already there. |
| 582 | |
| 583 | ### Pinned and recent projects |
| 584 | |
| 585 | However many projects a workspace has, its sidebar lists a few: |
| 586 | |
| 587 | - **Pinned**: the projects you pinned, in your order, up to eight a |
| 588 | workspace. Pin one with **Pin** on its page, or the pin on its row of the |
| 589 | Projects page or its card on the Overview. Drag a pinned project to move |
| 590 | it, or hold <kbd>Alt</kbd> and press the up or down arrow. |
| 591 | - **Recent**: the projects you opened last that you have not pinned, up to |
| 592 | five. |
| 593 | - **All projects**, with how many there are, opens the Projects page. |
| 594 | |
| 595 | Pins and recent projects are yours: nobody else sees them, and each |
| 596 | workspace has its own. ⌘K finds any project in the workspace, pinned or not. |
| 597 | From the API, use |
| 598 | [`GET /user/pinned_projects/{workspace}`](/reference/api/pinned-projects/list-pinned-projects/) |
| 599 | and the other [pinned projects](/reference/api/pinned-projects/list-pinned-projects/) |
| 600 | operations, or the `workspace` tool's `list_pinned_projects`, |
| 601 | `pin_project`, `unpin_project` and `reorder_pinned_projects` actions |
| 602 | over MCP. |
| 603 | |
| 604 | ### On your phone |
| 605 | |
| 606 | On a screen narrower than a tablet, g1t keeps the same places and moves |
| 607 | them within reach of your thumb: |
| 608 | |
| 609 | | | What it does | |
| 610 | | --- | --- | |
| 611 | | **The tabs along the bottom** | **Home**, **Code** (or **Artifacts**, if you don't use Code in this workspace), **Chat**, **Agents** and **Inbox**, each with what is unread. They step aside while the keyboard is up and inside a conversation. | |
| 612 | | **The menu button** (☰), beside the workspace's icon at the top left | Opens the sidebar of the mode you are in from the left: the same lists and links as on a computer. Inside a project, that is the project's own list; on a workspace or settings page, the Workspace or account sidebar. Tap outside it, or open a page, and it closes. | |
| 613 | | **The tab you are already on** | Tap it again to open that mode's sidebar too. | |
| 614 | | **The workspace's icon** at the top left | Everything else, from the bottom: **Artifacts** first, then the workspace's **Overview**, **People**, **Teams**, **Usage and billing**, **Integrations** and **Settings**; switching workspaces; help; and your status, profile, settings and signing out. | |
| 615 | |
| 616 | Inside a [project](/guides/projects/), its pages (**Overview**, **Code**, |
| 617 | **Issues**, **Pull requests**, **Agents**, **Workflows**, **Deployments**, |
| 618 | **Insights** and, for the roles that see them, **Security** and |
| 619 | **Settings**) run in a row under its name that scrolls sideways, with the |
| 620 | page you are on kept in view, so issues and pull requests are one tap |
| 621 | away. Pages with more than one view, such as **Files**, **Commits** and |
| 622 | **Branches**, show those as a second row of tabs. |
| 623 | |
| 624 | Menus stay inside the screen, dialogs rise from the bottom and sit on top |
| 625 | of the keyboard while you type, and nothing scrolls the page sideways: a |
| 626 | wide file, diff or table scrolls within its own box. |
| 627 | |
| 628 | ## Mission control |
| 629 | |
| 630 | Mission control, `g1t.sh` when you are signed in, is your home page. It |
| 631 | shows where you are needed in the workspace you have chosen in the |
| 632 | sidebar, what its agents are doing, and what landed without you. |
| 633 | |
| 634 | Under the greeting, one line sums up the week, such as *Agents landed 37 |
| 635 | of their 39 changes this week without you, and people landed 8 changes of |
| 636 | their own*. An agent's change landed without you when g1t merged it, by |
| 637 | auto-merge or from the [merge queue](/guides/merge-queue/), with no person |
| 638 | pressing merge. People's changes are their merged pull requests and the |
| 639 | commits they pushed straight to the default branch. A push is a person's |
| 640 | by the account that signed in to make it, not by the name on its commits: |
| 641 | pushes by g1t or a workflow job's token, and commits g1t wrote, are not |
| 642 | counted as people's. **Review N that need you** jumps to the |
| 643 | list, and **New issue** opens a new issue in the project you pick. |
| 644 | |
| 645 | | Across the top | What it counts | |
| 646 | | --- | --- | |
| 647 | | **Projects** | The workspace's projects, and how many were added this month. | |
| 648 | | **Agents** | Agent runs going now, and the hours agents worked in the last 7 days. | |
| 649 | | **Changes this week** | Pull requests merged in the last 7 days, and commits people pushed straight to the default branch, with the change from the 7 days before. The change is left out when g1t cannot read far enough back to count it. | |
| 650 | | **Landed without you** | The share of agents' changes that g1t merged with no person pressing merge. People's own changes are not counted in it. | |
| 651 | | **Need you** | What is waiting on you, and how many of those block work. | |
| 652 | |
| 653 | The list has three tabs. Each row opens to say more; the first is open. |
| 654 | |
| 655 | | Tab | What it lists | |
| 656 | | --- | --- | |
| 657 | | **Needs you** | Pull requests g1t stopped seeing through, reviews asked of you, changes ready for you to merge, failed checks, quiet agents, failed production builds, repository invitations and a usage limit that is close or reached. | |
| 658 | | **Waiting on agents** | Pull requests in an agent's hands (making the change, checking, reviewing, revising, catching up or in the merge queue), and runs going now. | |
| 659 | | **Landed today** | Pull requests merged today in your time zone, and whether a person merged them. | |
| 660 | |
| 661 | Each row in **Needs you** carries the reason it needs you: |
| 662 | |
| 663 | | Reason | Means | |
| 664 | | --- | --- | |
| 665 | | `BLOCKING` | Nothing moves until a person acts: a failed production build, a merge g1t could not make, or the usage limit. | |
| 666 | | `ASKED FOR YOU` | A review or an invitation addressed to you by name. | |
| 667 | | `CHECKS FAILING` | A required check still fails after the agent revised. | |
| 668 | | `OUTSIDE GUARDRAILS` | A run reached a cost or time cap set in [Guardrails](/guides/guardrails/). | |
| 669 | | `NEEDS REVIEW` | The repository wants a person's approval, or the review still asks for changes after the agent revised. | |
| 670 | | `STALLED` | An agent stopped, or has reported nothing for 10 minutes. | |
| 671 | | `READY TO MERGE` | Checks passed and it was approved; the repository lands changes only when a person merges them. | |
| 672 | |
| 673 | Opened, a row shows **The ask** (what g1t stopped with, and who the work |
| 674 | was started for), **What the agent already knows** (its checks, the files |
| 675 | and lines it changes, the test files it touches, how often the agent was |
| 676 | sent back, and what its runs cost) and **Why this needs you**. From |
| 677 | there, **Review and respond** opens it, and where it can be done without |
| 678 | leaving the page you can approve the change, merge it or re-run its failed |
| 679 | jobs. **By impact** puts the most urgent first; **Newest** sorts by time. |
| 680 | |
| 681 | On the right, **This week** charts the changes landed each day, split |
| 682 | by who did the work: agents on their own, agents with a person merging, |
| 683 | and people (their pull requests and direct pushes, merges left out), with what |
| 684 | agents and sandboxes cost over the same days. **Activity** lists what |
| 685 | moved across the workspace, agents marked apart from people. The page |
| 686 | refreshes itself while agents are at work. |
| 687 | |
| 688 | ## Workspace access tokens |
| 689 | |
| 690 | A workspace has access tokens of its own, for CI, integrations and agents |
| 691 | that work for a team. There is no shared service account to create, pay |
| 692 | for or lose the password to. |
| 693 | |
| 694 | | | Personal token | Workspace token | |
| 695 | | --- | --- | --- | |
| 696 | | Belongs to | You | The workspace | |
| 697 | | Acts as | You | The workspace: its name is the author of what it does | |
| 698 | | Can reach | All your workspaces, one of them, or none ([where a token reaches](/guides/authentication/#where-a-token-reaches)) | That workspace only: all of its repositories, or the ones chosen | |
| 699 | | Can do | What its [permissions](/guides/authentication/#permissions) allow, never more than you can | What its permissions allow, with Write on the workspace's repositories (Admin with Repositories: admin); it cannot manage people, tokens or workspaces, and holds no account permissions | |
| 700 | | Expires | 7 days to 1 year, or never where the workspaces it reaches allow | 7 days to 1 year, or never | |
| 701 | | When its creator leaves | Stops working | Keeps working | |
| 702 | | Created by | You, in [Settings → Access tokens](https://g1t.sh/settings/tokens) | An owner, under the workspace's **Settings → Access tokens** | |
| 703 | |
| 704 | They are the same kind of token and are sent the same way; see |
| 705 | [access tokens](/guides/authentication/#access-tokens). With git, any |
| 706 | username works; the token is the password. `GET /user` answers with |
| 707 | `"kind": "workspace"` for one, and `"kind": "user"` for a personal token. |
| 708 | |
| 709 | Every member can see a workspace's tokens: the name, who created each, |
| 710 | its permissions and repositories, when it was last used and when it |
| 711 | expires. Only owners can create, change or delete them. An owner selects |
| 712 | **New token** and fills in the same form as a personal token: a name, an |
| 713 | expiration (No expiration shows a warning), its repositories (all, or the |
| 714 | ones chosen) and its permissions, starting on the CI preset. Each token |
| 715 | shows **Write** or **Admin**: give it **Repositories: admin** to let it |
| 716 | manage webhooks, secrets, deploy keys and who has access, and teams as an |
| 717 | owner would. Select a token to change its permissions or repositories, or |
| 718 | to delete it. |
| 719 | |
| 720 | Which of your members' own personal tokens reach the workspace is set under |
| 721 | **Settings → Personal access tokens**; see |
| 722 | [a workspace's rules for tokens](/guides/authentication/#a-workspaces-rules-for-tokens). |
| 723 | |
| 724 | ## Profiles |
| 725 | |
| 726 | Every person has a profile at `g1t.sh/u/<username>`, apart from the |
| 727 | workspaces at `g1t.sh/<workspace>`. Author names on issues and pull |
| 728 | requests link to it. |
| 729 | |
| 730 | **What it shows.** Your picture, name, username, pronouns, bio, location, |
| 731 | website and when you joined; then your work in three tabs: |
| 732 | |
| 733 | - **Overview:** your contribution calendar, then pull requests merged, |
| 734 | open pull requests and issues opened, and your most recent activity. |
| 735 | - **Pull requests** and **Issues:** everything you opened, and what g1t |
| 736 | opened for you, newest first, |
| 737 | with filters beside the list for state (open, closed, merged), type, |
| 738 | repository and sort order. Add `?tab=pulls&state=merged` and the like to |
| 739 | link to a filtered list. |
| 740 | |
| 741 | **The contribution calendar.** The last year as a square a day, a column a |
| 742 | week, shaded more strongly the more you did that day, with the total |
| 743 | above it ("128 contributions in the last year"). A contribution is a |
| 744 | commit you pushed, an issue or pull request you opened (or g1t opened for |
| 745 | you), and a review you gave. Days are counted in UTC. Hover over a square, |
| 746 | or tap it, to see its day, its count and how many were commits ("5 |
| 747 | contributions on Oct 4, 2026, 3 of them commits"). On a narrow screen the |
| 748 | calendar scrolls sideways inside its card, starting at today. |
| 749 | |
| 750 | Commits count like this: |
| 751 | |
| 752 | - **Pushed to the default branch, or to `gh-pages`.** Commits on other |
| 753 | branches count once they reach the default branch, which is usually a |
| 754 | pull request, and the pull request is counted already. |
| 755 | - **Credited to whoever pushed,** on the day of the push, not to the |
| 756 | commits' authors. Pushes with an agent's, a workspace's or a workflow |
| 757 | job's token are not counted on anyone's calendar. |
| 758 | - **The new commits along the branch's own line,** at most 50 a push. A |
| 759 | merge commit counts once. The first push of a branch counts one, so |
| 760 | importing a long history doesn't fill a single day. |
| 761 | - **Only from the time this was added:** pushes before 9 October 2026 are |
| 762 | not counted. |
| 763 | |
| 764 | **Edit it** in [Settings → Profile](https://g1t.sh/settings/profile). Every |
| 765 | field is optional. The bio takes up to 160 characters and is also what a |
| 766 | link to your profile says. The website must be an `https://` address; |
| 767 | `example.com` is saved as `https://example.com`. Your email address is |
| 768 | never shown. |
| 769 | |
| 770 | **Time zone.** Pick the time zone you are in, by city or region (such as |
| 771 | `America/Denver`), and the [card over your name](#the-card-over-a-name) |
| 772 | shows your local time, so people can tell whether it is a good moment to |
| 773 | ask you something. If your browser's time zone differs from the one |
| 774 | saved, the field offers **Use my browser's time zone**. Choose **Not |
| 775 | shown** to clear it. |
| 776 | |
| 777 | **Who sees what.** A profile is public, but the work and workspaces on it |
| 778 | are filtered for whoever is looking: |
| 779 | |
| 780 | | On the profile | Shown to a visitor when | |
| 781 | | --- | --- | |
| 782 | | An issue or pull request, and its title | They can read its repository: it is public, or they are a member of its workspace | |
| 783 | | The counts, and the contribution calendar | Only what they could see is counted | |
| 784 | | A workspace | They are a member of it too, or you made a public project in it, whose page shows that already | |
| 785 | |
| 786 | Someone signed out sees your public work and the workspaces where you made |
| 787 | a public project; nothing else, and their calendar counts only work in |
| 788 | public repositories. The link preview for a profile uses only public work. |
| 789 | |
| 790 | **How it is laid out.** Signed out, a profile, Explore and Search are |
| 791 | shown with g1t's public top bar (search, Explore, signing in) and the page |
| 792 | at full width, with no workspace sidebar. Signed in, the rail stays, but |
| 793 | no mode is lit and no mode's sidebar opens beside these pages: they are |
| 794 | nobody's workspace, and the profile's own left column says whose it is. |
| 795 | |
| 796 | ### The card over a name |
| 797 | |
| 798 | Hold the pointer over a person's name or picture anywhere on g1t, or move |
| 799 | the keyboard focus to their name, and a card opens with their profile at a |
| 800 | glance: |
| 801 | |
| 802 | | On the card | Shown when | |
| 803 | | --- | --- | |
| 804 | | Picture, name, username and pronouns | Always | |
| 805 | | Bio and location | They filled them in | |
| 806 | | Their local time, such as **3:42 PM local time** | They set a [time zone](#profiles) | |
| 807 | | **Member of** | The same workspaces their profile shows you, at most three named | |
| 808 | | **Committed to this repository in the past day**, **week** or **month** | You opened it inside a repository you can read, and their latest commit on its default branch is that recent | |
| 809 | |
| 810 | On a touch screen no card opens: a tap goes to the profile. `@g1t` has a |
| 811 | card of its own, about putting g1t to work. `ghost`, which stands in for |
| 812 | deleted accounts, has no card. |
| 813 | |
| 814 | ### Commits and your account |
| 815 | |
| 816 | A commit shows as yours, with your username, picture, profile link and |
| 817 | card, when its author address is one of your |
| 818 | [confirmed addresses](/guides/authentication/#email-addresses) or your |
| 819 | noreply address. This holds everywhere a commit appears: the Files page, |
| 820 | history, a commit, blame, branches, tags, comparisons and the |
| 821 | Contributors list, which counts every address of yours as one person. |
| 822 | |
| 823 | To have commits made on your own machine show as yours without publishing |
| 824 | your address, commit with your noreply address: |
| 825 | |
| 826 | 1. Open [Settings → Emails](https://g1t.sh/settings/emails) and copy your |
| 827 | noreply address. It looks like |
| 828 | `<8 characters of your account id>+<username>@users.noreply.g1t.sh`. |
| 829 | 2. Set it for every repository, or leave out `--global` for one: |
| 830 | |
| 831 | ```sh |
| 832 | git config --global user.email "6c1d0efg+sam@users.noreply.g1t.sh" |
| 833 | ``` |
| 834 | |
| 835 | 3. Commit and push as usual. Commits you made before keep the address they |
| 836 | were made with; add that address to your account and confirm it to have |
| 837 | them show as yours. |
| 838 | |
| 839 | | A commit's address | Shown as | |
| 840 | | --- | --- | |
| 841 | | One of your confirmed addresses, or your noreply address | You | |
| 842 | | An address added to an account but not confirmed | The name in the commit | |
| 843 | | An address no account has | The name in the commit, with a plain picture, no link and no card | |
| 844 | | A deleted account's noreply address, or any of its confirmed addresses during the 30 days it can be restored | `ghost` | |
| 845 | | g1t's own (`g1t@users.noreply.g1t.sh`) | `g1t` | |
| 846 | |
| 847 | `Co-authored-by` trailers are matched the same way, and their pictures sit |
| 848 | beside the author's. An address itself is never shown on g1t. |