请求互联网企业中，频繁的上线项目，代码是如何管理的，最好能看下 git workflow 长啥样

V2EX = way to explore

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

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

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

目前公司的测试环境只有一个，但是有的代码测试周期比较长且上线比较频繁，传统的 workflow 好像并不适合如 workflow，那么使用 git，如何管理代码，以及如何实现自动化部署呢,求教？？

workflow

代码

git

上线

15 条回复 • 2019-03-22 11:38:13 +08:00

nullcoder

2017-10-17 13:42:41 +08:00

你想问的是 CI/CD 的方案吧，跟 git workflow 没啥关系
可以了解一下 gitlab 的方案
https://about.gitlab.com/features/#release

jinhan13789991

2017-10-17 13:46:27 +08:00

git 有比较标准的分支管理。
持续集成系统，比如 jenkins，可以配合 git 一起使用。
自动化部署可以考虑使用 docker。
比如 git 有：开发分支，测试分支，发布分支。
就可以使用 jenkins 来检测分支提交变化，自动打包部署 docker。
以上只是我个人的见解，希望能够帮助到你

MrXiong

2017-10-17 13:59:17 +08:00

@nullcoder，不是 ci/cd，是代码的管理，不是 ci,cd 的实现。问题是单个测试环境，有的代码测试周期比较长但是别的需求需要测试上线，在这种情况下能通过 git 方便的管理代码吗

nullcoder

2017-10-17 14:08:24 +08:00

你说的单个测试环境是什么意思？
是两个需求的测试环境相同？那就没问题
两个需求不能同时测试？这个就。。。
git 本来就去中心化了，做好版本管理，不建议搞太多分支。

frankynwa

2017-10-17 14:12:29 +08:00

团队一直用 gitflow 的 http://www.cnblogs.com/cnblogsfans/p/5075073.html
但是一直也没有解决周期长的分支的合并问题
我们一直认为最好不要产生跨迭代的特性
也不要在一个迭代里让两个开发同时做一个功能 = =

zhangsen1992

2017-10-17 14:39:03 +08:00

gitlab 做好各个分支测试上线联调打好 docker

cnJason2012

2017-10-17 15:15:44 +08:00

我原来在某互联网独角兽公司工作做过一小段时间的 DevOps。当时我们团队对于频繁上线的系统采用的是这样的管理方式：git 上面分 3 个分支。master、stable、develop。功能描述是：develop 是开发主分支，以供开发人员合并代码和联调使用。stable 是稳定版本。以供多部门协调用的调试版本 [也称稳定版本] 。只有 stable 上经过确认的版本才能上 master 分支。这些都有专门的 CICD 的项目来进行管理。每天对于 master 分支的上线次数是有规定的。会避免一大部分失误造成的上线。

bash99

2017-10-17 15:28:06 +08:00

说个在小 team 里面实现得还过得去的模式（当时 docker 还不够流行）

前提：
1. 强大的测试能力或者说自动化测试
我们的测试哥们工资很高，能指导开发数据库设计不合理，能写自动化测试
2. 较好的线上环境重建能力；包含标准测试数据库依赖的环境 5 分钟（也就是不管因为测试把数据库弄得怎么样了，5 分钟全套回复到标准环境）；线上数据库脱敏重建 30 分钟；
3. 变更管理较完备，数据库变动版本化进入代码。

做法：
敏捷模式，每周 release，但是每 2 ～ 4 周为一个 sprint，每个 sprint 里面程序员手头 3 ～ 6 个功能 /Fix，每个功能一个分支。少数情况 2 ～ 3 人工作在一个分支上
hotfix/紧急变动在测试通过后会迅速合并到 master
分支提测前，会保证合并了当前 master （普通 merge 模式；不 rebase -- 当时大家 rebase 用得实在不熟，否则 rebase 应该也行）。会要求程序员做基本自测。
自动化测试通过后，该分支会被合并到一个测试环境（代码包括所有提测的分支），合并有冲突会打回让程序员自己去兼容其它分支（这个情况比较少，可能也是比较麻烦的，基本上让他们本地拿测试分支 merge 找问题）；这个测试环境会再来一轮自动化，有问题也打回，然后 revert （这两步后期是土法脚本化了）；
然后在这个环境上做对应的新功能测试，有问题也是 revert 掉这个分支带来的改动。
周五下午会决定哪些功能在上述环境上已经稳定并且准备上线，所有待上线分支都冻结，然后单个分支 squash merge 到 master。对这个 master 做一些最后测试并确认。
周一上线。（只有脚本自动化，有回退，但是没有灰度发布，有数据库变动且不兼容回退也碰到过，这个没完美解决好）
之后删除已上线两周的老分支（少数重要分支打 tag 后删除）。

优势是 master 上都是干净的一个个功能 commit 和部分 hotfix。

另外，如果分支跨了 sprint，基本上也是很烦的，和其他分支冲突几率大大增加；通常我们在回顾会上检讨是产品经理粒度不合适还是开发没做好。

现在有 docker 了按说可以把上面的自动化测试和环境重建做得更好方便。我仍然觉得 CI 流程做好了是基础，git 只是更灵活更能适应各种的 CI 流程而已。

zhaoace

2017-10-17 15:32:49 +08:00

感觉不是代码的问题，是测试环境不够的问题。你们可能把 staging 的测试环境当成 dev 测试环境来测 feature 用了。

feature 没 complete 之前，不确定能上的时候是不能进 staging 环境的。feature 全测通过了决定合并进去上线了再进 staging 环境。也就是说测 feature （ dev 测试环境）和测 release （ staging 测试环境或者叫 migration 测试环境）是要分开的。

基本等同#7 楼说的做法。

一个测试环境是不够的。。。想想单车道怎么超车，对吧。。。