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