4.3 克隆与标签发布
4.3 克隆与标签发布
本节摘要：clone 是对象库的整库复制加引用初始化，标签是"钉死不动的命名指针"。本节讲克隆的协议与深浅取舍、两种标签的对象级差异、以及把版本发布钉进历史的完整流程。
学习目标
- 能解释克隆后本地自动建立了什么引用与绑定
- 能按场景选择完整克隆、浅克隆或单分支克隆
- 能区分轻量标签与附注标签并正确选择
- 能完成一次规范的版本发布打标与推送
一、clone：对象库的整库快递
git clone 做的事比"下载代码"多得多：复制远端对象库、为远端每个分支建远程跟踪引用、为 HEAD 指向的分支建本地分支并绑定跟踪、初始化工作区。取证验证：
git clone https://example.com/team/project.git cd project git branch -a # * main # remotes/origin/main # remotes/origin/dev <- 远端其余分支只建镜像 不建本地副本 cat .git/HEAD # ref: refs/heads/main # 与远端 HEAD 一致
注意第三行：远端的 dev 分支只以镜像形式存在——克隆默认只检出一个本地分支，要看别的分支 git switch dev 会基于镜像自动创建并绑定。传输协议上 HTTPS 与 SSH 的取舍主要在认证方式：HTTPS 走凭据管理器、SSH 走密钥对，企业内网常两者并存（SSH 推、HTTPS 拉）。协议对对象模型完全透明，对象在两边的哈希一字不差——这正是分布式设计的底气。
浅克隆取舍：超大仓库（比如浏览器内核、系统源码）全量历史动辄数 GB，git clone --depth 1 只取最近一层快照，体积骤减。代价是历史残缺：看不到旧 log、无法做涉及深度的 merge-base 推理、blame 到浅层边界即止。CI 流水线里跑构建测试是浅克隆的最佳场景；日常开发别用，会频繁撞墙。介于两者之间还有 --filter=blob:none 的部分克隆（先拿 tree 与 commit，blob 按需取），是近年大仓库的折中方案。单分支克隆 --single-branch 则适合只关心一条线的场合。
二、标签：钉死的命名指针
第 2 章说过分支是"会挪动的书签"，标签则是"钉死在某一页的姓名贴"。两种形态的对象级差异：
轻量标签只是一个引用文件，refs/tags/v1.0 直接指向某提交，不新建任何对象：
git tag v1.0-light git cat-file -t v1.0-light # commit —— 它就是提交本身
附注标签是一个完整的 tag 对象，带打标人、日期、说明，还可 GPG 签名：
git tag -a v1.0 -m "首个正式版" git cat-file -t v1.0 # tag git cat-file -p v1.0 # object e5f6a7b... <- 指向提交 # type commit # tag v1.0 # tagger 侦探 <det@example.com> ... # # 首个正式版
选择原则一句话说死：对外发布用附注标签，临时书签用轻量标签。附注标签的信息（谁、何时、为什么发版）是发布审计的一部分，还能被签名验证防篡改；轻量标签更像私人的临时记号。
三、发布流程实战
以一次小版本发布为例，串起标签与远端：
git switch main git pull --rebase # 确保站在主干最新 git tag -a v1.2.0 -m "修复登录超时 新增导出功能" git push origin v1.2.0 # 标签不随普通push走 必须显式推 git tag -l "v1.*" # 本地核对 git ls-remote --tags origin # 远端核对
两个易错点：其一，普通 git push 默认不推标签（无论新旧版本 Git 都要求显式推标签或用 --tags），发布后务必远端核对；其二，--tags 会把仓库里所有标签一口气推上去，包括早年的测试标签，规范仓库用点名推送。误推了标签可以删：git push origin --delete v1.2.0，但若发布已被他人拉取，删除比改错更伤——标签同样受"已共享的引用别乱动"法则约束。错字标签宁可废弃重建（v1.2.0 改 v1.2.1）也不要原地改名。
语义化版本速记：主版本号破坏兼容、次版本号向下兼容的新功能、修订号纯修复。团队把版本号规则和打标权限（谁能打 release 标签）写进规范，发布就不再是口口相传的手艺。
从克隆到发布的生命周期
⚠️ 常见坑：在浅克隆里打标签或做深度合并，遇到"缺失对象"报错。浅克隆是只读考古与构建的省钱姿势，不是完整工作区；发现历史不够时可用
git fetch --unshallow补齐。
还有一句直觉值得记牢：发布不是复制一份代码，而是给某个哈希起一个永不改变的名字。zip 包会散佚、分支会被清理，而钉在对象链上的标签只要仓库活着就永远指向同一棵 tree——版本可追溯的根基全在这一个指针上。
本节要点回顾
- 克隆四件事：复制对象库、建镜像引用、建绑定本地分支、初始化工作区。
- 浅克隆有边界：CI 省空间利器，日常开发补全（--unshallow）再用。
- 标签两形态：轻量只是引用文件，附注是独立对象可签名，对外发布必用附注。
- 标签要显式推：点名推送优于 --tags，远端核对是发布闭环。
- 共享标签别乱动：错字重建新号，不删不改已发布标签。
第 4 章结案。至此你已经打通"本地对象库到远端引用"的全部机制。最后一章，把这些机制组装成团队的工作流与规范。