目前是有 dev、pre、master 分别是测试、预生产、生产
目前流程是这样的
1.每个人开发新功能时基于 master 切出新分支 feature_xxx 开发完成时合并到 dev
2.测试没问题再将 feature_xxx 合并到 pre
3.预生产没问题再将 feature_xxx 合并到 master
这样的流程感觉 pre 预生产没有存在的必要,预生产应当是直接合并到 master 上的
请问多人开发同一个项目,且每个人的上线时间点都不一样,还有当代码已经提交到预生产了,却又延迟上线,另一个人却提前上线的
这种应该使用怎样的 git 流程?
1
Allianzcortex 2019-12-27 02:19:23 +08:00
我们的做法是只有 dev 作为测试环境和 master 作为生产环境,用 netlify 来部署 Preview feature 做 PR。每个人的上线时间点都不一样这应该是常态啊,除非一个人的任务被另一个人 block 住都没什么问题吧
|
2
seki 2019-12-27 02:26:11 +08:00
我们是用一个统一的配置来控制每个 feature 的开关或者灰度的,只要测试验证通过,每个人都可以一个一个提交往 master 上合并
|
3
msg7086 2019-12-27 06:25:02 +08:00
Staging 应该是上线前的最后一道门槛。如果要上线的 feature 改了,那么就应该重做 Staging 分支,只包含要上线的 feature 来测试。
Git 是很灵活的,不要把他用得那么死板。如果一个分支不适合当前需求了,就重建这个分支。 |
4
br00k 2019-12-27 08:11:11 +08:00 via iPhone
git fkow
|
5
luozic 2019-12-27 08:14:51 +08:00 via iPhone
feature 之间有无依赖或者冲突,没有矛盾或者冲突,并且数据独立性较好,可以一个个上线,gitFlow+CI/CD 就是干这事的。
|
6
finian 2019-12-27 09:05:35 +08:00
目前的流程没问题啊。问题点在哪儿?
|
7
sagaxu 2019-12-27 09:14:16 +08:00 via Android
有人插队先发就让他发,后发的人 rebase 到新发的 master 上
|
8
ducklyl 2019-12-27 09:20:52 +08:00
去掉 pre,保留 dev 和 master 即可。
|
9
Hyseen 2019-12-27 09:26:09 +08:00
不需要 pre 分支
|
11
JJstyle 2019-12-27 09:39:06 +08:00 via iPhone
我们是两周一个开发周期,不存在你的功能先做完就先上线,大家最后都会合到一个分支里,统一测试、上线。
有人会说要是我的功能一周就做完了是不是下周可以划水一周了呢?那宁难道不会工作半天划水半天吗 |
12
earthyan 2019-12-27 09:39:08 +08:00
并不需要 pre 分支,不存在先后关系。merge PR 的时候,记得 rebase 分支就 ok
|
13
Bigglesworth 2019-12-27 09:44:13 +08:00
@JJstyle #11 666 学到了
|
15
DelayNoMore 2019-12-27 09:51:21 +08:00
@JJstyle 我每天都是半天工作,半天划水状态
|
16
wangyzj 2019-12-27 09:52:02 +08:00
Gitflow
|
17
passerbytiny 2019-12-27 09:56:56 +08:00
每个人开发新功能时都切出新分支,这种情况下,最没必要的不是 pre,而是 dev。
在 feature_xxx 上做单元测试,生成 PR ;在 pre 上做集成测试和系统测试,发布预览版本;在 master 分支上再次做集成测试和系统测试,发布稳定版本。上面的合并方向是 feature_xxx→pre→master。如果不需要同时发布预览版本和稳定版本,则取消 pre 分支,feature_xxx 直接向 master 合并。 Github 流程就是单中央分支的。 你现在的流程是有隐患的:测试、预生产用得是 dev、pre 分支,但合并过去的是 feature_xxx 分支。 |
18
binux 2019-12-27 10:09:03 +08:00
单一主线原则:保证 master 分支(你这里是 dev )处于随时可上线发布状态。
如果有任何分支并入会改变这个状态,则先,将任何有相互依赖的 feature 分支先合并再以单一 PR 并入 master。 如果合并后有 bug 使其变为无法发布状态,先 revert 再发布。 预生产本来就是团队的主观决定,一般预生产比测试环境更稳定这样。 另外我们发布是用 tag,比如 staging-1, demo-2, production-3 这样,我觉得比 branch 好很多。 |
19
yang2yang 2019-12-27 10:40:45 +08:00
只能说楼主家做法的跟我司基本上一致的
|
20
zydrsnuo 2019-12-27 14:33:08 +08:00 via Android
我们的流程也是这样的,拉一个新分支开发,然后合并到 dev 联调测接口,之后再合并到 pre 测整体功能和 bug。理论上 dev 是可以省略的,因为可以在新拉出来的分支上联调,然后直接合并到 pre。但是我们有个自动编译和部署的系统,合并到 dev 是为了通过它自动部署到测试环境。
|
21
xavierchow 2019-12-27 21:17:01 +08:00 1
https://xavierchow.github.io/talk_git_branch_model/#/
^这是我在公司推行 git flow 时的一个讲座的资料, 有图比较容易懂,希望能帮助到你。 |
22
homecoming 2019-12-28 10:21:24 +08:00
不是说开发完了就会上线,多人合作,会有一个版本/迭代的概念。
功能开发拉 feature 分支,开发完了,给 QA 进行功能测试 功能测试完成,进入集成分支(版本分支),进行集成测试(功能开发完了,因为依赖方不 OK,或者其他问题,可能会延期,这种 feature 不进入集成,一旦进入集成,原则上必须这个版本上线。) 集成测试完成,进入 release (预发布)分支,进行线上验证,老版本兼容验证等。 验证完成,进入 master 分支,再次验证,然后线上灰度放量。 如果灰度过程中,发现问题,从 master 拉出 hotfix,修复、验证以后 ,合并进入 master. 这种模型,还可以进行多版本同时开发。 |