本文大约需要 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 停用后的替代方案
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` 中，新的贡献者也能快速适应运营流程。短链接虽然是一个小工具，但具有全面提升开发工作流效率的潜力。