# gitgo **Repository Path**: cng1985/gitgo ## Basic Information - **Project Name**: gitgo - **Description**: No description available - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-11-03 - **Last Updated**: 2026-11-11 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # GitGo GitGo 是基于 Go + Vue 3 的代码协作平台起步项目。完整目标及每项状态见 [功能清单](docs/功能清单.md)。当前实现基础注册登录、仓库信息、Star 收藏与 Watch 订阅、Git HTTP 代码存储、Issue 讨论、Wiki 和 Pull Request 操作。仓库支持所有者以及接受邀请的只读、可写协作者；**组织与团队权限和完整安全体系尚未实现，仅供本机开发体验，不要放到公网。** ## 运行 需要 Go、Node.js、npm 和 Git（服务端必须能在 PATH 中找到 Git）；SQLite 使用纯 Go 驱动，无需 C 编译器。首次检出或前端代码更改后，先构建前端（`web/dist` 不提交到版本库，Go 编译和测试也需要它存在）： ```bash cd web npm ci npm run build cd .. go run ./cmd/server ``` 访问 `http://127.0.0.1:8080/`。Go 服务会嵌入前端构建产物，并支持直接访问或刷新前端路由。重新构建前端后需重新编译或重启 Go 服务，嵌入的页面才会更新。 前端开发时，可在另一个终端执行 `cd web` 和 `npm run dev`，访问 Vite 显示的地址；前端和 Git 请求由开发代理转发到 `127.0.0.1:8080`；可用 `GITGO_DEV_PROXY_TARGET` 更改目标地址。SQLite 数据默认存于 `data/gitgo.db`。停止服务使用 Ctrl+C。 ## Git 推送和拉取 创建仓库并推送代码后，可在仓库详情页创建、查看和删除非默认分支与轻量标签，按分支或标签浏览目录和文件、预览 README/Markdown 与常见图片、查看语法高亮、搜索仓库内文本、逐行提交记录、提交历史及提交差异。仓库所有者和可写协作者也可在已有分支中创建、编辑、上传或删除文件并生成 Git 提交，提交前会校验分支是否发生变化；“代码”按钮中可查看克隆地址或下载 ZIP，文件详情页也支持下载单个文件。文本和图片预览上限为 1 MiB，代码视图及逐行提交记录最多显示 10,000 行，每篇 Markdown 最多预览 8 张仓库内相对图片；符号链接只显示目标，不会跟随链接。跨文件符号导航和全局代码搜索尚未实现。GitGo 使用 Git 的 HTTP 协议：公开仓库可匿名克隆和拉取，私有仓库仅所有者和已接受邀请的协作者可以读取，推送仅允许所有者和可写协作者。Git 客户端提示认证时可输入 GitGo 用户名和个人访问令牌；为兼容已有客户端，目前仍接受账户密码。SSH 和 Git LFS 尚未支持。 ```bash git clone http://127.0.0.1:8080/git/仓库ID.git cd 仓库目录 git pull git push ``` 在“设置 → 个人访问令牌”中可创建令牌：选择单个仓库或全部可访问仓库、Git 只读、Git 读写或提交状态上报权限及有效期，并再次输入当前密码。完整令牌仅在创建时显示一次，服务端只保存摘要；可查看最近使用时间并随时撤销。令牌不会增加账户已有的仓库权限；Git 令牌仅用于 Git HTTP，提交状态上报令牌仅能调用对应的状态上报接口。被撤销或过期后不能再用于新的 Git 操作；已经开始的操作可能继续完成。建议将令牌作为 Git 密码输入或交由凭据管理器保存，不要放入仓库地址。 已有本地仓库可先执行 `git remote add origin http://127.0.0.1:8080/git/仓库ID.git`，首次推送可使用 `git push -u origin <分支名>`。Git 仓库在首次访问时初始化，现有有主仓库也会自动初始化；首次推送不含 main 时，系统会选择一个已推送分支作为默认分支。默认数据目录为工作目录下的 `data/repositories`，可通过 `GITGO_GIT_ROOT` 设置其他路径；该目录与数据库必须一起备份和恢复。已初始化的仓库存储缺失时不会自动重建，以免掩盖数据丢失。当前仅支持单个 GitGo 进程使用同一个存储目录。 如果在旧版本中首次推送了非 main 分支，克隆时提示远端 HEAD 不存在，请先确认实际分支名，再由服务器管理员执行 `git --git-dir="<仓库存储目录>/<仓库ID>.git" symbolic-ref HEAD refs/heads/<分支名>` 修正默认分支。 单次 Git HTTP 请求体上限为 1 GiB；分块上传会暂存到系统临时目录，请保证该目录有足够空间。Git 认证在一分钟内失败 20 次后，同一客户端地址会暂时受限；成功的 Git 请求不会消耗失败次数。 服务端需安装 Git 2.38 或更新版本，并确保 `git` 和 `git-http-backend` 可用。HTTP Basic 认证会传输账号密码或令牌，明文 HTTP 仅适合本机；跨机器访问需使用 HTTPS，当前项目仍不具备公网部署所需的完整安全能力。修改 Linux 部署的数据目录时，请确保运行服务的用户对目录有读写权限。 ## 导入远程仓库 在“代码仓库 → 导入 Git 仓库”中输入 HTTP(S) Git 地址、仓库名称和可见性（默认私有）；地址不能包含账号密码。需要认证时填写用户名及密码或访问令牌。提交后仓库立即创建，代码在后台导入，仓库页面会自动更新状态；如导入失败，可在仓库页面检查地址和网络、补充认证信息后重试。服务重启时未完成的下载会标记为待重试，已完成安装的导入会自动恢复。导入复制远程已有分支、标签和默认分支，不包含 Issue、Wiki 或 Git LFS 内容；不支持 SSH 地址或需要重定向的地址。 导入后，仓库所有者可在代码页选择已有分支并点击“拉取”或“推送”。拉取只更新所选同名分支，且只允许快进；有分叉时需先处理差异。推送不会强制覆盖远程分支，远程也可能拒绝写入。受保护分支的直接修改规则同样适用于拉取。其他协作者无法使用已保存的远程凭据；认证失效时所有者可在代码页修改，成功同步后保存。新建远程分支和标签不会通过单分支同步自动导入。 远程用户名和密码使用 AES-GCM 加密存入数据库，密钥保存在 Git 存储目录的 `.gitgo-remote-key` 文件中，需与数据库和仓库存储一起备份并限制服务账户以外的访问。丢失密钥后需要重新输入远程认证信息。应优先使用权限最小的访问令牌；跨机器连接使用 HTTPS，HTTP 会明文传输凭据。导入功能会从服务器访问用户提供的地址，应仅允许可信用户使用，且服务运行环境必须能够访问目标 Git 服务。 ## 分支保护 仓库所有者可在“分支 → 保护设置”中为具体分支设置必须通过 Pull Request、禁止强制推送和禁止删除。规则对所有者和可写成员都生效，适用于 GitGo 的 Git HTTP 推送及网页文件、分支、Fork 同步和来源分支更新；启用必须通过 Pull Request 时，也会阻止直接删除或重新创建该分支。通过 Pull Request 合并仍受仓库审查和必需检查约束。规则按大小写精确匹配，删除分支后规则保留；最多 200 条，不支持通配符、管理员绕过或完整规则集。 Git HTTP 推送通过接收前检查保护规则；普通已有接收钩子及 `core.hooksPath` 设置会继续执行。为了避免自定义 `proc-receive` 修改其他引用绕过规则，存在有效分支保护时 GitGo 不执行 `proc-receive`，对应推送会被拒绝。服务器端本地直接修改仓库存储和受信任的服务器钩子不由 GitGo 约束；受保护推送需要系统提供 Git 支持的 shell。 ## Wiki 与 Pull Request 仓库详情页提供 Wiki 和 Pull requests 入口。Wiki 支持创建 Markdown 页面、修改和查看历史版本；保存时会检查版本，避免覆盖他人的更新。Wiki 数据及历史保存在数据库中，需要随数据库一起备份；目前不提供独立的 Git Wiki 仓库或 Wiki 克隆。 Pull Request 支持同一仓库内选择来源和目标分支、指定可写成员审查、逐文件查看差异、对新旧代码的单行或同一差异段内的连续多行（包括原代码到新代码的跨侧范围）添加评论并回复或解决讨论、提交批准或要求修改的审查，以及关闭、重新打开、合并提交、squash、rebase 和快进合并。合并前会确认查看过的分支提交没有变化；有冲突时需要先在本地解决冲突并更新来源分支。公开仓库的已登录用户可评论和审查，Wiki 默认限所有者和可写协作者编辑，公开仓库可由所有者开放给登录用户；创建及合并 Pull Request 限所有者和可写协作者；审查记录关联具体提交；所有者可设置要求 1 至 6 名其他可写成员批准当前提交，并要求代码行讨论全部解决。每个文件的差异最多显示 256 KiB 和 10,000 行，文件列表最多 500 个。代码行评论支持鼠标拖选、Shift 选择以及触屏两步选择，并保存关联提交快照；分支变化或删除后可查看原始差异。Pull Request 作者和可写成员可解决或重新打开讨论，删除讨论首条评论会保留后续回复。 仓库所有者可设置 Pull Request 必需的提交检查，仓库可写成员或持有专用状态上报令牌的自动化系统可以报告仓库可达提交或 Pull Request 当前来源提交的 `pending`、`success`、`failure` 或 `error`。Pull Request 页面展示每项最新结果，提交详情可查看最新状态和最近上报记录；所有必需检查成功才允许通过 GitGo 合并；来源提交更新后需重新上报。检查名称不区分大小写，同名结果以最新上报为准。此条件本身不限制直接 Git 推送；可为相应分支启用“更改必须通过 Pull Request”。内置 Actions 工作流尚未实现。 例如，自动化系统可在构建完成后使用状态上报令牌调用（仓库 ID 和提交哈希替换为实际值）： ```bash curl -X POST http://127.0.0.1:8080/api/repositories/statuses/create \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $GITGO_STATUS_TOKEN" \ -d '{"repositoryId":1,"commitOid":"完整提交哈希","context":"ci/build","state":"success"}' ``` 对于公开 Fork 的来源提交，可传入 `pullId` 和 `expectedHead` 代替 `commitOid`；详见[接口规范](docs/接口规范.md)。 Pull Request 可创建为草稿或在打开时切换草稿状态；草稿不能合并，标记为可审查后可继续合并。所有者和可写协作者可管理草稿状态。 公开 Fork 的 Pull Request 作者可选择允许目标仓库的可写成员更新来源分支，创建时默认关闭，也可在请求详情中启用或撤销并查看记录。授权仅在请求开启、两个仓库公开且作者仍有来源仓库写权限时生效；允许 Git 推送和网页更新该来源分支，但不包含创建或删除分支、标签或其他分支。同一来源分支上的其他开放请求可能分别授予权限，全部有效授权撤销后才会失效。受限推送不支持压缩请求体或签名推送。 目前支持公开 Fork 的跨仓库 Pull Request；私有 Fork 请求和内置自动工作流尚未支持，团队权限、Actions 和完整 Projects 等其他 GitHub 功能也尚未实现，完整状态见功能清单。默认分支和关联打开状态 Pull Request 的分支不能在页面中删除；网页新建标签为轻量标签，已有附注标签可浏览和删除。网页文本编辑仅支持不超过 50,000 字节的 UTF-8 文本；网页上传支持多选或拖入，每次最多 100 个文件、单个不超过 1 MiB、总计不超过 8 MiB，支持二进制文件和明确选择覆盖；所有文件作为一次提交，任何文件失败都不会更新分支；单次文件或 ZIP 下载上限为 50 MiB。空仓库需先通过 Git 推送创建分支。首次升级前请备份数据库。 Pull Request 标题和描述支持作者、仓库所有者及可写协作者编辑；讨论支持 Markdown，评论作者、所有者和可写协作者可以编辑或删除评论。 Wiki 页面支持删除和从回收站恢复，也可将页面恢复到历史版本；操作会保留版本记录，回收站仅当前 Wiki 编辑者可查看。 仓库代码搜索使用当前分支或标签进行文本匹配，可选择区分大小写；最多展示 100 条结果和每行前 1,000 个字符，二进制文件不参与搜索。 ## Issue 标签 仓库所有者和可写协作者可在标签页面创建、编辑和删除标签，并在 Issue 或 Pull Request 详情中分配标签；访问者可点击标签筛选该仓库的对应内容。每个 Issue 或 Pull Request 最多分配 20 个标签，标签列表最多显示 500 个。多标签筛选尚未实现。 ## 负责人 仓库所有者和可写协作者可为 Issue 或 Pull Request 指派最多 10 名负责人，候选人包括所有者及已接受邀请的协作者。新指派会产生站内通知并订阅讨论；显式取消订阅的用户不会被重新订阅。移除协作者时会解除其负责人关联。点击负责人可筛选相关内容，Issue 和 Pull Request 列表也提供“分配给我”入口。 ## 里程碑 仓库所有者和可写协作者可创建、编辑、关闭或删除里程碑，为 Issue 和 Pull Request 设置里程碑，并按目标筛选；进度统计包含已关闭 Issue 和已关闭或合并的 Pull Request。删除里程碑会解除关联，保留 Issue 和 Pull Request。当前列表最多显示 500 个，尚未支持排序和跨仓库规划。 所有者和可写协作者可向其他可写成员请求审查；请求会发送站内提醒，审查提交后自动清除。Pull Request 列表可筛选“需要我审查”，转为草稿会清除待审请求。 Pull Request 合并条件仅约束 GitGo 的网页和 API 合并；可通过分支保护要求更改必须经过 Pull Request。启用批准条件后，可设置所需批准人数（1 至 6 人）；当前仍有写权限的非作者成员或所有者的最新审查才计入；新提交会使此前批准失效，当前提交上的有效修改请求会阻止合并。 ## 仓库协作者 仓库所有者可按用户名邀请已注册用户，邀请在通知页接受后生效。只读协作者可访问私有仓库、克隆代码和参与讨论；可写协作者还可推送代码、管理分支、Wiki、Issue 和 Pull Request。只有所有者可修改仓库设置、邀请、调整角色或移除协作者。邀请目前不发邮件、没有过期机制；组织、团队和更细粒度角色尚未实现。 ## Watch 与站内通知 登录后可在仓库页订阅或取消订阅。订阅者会收到其他用户创建、关闭、重新打开或评论 Issue / Pull Request，审查或合并 Pull Request，以及更新 Wiki 的站内通知；顶部铃铛可查看未读并标记已读。通知按当前仓库权限过滤，仓库私有期间不会向无权访问的历史订阅者产生通知。创建或参与 Issue / Pull Request 后会自动订阅该讨论；可在详情页单独订阅或取消订阅，取消订阅会屏蔽该讨论的仓库 Watch 通知。自动订阅从启用功能后的新参与开始，不会追溯既有讨论。代码推送通知、邮件和移动推送尚未实现。 ## 数据库配置 `configs/application.yaml` 默认选择 `database-sqlite.yaml`。MySQL、PostgreSQL 和 SQL Server 分别有对应的 `configs/database-*.yaml`；可以修改 `database.config_file` 或设置 `GITGO_DB_CONFIG` 选择。配置默认使用拆分字段，密码可通过 `GITGO_DB_PASSWORD` 注入；完整 DSN 可通过 `GITGO_DB_DSN` 覆盖。详细步骤和验证状态见 [数据库配置与验证](docs/数据库配置.md)。目前 SQLite 已实际验证；其他数据库仍需连接专用测试实例完成验证。 ## 用户注册与登录 可在页面右上角注册、登录和退出，详细说明及与参考旧表的关系见 [用户注册与登录](docs/用户注册登录.md)。启用 HTTPS 时需配置安全 Cookie。仓库与 Issue 的基础访问规则见 [基础功能](docs/基础功能.md)。 ## 结构 - `internal/modules/`：按业务拆分的仓库与 Issue 模块。 - `internal/platform/`：配置、数据库及响应类型。 - `internal/app/`：Fx 装配与生命周期。 - `web/embed.go`、`static.go`、`module.go`：嵌入并注册前端构建产物，区分 API、静态资源与页面路由。 - `web/src/views`、`layouts`、`router`、`stores`、`api`：页面、布局、路由、偏好及接口。主题和导航方式保存在浏览器本地。 目前使用 GORM AutoMigrate 建表，尚未提供生产级版本迁移或完整生产部署流程。 ## 构建发布包 在 Windows 的 CMD 或 PowerShell 中，从任意目录运行： ```powershell E:\codes\ai\gitgo\scripts\build-platforms.cmd -Version 0.1.0 # 或使用 PowerShell： pwsh -NoProfile -File E:\codes\ai\gitgo\scripts\build-platforms.ps1 -Version 0.1.0 ``` 默认构建 `windows/amd64`、`linux/amd64`、`linux/arm64`。PowerShell 入口可用 `-Targets 'linux/amd64'` 选择目标，用 `-OutputDir` 指定输出目录；PowerShell 7 也可在 Linux CI 中执行 `.ps1`（需安装 Node.js、npm、Go 和 pwsh）。脚本在独立临时目录使用 `npm ci` 安装锁定的前端依赖，构建一次并嵌入每个平台的 Go 程序。它会更新工作区的 `web/dist`，但不会删除正在使用的 `web/node_modules`；不要同时运行多个构建脚本。 输出位于 `release/gitgo-<版本>-<时间>-<标识>/`，每个平台有目录和对应 ZIP，包含程序、示例配置、构建信息和程序 SHA-256 校验值；Linux 包还包含以下启动和安装脚本。包含不带数据库密码和 DSN 的配置模板，不复制当前运行配置、数据库或凭据。每次构建采用新目录，失败时保留不完整输出供检查。可执行文件支持 `--version`。 ## Linux 启动与 systemd 安装 将对应架构的 Linux ZIP 解压到目标机器。压缩包不保证保留可执行权限，以下命令在解压后的目录执行： ```bash sha256sum -c SHA256SUMS chmod +x gitgo bash scripts/start-linux.sh ``` 前台启动使用包内的 `configs/application.yaml`，默认数据为包内 `data/gitgo.db`，Ctrl+C 停止。需要 systemd 管理时，执行： ```bash sudo bash scripts/install-linux.sh sudo systemctl status gitgo sudo journalctl -u gitgo -f ``` 安装脚本需要 systemd、curl、sha256sum 和 root 权限；会检查系统架构、校验文件和程序，创建专用 `gitgo` 用户，将程序放在 `/opt/gitgo/releases/`，配置保存在 `/opt/gitgo/configs/`，数据保存在 `/var/lib/gitgo/`。更新前停止服务，保留原有配置、数据、旧程序与旧 unit 备份；它不会覆盖已存在的主配置或数据库配置。更新后通过 POST 请求 `/api/health`（JSON 请求体 `{}`）验证 HTTP 服务，**该接口目前只表示进程可响应，不等于数据库完整就绪检查**。如果修改监听地址，安装时可用 `sudo env GITGO_HEALTH_URL=http://127.0.0.1:端口/api/health bash scripts/install-linux.sh` 指定检查地址。 安装失败时检查 `systemctl status gitgo` 与日志。需要回退时先停止服务，将 `/opt/gitgo/gitgo` 链接恢复为安装输出中记录的旧程序路径，并按需恢复 `/etc/systemd/system/gitgo.service.previous-*` 后执行 `systemctl daemon-reload` 和 `systemctl restart gitgo`。回退前必须确认数据库迁移与旧程序兼容；程序文件回退不恢复数据库。当前程序尚不支持生产 profile 和完整授权，这些脚本仅用于部署与本地体验，不应将服务直接暴露到公网。 仓库 Releases 支持选择已有的 Git 标签，保存草稿、发布正式版或预发布，并以 Markdown 编写说明。草稿仅仓库所有者和可写协作者可见；正式发布会通知订阅仓库的用户。保存时绑定标签对应的提交，若标签随后被删除或移动，页面会提示并停止提供该版本的源码下载，编辑保存可重新确认当前标签。删除发布不会删除 Git 标签，正式发布不能重新转回草稿。版本附件支持上传、下载和删除，单个文件上限为 5 MiB、每个版本最多 20 个；附件内容保存在数据库中，备份数据库时会一并备份。附件遵循仓库权限及草稿可见性，删除版本会同时删除附件。可选择对比标签，根据两标签间最多 100 条提交生成发布说明并追加到编辑内容；不选择对比标签时从最初提交开始。生成结果同时列出范围内已合并的 Pull Request、贡献者和提交摘要，Pull Request 按其标签名称排序后的第一个标签分组；未标记的请求归入“其他更改”。当前最多检查 100 条提交并列出 100 个 Pull Request。所选标签的 Git 树中若包含 `.github/release.yml`（优先）或 `.github/release.yaml`，生成时读取其中 `changelog.exclude.labels`、`changelog.exclude.authors`、`changelog.categories` 及分类内的 `exclude`；分类按文件顺序匹配，`*` 匹配其余请求。配置生效时只生成符合规则的 Pull Request 和贡献者，不再附加原始提交摘要，以免泄露被排除的内容。文件必须是普通 UTF-8 YAML，最大 64 KiB，配置错误时生成会返回错误。 发布说明配置示例（提交到所选发布标签的 `.github/release.yml`）： ```yaml changelog: exclude: labels: [ignore-for-release] authors: [automation-bot] categories: - title: 新功能 labels: [enhancement] - title: 修复 labels: [bug] - title: 其他变更 labels: ["*"] ``` Issue 列表可先选择仓库，再使用“筛选标签”选择多个标签；仓库 Pull requests 列表也提供同样的筛选入口。结果必须包含所选的全部标签，最多选择 20 个，可与状态、里程碑、负责人和审查者等现有条件组合；筛选条件保留在页面地址中，便于刷新和分享。 Issue、Pull Request 及其评论支持八种表情回应，代码行讨论和回复也可回应。登录用户可添加或取消自己的回应，页面显示各表情的总数；仓库可见性规则同样适用，删除评论会清理该评论的回应。 在 Issue、Pull Request 描述、评论、代码行讨论及审查说明中输入 `@用户名`，可向有仓库阅读权限的用户发送站内提醒。编辑内容时只提醒新提及的用户；已静音的讨论不会发送提醒，同一次事件会与订阅通知去重。代码块、行内代码、Markdown 链接和邮箱中的内容不会触发提及；每次最多处理 20 个不同用户名，通知会定位到对应评论、讨论回复或审查；目标已删除时会显示提示。输入 `@` 后可通过键盘或鼠标选择用户建议；建议包含仓库所有者、当前协作者，以及公开仓库中该讨论的参与者。私有仓库只建议当前有访问权限的成员。 Pull Request 描述可使用 `Closes #123`、`Fixes #123` 或 `Resolves #123` 等关键词关联同仓库 Issue；合并到仓库默认分支后，关联的待处理 Issue 会自动关闭并发送站内通知。非默认分支不会触发自动关闭，代码块和链接里的文字不会被识别。关联在合并开始时固定，即使合并完成后服务中断，恢复时也会按原关联完成关闭；仓库所有者和有写入权限的协作者也可在 Pull Request 或 Issue 页面手动关联，每个 Pull Request 最多关联 10 个同仓库 Issue；手动关联与关键词关联并存，合并后不能再修改手动关联。在 GitGo 中合并到默认分支时，实际进入默认分支的提交消息也可用这些关键词关闭同仓库 Issue，但不会创建 PR 关联；压缩合并只检查最终生成的提交消息。每次合并最多处理 200 个不同的提交消息引用，单条提交消息不超过 2 MiB。直接通过 Git HTTP 推送到默认分支时也会处理新进入分支的提交消息；推送到其他分支不会关闭 Issue。推送前会保存恢复记录，更新后与关闭通知一同完成；若同步失败，后续 Git 推送、网页文件编辑、分支操作或 PR 合并会先重试，服务启动时也会恢复。直接推送最多处理 10,000 个不同引用，单条提交消息不超过 2 MiB；超限或恢复错误时，推送可能已完成，需先处理服务日志中的恢复错误。网页创建、编辑、上传和删除文件时，默认分支提交说明中的关闭关键词也会生效；若文件已提交但 Issue 状态暂未同步，页面会显示提示并保留恢复记录。跨仓库关联暂不支持。 仓库所有者可以在仓库编辑中关闭“合并关联的 Pull Request 时自动关闭 Issue”：关联仍会保留，合并时也不会因同一 Issue 在提交消息中重复出现而关闭它；未关联 Issue 的提交消息关键词以及直接推送和网页提交的关键词仍会生效。该设置在合并开始时固定，恢复时保持原规则。 Issue 关闭时可选择“已完成”或“不计划处理”，关闭后可修改原因；重新打开后会显示“已重新打开”。列表支持按原因筛选并保留在页面地址中。升级前已关闭的 Issue 未记录原因，会显示为“原因未记录”，可在详情中补充；由 PR、Git 推送或网页提交自动关闭的 Issue 标记为“已完成”。仓库所有者和可写协作者可以将 Issue 标记为其他 Issue 的重复项，支持跨仓库目标，并可选择同时以“重复项”为原因关闭；解除标记不会改变关闭状态。目标不可见时不会显示其编号或标题。评论支持 `Duplicate of #123` 和 `Duplicate of owner/repo#123` 标记，代码块和链接不触发；标记与关闭是独立操作。Pull Request 也支持跨仓库重复标记、记录和解除，可选择同时关闭；写入者可以通过同样的评论关键词标记，目标不可见时不会显示其信息。Issue 和 Pull Request 仅能标记为同类型的重复项；URL 格式引用暂不支持。 ### 父 Issue 和子 Issue 在 Issue 详情中，仓库所有者和可写协作者可以创建子 Issue，或将同一所有者的其他仓库中有权查看的 Issue 添加为子项；支持排序、移除和更换父项。更换父项还需要管理原父 Issue 的权限。每个 Issue 最多有一个父项、100 个直接子项及 8 层嵌套，系统会阻止循环和超出层级的移动。页面显示可查看子项的关闭进度，隐藏无权查看的父项和子项；进度只统计当前用户可查看的直接子项。 ### Issue 依赖关系 Issue 详情支持设置“受阻于”和“阻塞”的双向依赖，可跨仓库关联有权查看的 Issue。添加或移除时需要受阻 Issue 所在仓库的写权限；每个方向最多 50 项，系统会阻止循环依赖。阻塞项关闭后，关联仍保留，但不再使任务处于受阻状态。Issue 列表可筛选受阻、正在阻塞其他任务，以及与指定 Issue 有依赖关系的任务；只显示和统计当前用户有权查看的关联。依赖变更会通知受阻 Issue 的订阅者，事件不包含不可查看的关联目标信息；Webhook 暂不支持。 ### Issue、Pull Request 和评论的编辑历史 Issue 和 Pull Request 的标题、描述及评论（包括代码行讨论及回复）编辑后会显示“已编辑”。仓库读者可以查看每次编辑之前的内容、编辑人和时间；内容作者及有写权限的协作者可以从历史中删除单个版本的内容，保留编辑记录；标题与描述版本会一同清除。删除当前评论也会清除其历史；每个内容项的原始版本和最近 99 次编辑前的版本最多保留 100 条。历史从本功能启用后的编辑开始，无法补回以前未记录的内容。删除历史内容不会修改当前内容或其他版本，也不会清理已有数据库备份。 ### 锁定讨论 仓库所有者和可写协作者可以锁定或解锁 Issue / Pull Request 讨论，并可选择偏离主题、讨论过于激烈、问题已解决或垃圾信息作为原因。锁定后，只有所有者和已接受邀请的协作者可参与评论、回复或审查，并可按原有权限删除评论，所有用户暂时无法更改表情回应；已有评论仍可按原权限编辑。页面显示锁定原因及最近 100 条锁定记录，对非仓库协作者隐藏操作者身份。Issue 和 Pull Request 列表支持按锁定状态筛选；锁定记录目前不发送站内通知。 ### Rebase 并合并 选择 Rebase 并合并时，GitGo 将来源分支的新提交逐个重放到目标分支，保留原作者、作者时间及提交说明，更新提交者并生成新的提交 ID；来源分支保持不变。原本为空或重放后不再产生变化的提交会被跳过，原提交签名不会转移。合并前会校验分支、审查条件与重放结果：逐提交发生冲突，或重放后的文件与普通合并结果不一致时，会拒绝合并并保持分支不变。每次最多处理 1000 个提交，单条提交说明最多 2 MiB，变基计算限时 120 秒；超限或超时可在本地处理或选择其他合并方式。最终 Git 引用更新仍采用原子校验并支持中断恢复，进入默认分支的重写提交说明可以关闭同仓库 Issue。 ### 仓库合并方式与提交说明 仓库所有者可在“编辑仓库”中分别允许或禁用合并提交、Squash、Rebase 和 GitGo 的快进合并，至少保留一种。设置对仓库内的所有 Pull Request 生效；直接 Git 推送不受这些选项限制。合并页面只提供仓库允许的方式，若当前只允许快进但分支不能快进，需要更新分支或调整设置。合并提交和 Squash 支持自定义提交标题及说明；Rebase 和快进保留各自的提交历史，不使用自定义合并说明。自定义说明中指向同仓库 Issue 的关闭关键词仍会生效。合并前会再次检查设置、审查条件和分支；页面中的旧设置发生冲突时需刷新。 ### 仓库重命名 仓库所有者可在编辑仓库时更改名称；新建和重命名时，同一所有者的仓库名称不区分大小写。升级前若已有仅大小写不同的名称，建议重命名消除歧义。仓库页面、Git HTTP 地址、Issue、Pull Request、Wiki、收藏和协作者仍使用原有仓库 ID。旧名称在被同一所有者重新使用前，仍可用于评论中的 `Duplicate of owner/repo#编号` 引用；重用后旧名称指向新仓库，已建立的关联保持不变。 ### 个人主页、资料和克隆地址 用户可在设置中修改公开显示名称和个人简介，并通过 `/users/用户名` 查看个人主页。主页展示该用户的仓库，并按访问者的权限过滤私有仓库；列表最多显示最近的 100 个，数量显示所有可见仓库。主题和导航偏好仍保存在当前浏览器。 仓库页面提供 `http(s)://服务器/用户名/仓库名.git` 格式的克隆地址。仓库重命名后请使用新地址；原有 `/git/仓库ID.git` 地址仍可使用。由于旧地址占用了 `/git/数字.git`，当用户名为 `git` 且仓库名为数字时，页面提供原有 ID 格式以避免冲突。私有仓库和推送继续使用现有权限及认证规则。 ### 设置默认分支 仓库所有者可在分支列表中将已有分支设为默认分支。代码首页、新克隆和新建 Pull Request 默认使用该分支，已有 Pull Request 的目标分支保持不变。后续提交消息和 Pull Request 关联的 Issue 自动关闭规则按新的默认分支判断，切换本身不会追溯处理历史提交。切换会先恢复未完成的推送，并核对当前默认分支和目标提交；此操作需要 Git 2.46 或更高版本。 ### 更改 Pull Request 目标分支 打开的 Pull Request 可由作者或仓库可写协作者更改目标分支，并查看最近 100 条变更记录。变更可能改变差异；旧批准不会计入新的合并条件，已有讨论和当前来源提交上未解除的修改请求会保留。更改会发送站内通知，并在审查与合并时检查目标版本，防止旧页面操作错误分支。关联 Issue 是否自动关闭会按新的目标分支和仓库设置重新判断。 ### 解除 Pull Request 审查 仓库所有者和可写协作者可以解除打开的 Pull Request 中的批准或修改请求，并须填写原因。原审查、解除人、原因及时间会保留在讨论中，相关订阅者会收到站内通知；原因中也可使用 @用户名。被解除的审查不再计入合并条件，也不会使同一审查者更早的审查重新生效。解除不可撤销，审查者可以提交新的审查；解除批准后仍须满足仓库要求的批准人数。 ### Wiki 设置 仓库所有者可启用或停用 Wiki。停用后页面、历史和相关通知暂时隐藏，重新启用后恢复；已保存内容不会被删除。公开仓库可选择允许所有已登录用户创建、修改、删除和恢复 Wiki 页面，关闭 Wiki 后重新启用会保留先前的编辑设置。将仓库设为私有会自动关闭公开编辑，再次公开也不会自动重新开放。默认只允许所有者和可写协作者编辑。 ### Wiki 搜索与页面链接 Wiki 侧栏可搜索当前仓库未删除页面的地址、标题和正文，结果最多显示 50 项；搜索遵守仓库访问权限，并支持中文及其他 Unicode 文本的大小写匹配。页面内可使用 `[[Guide]]`、`[[Guide|链接文字]]` 或 `[链接文字](Guide.md)` 跳转到同仓库页面；代码块中的内容不会被转换。页面地址目前仍限字母、数字、连字符和下划线。 ### Wiki 版本对比 Wiki 页面历史会显示修改人，读者可以输入两个版本号，查看标题和正文的逐行增删；比较删除或恢复操作时，已删除版本按页面不存在显示。Wiki 编辑者可以从对比结果恢复旧版本，若页面已被其他人更新则需要重新比较。当前已删除的页面仅编辑者可在回收站中比较。差异过大时最多显示 10,000 行或 256 KiB；比较需要服务端 Git。 ### 探索 探索页面提供公开仓库和用户发现。仓库可按名称、描述或所有者搜索，并按主要语言筛选；支持按创建时间、总收藏数或近 7 天仍保留的收藏数排序。趋势收藏数会随取消收藏减少，并非历史事件统计；私有仓库和创建中的 Fork 不会出现在结果或统计中。用户可按用户名或显示名称搜索。结果每页 20 条，筛选和页码保留在地址中。主题、个性化推荐和人工精选尚未实现。 ### 个人项目 登录后可以创建、编辑和删除自己拥有的项目，并在表格、看板和路线图之间切换。看板可通过拖动条目手柄或状态选择器调整状态；拖动仅改变状态，不调整列内顺序。任务支持标题、说明、状态、优先级、开始日期和截止日期；页面提供完成进度、关键词/状态/优先级筛选及截止日期/优先级排序。路线图按已填写的日期展示，未排期任务单独列出。每个项目最多 500 个条目。 项目默认仅创建者可见。所有者可按用户名邀请编辑者或查看者；邀请出现在被邀请人的项目页面，接受后才可访问。所有者管理项目设置和成员，编辑者可管理任务、指派负责人和发表评论，查看者只读。每个项目最多 100 名受邀或已加入成员（不含所有者）；移除成员会清除该成员的任务负责人，并保留变更记录。 任务详情的时间线记录任务创建、状态、优先级、负责人、日期、标题、说明和关联变更及评论；修改任务和写入记录处于同一事务。时间线启用前的历史不会补录，删除任务会删除其时间线；评论目前仅支持新增和查看。任务可关联用户有权访问的 Issue 或 Pull Request，关联不会自动改变原始对象状态。关联权限按每位查看者分别判断；无仓库权限时隐藏关联对象的信息。条目和成员更新使用版本检查。自定义字段、保存视图、迭代和自动化尚未实现。