托管与拉取请求
创建
不用离开这个应用就能创建拉取请求（PR，在有些平台上叫合并请求）：分支下拉框、由该分支的提交预填好的标题和正文、一个草稿开关，以及——在 GitHub 上——创建时就一并设好的评审者、标签和指派人。
GitHub、GitLab、Bitbucket 和 Azure DevOps 都能用。四家平台上打开着的 PR/MR 都列在侧边栏里。
可以从分支对比、提交图、PR 面板里的 +，或者从一个议题出发创建（后者会自动填上 Closes #N）。
列表里的堆栈
互相叠在一起的 PR 会折叠成一行：堆栈图标、这条链落脚的分支，以及一共几个。展开就能按阅读顺序看到整条链——从最上面一直到基底——每行下面还有个小箭头写着它合并进 哪里，方向直接摆在屏幕上，不用对着四个基底自己推。
决定它们成组的有两件事：如果这些 PR 属于原生堆栈，就用 GitHub 自己的堆栈编号； 否则看 ref 本身——基底是另一个 PR 的 head，就说明它压在那个上面。第二条规则正是它在 GitLab、 Bitbucket 和 Azure DevOps 上同样管用的原因。
每一行都带着它 head 的检查状态——悬停能看到数量——在 GitHub 上还会列出已经关闭或已 合并的层，这些在“只看开着的 PR”的列表里本来是看不到的。位于已关闭那层之上的层会被标 成受阻：它自己的检查也许是绿的，但它指向的分支永远不会落地了。行上的操作按钮悬停才出现， 好把宽度让给标题。
读取检查的代价是每个 PR 一个请求，而且只在刷新列表时发生。
评审——GitHub 与 GitLab
| 对话 | 评论与评审状态 |
| 检查 | CI 检查任务（GitHub）或流水线作业（GitLab），带通过／失败／等待中状态和查看日志的链接 |
| 已看过的文件 | 每个文件一个 ✓ 的清单，带进度 |
| 行内讨论串 | 按 file:line 归组的行评论，以及回复 |
| 动作 | 评论、批准、要求修改，以及合并 / 压缩合并 |
如果有人在评审进行到一半时强制推送，自那以后改了什么会准确告诉你哪些东西动了。
GitLab 的差别，直说了就是：GitLab 没有单一的“提交评审”调用，所以批准用的是它的批准接口，要求修改则会撤掉你的批准并发出你的评论。不提供变基合并——GitLab 会根据项目设置自行决定用合并提交还是快进，所以合并菜单里只有合并和压缩合并两项。行内讨论串会显示文件和行号，但不会显示周围的变更块，因为 GitLab 的 API 不返回它。评审／合并适用于 gitlab.com 上的项目；自托管实例暂不支持。Bitbucket 和 Azure DevOps 的评审仍会在浏览器中打开。
议题、里程碑、发布——GitHub
浏览议题，并打开一个完整的议题标签页：正文、评论、标签、指派人、里程碑、Projects v2 字段、关闭／重新打开，以及为这个议题创建一个分支（可由 AI 起名）。里程碑会显示进度和它下面的议题。发布可以连同变更日志页面一起浏览。
通知——GitHub
你的整个收件箱——评审请求、提及、CI 动态——覆盖每一个仓库，带未读／全部筛选和标记为已读。工具栏上的铃铛带一个未读徽标，还可以选择在有人请求评审或 CI 跑完时弹出桌面通知。
令牌
按配置档保存的令牌，可以对应多个账号或组织，存在你操作系统的钥匙串里。Gitcito 也可以直接借用你的 git credential helper 里已经有的凭据，所以一个你早就认证过的组织往往完全不需要配置。见安全与机密。