多人开发同一个项目且每人进度不一样，上线时间不一样 git 应该使用什么样的流程？
Idealyouth · 2019-12-27 02:11:26 +08:00 via iPhone · 5339 次点击这是一个创建于 1799 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前是有 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. 这种模型，还可以进行多版本同时开发。 |
Select Language