git describe 合并带新标签的分支后为何不显示最新标签

先明确git describe的核心运行规则：

该命令会从当前分支的HEAD提交出发，遍历所有可达的历史提交链路，查找距离当前提交最近的标签（包含带备注的annotated标签、轻量标签），输出格式为「最近标签-跨标签的提交数-当前提交短哈希」；添加--abbrev=0参数时，只会输出匹配到的纯标签名。

结合实际得到的返回结果，异常来自两个操作环节的偏差：

• 标签挂载位置和计划不符
  在dev分支上得到v0.19.0-1-ge147b2d的结果，说明v0.19.0标签实际指向的提交，比dev当前的HEAD早1个提交。也就是说实际的打标签操作是在提交just some testing之前完成的，和计划的操作时序相反，标签没有落在本次要发布的代码提交上。
• 跨分支合并后的历史链路不连通
  如果是常规的git merge dev操作合并分支，生成的合并提交会同时携带原staging HEAD、dev HEAD两个父节点，从staging HEAD出发完全可以回溯到dev链路上的所有提交（包括挂着v0.19.0标签的提交），git describe不可能找不到更近的标签。
  结合staging、master分支上的返回结果仍然停留在老的v0.17.0标签，说明实际的合并操作要么使用了--squash参数压缩提交（把dev的所有变更打包成一个和dev原历史完全断开的全新提交），要么是手动拷贝文件后直接在staging、master上提交变更，没有关联dev的历史提交。这种操作下，staging和master的历史链路根本无法触达dev上挂着v0.19.0标签的提交，自然只能识别到自己链路上更早的v0.17.0标签。

修正上述两个操作偏差后，就能实现dev分支打标签后，全分支统一识别版本标签的需求，标准操作步骤如下：

• 先提交变更，再执行打标签操作
  检出dev分支完成代码修改后，先执行git add --all && git commit -m 'just some testing'完成提交，确认本次发布的代码提交已经成为dev的最新HEAD。
• 精准绑定版本标签到发布提交
  执行git tag -a v0.19.0 -m 'Release v0.19.0'创建带备注的版本标签，此时标签会直接指向刚才完成的发布提交。可以执行git show v0.19.0核对标签指向的提交哈希，避免标签挂到更早的历史提交上。
• 使用常规模式完成跨分支合并，不压缩提交
  检出staging分支后，直接执行git merge dev完成合并，不要添加--squash参数。合并过程中如果遇到冲突，正常解决后提交合并结果即可，保证合并提交的第二个父节点是dev的HEAD，让两个分支的历史链路自然连通。合并完成后执行git push origin staging将分支推送到远程。
  后续检出master分支，同样使用常规git merge staging模式完成合并，推送远程仓库即可。
• 统一推送版本标签
  执行git push origin v0.19.0将标签推送到远程仓库。因为标签直接挂载在本次的发布提交上，只要分支历史链路连通，后续不管这个提交被合流到哪个分支，所有分支的HEAD都能回溯到这个带标签的提交，实现全分支版本识别一致。

特殊场景说明：如果分支历史已经分叉、无法通过常规合并建立连通，可以在各分支的对应发布节点上补打同名版本标签，保证版本识别一致，这种操作不需要重复同步代码，只需要补充标签即可。

内容的提问来源于stack exchange，提问作者zlZimon