本文大约需要 3 分钟阅读
## GitHub 的 URL 为什么会变长
GitHub 的 URL 将所有者名、仓库名、分支名和文件路径全部拼接在一起。例如，指向特定文件特定行的永久链接会变成这样：
`github.com/organization/repository-name/blob/a1b2c3d4e5f6/src/components/authentication/LoginForm.tsx#L42-L58`
Issue 或 Pull Request 评论的链接也会附带 `#issuecomment-1234567890` 这样的片段标识符，整体经常超过 150 个字符。代码审查的差异链接更是文件路径和哈希值的组合，超过 200 个字符的情况也不少见。
将这些长 URL 粘贴到 Slack 的消息串或邮件中，URL 会占据消息的大部分空间，降低沟通效率。
## git.io 停用后的替代方案
GitHub 曾提供名为 `git.io` 的官方短链接服务。但在 2022 年停止了新 URL 的创建，现有短链接的重定向也在逐步失效。这意味着缩短 GitHub URL 的官方途径已经不复存在。
替代方案包括：
- 使用自有域名的短链接服务 - 用自定义域名运营短链接 - 结合 GitHub Pages 创建重定向页面
在开源项目中，使用项目专属子域名 (例如 `go.project-name.dev/issue-123`) 作为短链接的做法越来越普遍。
## README 中的短链接应用
GitHub 仓库的 README 是项目的门面，也是最多人浏览的文档。用短链接管理 README 中的链接有以下几个优势。
### 徽章 URL 的简化
在 README 开头排列 CI 状态徽章、覆盖率徽章、许可证徽章等是常见做法，但每个徽章的图片 URL 和链接 URL 都很长，导致 Markdown 源码难以阅读。使用短链接可以让徽章的 Markdown 更简洁，README 的编辑也更方便。
### 文档站点的导航
许多开源项目在 GitHub 仓库之外还运营着独立的文档站点。从 README 链接到文档站点各页面时，使用短链接可以灵活应对链接变更。即使文档站点的 URL 结构发生变化，只需更新短链接的重定向目标，无需修改 README。
## CI/CD 流水线中的通知链接
CI/CD 流水线失败时向 Slack 或 Teams 发送通知是常见做法。将通知消息中的链接替换为短链接，可以提升通知的可读性。
### 实现模式
在 GitHub Actions 工作流中，在构建失败时发送 Slack 通知的步骤中加入短链接生成。具体来说，将失败的工作流运行 URL 发送到短链接 API，将返回的短链接包含在 Slack 消息中。
这种方法的优势不仅在于通知消息更紧凑，还能通过点击分析衡量“收到通知的工程师中有多少人实际查看了日志”。如果通知的查看率较低，就可以作为改进通知目标或消息内容的依据。
### 部署通知的应用
短链接在部署完成通知中同样有效。将部署环境的 URL、变更内容的 PR 链接、回滚操作文档链接等多个 URL 用短链接整理后包含在通知消息中，紧急情况下也能快速访问所需信息。
## 开源项目中的应用案例
### 在 Issue 模板中嵌入短链接
在 Bug 报告或功能请求的 Issue 模板中包含贡献指南和行为准则的链接是常见做法。将这些链接替换为短链接，即使指南的 URL 发生变更也无需修改模板。
### 在发布说明中的应用
发布说明中通常包含大量与变更内容相关的 Issue 和 PR 链接。使用短链接可以提升发布说明的可读性，用户也能更快地访问感兴趣的变更详情。
开发者生产力提升相关的书籍也可以在 Amazon 上找到。
## 开发团队的运营规范
在开发团队中运营短链接时，建立以下规范可以确保顺畅运作：
- 统一短链接的命名规则 (例如 `repo-issue-123`、`repo-pr-456`) - 临时链接 (如代码审查请求) 设置有效期 - 永久链接 (如文档、指南) 不设有效期 - 在 Notion 或 Wiki 中管理短链接清单，确保团队全员可访问
将这些规范写入 README 的 `CONTRIBUTING.md` 中，新的贡献者也能快速适应运营流程。短链接虽然是一个小工具，但具有全面提升开发工作流效率的潜力。