迁移至 MQL5 Algo Forge（第 4 部分）：使用版本和发布·进阶篇
（2/3）· 派生改完代码只是起点，发布前弄丢分支指针的人远比你想象的多
「HEAD 指针到底指向哪儿」
Git 里有个固定名字叫 HEAD 的指针，它不算标签，却总跟着当前签出的分支跑，自动停在那个分支最新的提交上。它实质是“你现在在仓库哪个位置”的答案，物理上存在 .git/HEAD 文件里，内容要么是符号引用（分支或标签名），要么是裸提交哈希。 切换分支时 HEAD 会自己更新；一旦你提交新内容，Git 建好提交对象后还会把 HEAD 挪过去。命令里可以直接写 HEAD 代替长哈希或分支名，用 HEAD~2 这种写法就能指最近提交往前数两步的那一笔，不用死记哈希。 仓库通常处在 attached HEAD 状态，新提交规规矩矩接在当前分支最新提交之后，编辑按序叠加、不打架。另一种 detached HEAD 就麻烦些：HEAD 直接钉在某个不是最新的提交上，比如 git checkout <commit-hash>、git checkout tags/<tag-name>，或者切到本地删了但远程还在的分支 origin/<branch-name> 都会触发。 这种游离状态能避则避——切去别的分支时，里头没挂任何分支的改动大概率直接丢。要是你只打算翻历史不改东西，暂留一下也无妨，但别手痒提交。
◍ 切到旧提交会掉进 detached HEAD
把本地仓库切到某个过去的提交，在日常 Git 流程里很少见。比如那个曾属于已删分支 article-17698-forge2 的最新提交，它其实还在 develop 分支历史里，只是后面已经有了更新的提交，不再是顶端。 用命令行强行切过去能成功，但仓库会进入 detached HEAD 状态，Git 会明确警告你 HEAD 不再指向任何分支顶端。 有个细节容易让人疑惑：截图里切的提交哈希是 58beccf233，Git 却报 HEAD 在 58beccf。这不是丢失了三位，而是 Git 允许用缩短哈希，只要仓库内唯一，界面常显示 4 到 10 个字符。 要拿完整 40 位哈希，跑一次 git log 即可。因为哈希随机唯一生成，前几位几乎必然不同，所以短前缀通常就够 Git 精确定位提交。
把旧 MQL5 文件从 UTF-16LE 转成 UTF-8
MetaEditor 早期版本用 UTF-16LE 存源码，Git 会把它当二进制——提交里只能看到文件前后体积变化，没法 diff 具体改了哪行。Visual Studio Code 本地能读，但仓库网页端（如 MQL5 Algo Forge）只显示「大小从 X 字节变为 Y 字节」，定位改动基本靠猜。 新版本 MetaEditor 新建文件默认 UTF-8，即便写俄文、中文等字母也不再自动跳回 UTF-16LE。手头若有老项目残留的 UTF-16LE 文件，用编辑器转存为 UTF-8 后推一次 commit，之后网页端就能逐行高亮变更，哪行哪列动了看得一清二楚。 外汇与贵金属 EA 开发涉及杠杆与滑点，代码版本失控可能直接把旧逻辑带进实盘，风险不低。转编码这步不复杂，但能省掉后期扒变更的瞎忙。
「把 develop 的更新并回未完工分支」
仓库里 article-17608-close-manager 和 article-17607 这两条分支还挂着没合进 develop，因为对应任务没收口。先挑 article-17607 往下做，做到逻辑完成点再并回主干，最终打版本标签。 切过去之前得先把 develop 上已合并的稳定改动拉进 article-17607。反向合并（稳定代码进新代码分支）用 Git 控制台命令比 Web 合并请求更顺手，后者适合把未测代码并进稳定分支的场景。 当前 HEAD 在 article-19436-forge3，git status 显示与远程同步。执行 git checkout article-17607 切换，再 git merge develop——由于外部改动只碰到我们没动过的文件，无冲突，Git 自动建了一个合并提交。 git push 之后去远程看，最后一次提交就是 develop 与 article-17607 的合并节点。article-19436-forge3 仍是自由端，工作没完，先搁着，时机到了再回来。 至此 article-17607 已具备继续编码的条件，具体任务解法在别处讲，这里只交代收尾前怎么定版和留痕。