如何看待 CI 持续集成产生的大量 tag？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 2389 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近在研究 CI 由于公司业务性质，网站每天可能会有数十次的更新上线，而每次上线都会通过 CI 自动化的 release 打上语义化的 tag，长期下来产生的 tag 非常的多，担心后续对 git 仓库的管理和性能产生的影响。

不禁思考，每次 git 提交都有 commit id，为何还要 tag ？打这么多 tag 是不是太浪费了

25 条回复 • 2019-07-11 14:21:52 +08:00

zealic

2019 年 7 月 10 日

对性能影响不大，语意化及可追溯更重要。

tuxz

2019 年 7 月 10 日

也可以使用 commit id 的前几位作为标签

miaoxia

2019 年 7 月 10 日

每天数十次的上线肯定是有问题的
每次上线打 tag 这样的行为是对的
commid id 和 tag 完全不是一个纬度的东西
建议去了解下 git flow 工作流，分别了解下开发、提测、上线及修复不同 bug 的处理流程
打 tag 不会对性能造成影响，无意义的 co 二进制文件才会

zhuweiyou

2019 年 7 月 10 日

每天上线 10 次。。。

chinesestudio

2019 年 7 月 10 日 via Android

我就好奇啥业务

misaka19000

2019 年 7 月 10 日

每天上线数十次？这种上线频率肯定是有问题的

clino

2019 年 7 月 10 日 via Android

可以将 sha1 信息存在一个专门的 git 里来记录历史

mercury233

2019 年 7 月 10 日

- bash -c "git tag -d latest ; exit 0"
- git tag latest HEAD
- git push -f origin latest

mikicomo

2019 年 7 月 10 日

每天上线十次？是开发自己有权限发版么？如果是运维，不怕被打死？

bkmi

2019 年 7 月 10 日 via Android

多业务线并行的情况下每天上线数十次真的挺正常的，不过可以考虑拆分一下

petelin

2019 年 7 月 10 日 via iPhone

我们大概有 200 多万 tag 吧

Torpedo

2019 年 7 月 10 日

你这上线太多了，不要怪 ci

mywaiting

2019 年 7 月 10 日

依稀记得先前看 coolshell 的 blog，里面有说 amazon 的基础设施每几秒钟就有一次部署？

每天线上能滚动部署数十次，侧面说明你们的线上环境 /流量转移 /AB 测试都做得挺好的，应该感谢有这么好的开发部署流程啊

git tag 多少无所谓的，我个人的项目都有好几百个 tag，回滚比 comment id 要方便好多

好像记得有一种利用 git tag 来进行灰度发布，引入部分流量开启部分 feature 测试的方法，大体是这个思路，我没有实践过，贴主可以去自己搜索看看

ericgui

2019 年 7 月 11 日

@mikicomo 全都自动化了，没什么了不起的

xiaket

2019 年 7 月 11 日

为什么上面这么多同学认为每天上线十几次是坏事的?

wenzhoou

2019 年 7 月 11 日 via Android

@xiaket 因为上线是个很严肃的事情需要审查。而且因为上线频繁，有可能导致大量 bug 不知道到底在什么版本会重现，相当于定时炸弹。

ericgui

2019 年 7 月 11 日

@wenzhoou 全自动的嘛，从 push 到 run test，到 build 到 deploy，一条龙自动化

能够做到这个，理论上你要写很多测试用例的，尤其是新加 feature 的时候，要写很多测试用例。所以其实一般这么做，显然都是 master branch 做这一套，有权限管理，只能有权限的人把自己的分支合并到 master。