源码获取与版本管理
说到源码获取和版本管理，这几乎是每个项目的第一步。但你别小看这一步，我在好几个项目里都见过团队在这里栽跟头——要么分支乱成一锅粥，要么子模块忘了更新，编译半天报错才发现。今天咱们就把这块讲透。
说白了，搞国密SDK集成，代码的源头必须干净，版本必须可控。不然你辛辛苦苦调通了一个版本，回头想追溯某个改动的来龙去脉，结果发现啥都查不到——那种感觉我真不想再体会第二次。
从GitHub/Gitee克隆国密SDK
先讲克隆。这看似简单，但里头有门道。
HTTPS 还是 SSH？我个人习惯用 SSH。为什么？因为 HTTPS 每次 push 都要输密码，即便配置了 ，次数多了也挺烦。SSH 配好密钥后一劳永逸。但如果你在服务器上做 CI，或者网络环境受限，HTTPS 反而更稳。
| 方式 | 命令示例 | 适用场景 |
|---|---|---|
| HTTPS | git clone https://github.com/GmSSL/GmSSL.git |
首次使用、服务器CI、网络受限环境 |
| SSH | git clone git@github.com:GmSSL/GmSSL.git |
日常开发、频繁提交、个人电脑 |
git clone https://gitee.com/GmSSL/GmSSL.git。我在国内团队时就这么干，速度快多了。
克隆的时候还有一个参数值得关注：--depth。如果你的 CI 环境只关心最新代码，不需要历史记录，可以只拉最近一次的提交。像这样：
git clone --depth=1 https://github.com/GmSSL/GmSSL.git
这能省下不少磁盘和网络开销。但要注意——如果你用了子模块，单靠 --depth 可能不够，后面我会讲。
分支策略：怎么管才不乱
分支管理这件事，我在新手期吃过亏。那时候觉得分支想建就建，结果项目后期分支列表一拉几十个，谁是谁都分不清。
核心原则：主分支要稳定，开发分支要灵活，特征分支要独立。
国密SDK集成项目我建议这么搞：
- main 或 master：只放经过测试通过的稳定版本。任何人往这里合代码，必须先过CI和Code Review。
- develop：日常开发的主战场。新功能从这里拉出特征分支，完工后再合回来。
- feature/xxx：每个新特性一个分支，完成即合并并删除。
- release/vX.Y.Z：准备发布时用的分支。只能修 bug，不能加新功能。
- hotfix/xxx：线上出了紧急 bug，直接从 main 拉出来修，修完再合回 main 和 develop。
为什么这么强调？因为你想想看，如果 CI 跑的是 main 分支，那么任何一次合并前都要确保没有破坏主流程。但我们日常开发中，新功能总会带来风险。让 develop 承担这份风险，main 只收稳定版本——这个思路在团队协作中极其重要。
标签管理：给版本打上烙印
标签是什么？它就是给某个 commit 贴个名字，方便以后快速找到它。我在项目里最常用的标签格式是语义化版本：v1.2.3。
打标签分两种：
- 轻量标签：只是指向某个 commit 的指针。比如
git tag v1.0.0。 - 附注标签：包含作者、日期、备注信息。比如
git tag -a v1.0.0 -m "正式发布1.0.0版本"。
我个人强烈推荐使用附注标签。为什么？因为国密SDK验证往往涉及合规审计，标签里的信息能帮助追溯。我记得有次紧急修复，就是因为之前的标签有详细备注，我们才能在几分钟内定位到对应版本。
# 打附注标签
git tag -a v1.0.0 -m "国密SDK持续集成验证基线版本，支持SM2/SM3/SM4"
# 推送标签到远端
git push origin v1.0.0
# 查看所有标签
git tag -l
子模块更新：最容易忽略的坑
子模块（submodule）是国密SDK项目中常见的结构。比如 SDK 本身依赖了一个数学库或加密核心，这些库以子模块的形式引入。
但子模块有个特点：主仓库只记录子模块的 commit id，不保存子模块的实际内容。所以当你克隆主仓库后，必须手动拉取子模块。
标准操作流程是这样的：
# 克隆主仓库
git clone https://github.com/your-org/gmssl-ci.git
# 进入目录，初始化并更新子模块
cd gmssl-ci
git submodule init
git submodule update
如果你想一次性搞定，加个 --recurse-submodules 参数：
git clone --recurse-submodules https://github.com/your-org/gmssl-ci.git
这个坑我踩过。当时在 CI 机器上跑构建，编译到一半报错说某个头文件找不到。我查了半天，发现是子模块没拉取。后来我养成习惯——每次克隆后第一件事就是检查子模块状态。用 git submodule status 看一眼，确保都是绿色的。
本章知识体系结构
下面这张图把本章核心逻辑串起来了。你看一遍就知道各个步骤之间的关系：
好了，以上就是关于源码获取和版本管理的核心内容。从克隆方式的选择，到分支策略的设计，再到标签管理和子模块更新——每一步都可能影响后续的持续集成验证效率。建议你对照自己的项目情况，看看有哪些地方可以优化。