先记住这几点
- 分支、标签和Release是不同层次的对象。
- 围绕同一个版本阅读文档与源码。
- 需要重复核对时同时保留提交标识。
四个词放在同一张图里理解
初次阅读海角官网git相关资料时，常见误区是把默认分支、最新标签和已发布版本当成同一个东西。Git 官方教材将分支解释为可移动的提交引用；标签用于标记历史中的重要位置。GitHub 的 Release 则在标签基础上补充发行说明与附件。
| 对象 | 阅读用途 | 不能直接推断 |
|---|---|---|
| 提交 | 定位一次具体代码状态 | 该状态一定适合使用 |
| 分支 | 跟随一条开发路线 | 名称叫 main 就是稳定版 |
| 标签 | 按名称寻找历史节点 | 有标签就有完整发行附件 |
| Release | 查看一次版本交付 | 发行日期等于标签创建日期 |
先选阅读目标，再选择版本
若只是理解项目结构，可以从默认分支的说明开始；若要解释某个已有版本的行为，应找到该版本对应的文档和代码。想比较变化，则选择两个明确节点进行对照。不同任务需要不同参照，不能单靠“最新”两个字完成选择。
虚构教学情景：某项目的 v1.4 文档写一种配置格式，而默认分支已准备 v2.0 的改动。读者若把新 README 与旧安装包混用，得到的步骤可能互相冲突。把文档切回目标版本，通常比反复尝试不同参数更有条理。
记录版本时别只抄一个名称
分支会继续变化；标签虽常被用于标记发行节点，技术上也可能被移动或重新创建。因此需要可重复核对的笔记时，除分支或标签名称外，再记录对应提交标识与阅读日期。GitHub 对归档的说明也提醒，分支或标签指向变化后，再次下载的内容可能不同。
- 确认当前选择器显示的是分支、标签还是具体提交。
- 保存完整提交标识，并写明它与哪个版本名称对应。
- 阅读同一版本的 README、配置示例和发布说明。
- 比较版本时列出变化项、影响条件及仍不明确的地方。
标签名称不是通用质量承诺
v1.0、stable、release 等名称由项目自行约定。版本号看起来整齐，并不能替代项目对兼容性和支持范围的说明。遇到预发布标记，应回到发布正文理解用途；缺少发布说明时，不要凭编号自行写出功能清单。
同样，发行页与标签的日期可能不同。若在笔记里写“发布于某日”，应明确所指的是发行时间、提交时间还是自己的阅读时间，避免把不同时间轴混用。
完成阅读后的自查
试着用一句话复述：“我正在阅读某仓库某标签对应提交的文档，用来理解某个配置。”如果这句话仍需要用“好像是最新版”代替具体参照，就还没有完成版本定位。
资料来源与延伸阅读
下列原始文档用于核对通用技术概念，不构成对任何同名项目官方身份的证明。