多人开发同一个项目且每人进度不一样，上线时间不一样 git 应该使用什么样的流程？

[Idealyouth]

目前是有 dev、pre、master 分别是测试、预生产、生产

目前流程是这样的
1.每个人开发新功能时基于 master 切出新分支 feature_xxx 开发完成时合并到 dev
2.测试没问题再将 feature_xxx 合并到 pre
3.预生产没问题再将 feature_xxx 合并到 master

这样的流程感觉 pre 预生产没有存在的必要，预生产应当是直接合并到 master 上的

请问多人开发同一个项目，且每个人的上线时间点都不一样，还有当代码已经提交到预生产了，却又延迟上线，另一个人却提前上线的

这种应该使用怎样的 git 流程？

[Allianzcortex]

我们的做法是只有 dev 作为测试环境和 master 作为生产环境，用 netlify 来部署 Preview feature 做 PR。每个人的上线时间点都不一样这应该是常态啊，除非一个人的任务被另一个人 block 住都没什么问题吧

[seki]

我们是用一个统一的配置来控制每个 feature 的开关或者灰度的，只要测试验证通过，每个人都可以一个一个提交往 master 上合并

[msg7086]

Staging 应该是上线前的最后一道门槛。如果要上线的 feature 改了，那么就应该重做 Staging 分支，只包含要上线的 feature 来测试。

Git 是很灵活的，不要把他用得那么死板。如果一个分支不适合当前需求了，就重建这个分支。

[br00k]

git fkow

[luozic]

feature 之间有无依赖或者冲突，没有矛盾或者冲突，并且数据独立性较好，可以一个个上线，gitFlow+CI/CD 就是干这事的。

[finian]

目前的流程没问题啊。问题点在哪儿？

[sagaxu]

有人插队先发就让他发，后发的人 rebase 到新发的 master 上

[ducklyl]

去掉 pre，保留 dev 和 master 即可。

[Hyseen]

不需要 pre 分支

[Kylinsun]

@br00k git flow

[JJstyle]

我们是两周一个开发周期，不存在你的功能先做完就先上线，大家最后都会合到一个分支里，统一测试、上线。

有人会说要是我的功能一周就做完了是不是下周可以划水一周了呢？那宁难道不会工作半天划水半天吗

[earthyan]

并不需要 pre 分支,不存在先后关系。merge PR 的时候，记得 rebase 分支就 ok

[Bigglesworth]

@JJstyle #11 666 学到了

[Huizhen]

@JJstyle 学到了

[DelayNoMore]

@JJstyle 我每天都是半天工作，半天划水状态

[wangyzj]

Gitflow

[passerbytiny]

每个人开发新功能时都切出新分支，这种情况下，最没必要的不是 pre，而是 dev。

在 feature_xxx 上做单元测试，生成 PR ；在 pre 上做集成测试和系统测试，发布预览版本；在 master 分支上再次做集成测试和系统测试，发布稳定版本。上面的合并方向是 feature_xxx→pre→master。如果不需要同时发布预览版本和稳定版本，则取消 pre 分支，feature_xxx 直接向 master 合并。

Github 流程就是单中央分支的。

你现在的流程是有隐患的：测试、预生产用得是 dev、pre 分支，但合并过去的是 feature_xxx 分支。

[binux]

单一主线原则：保证 master 分支（你这里是 dev ）处于随时可上线发布状态。
如果有任何分支并入会改变这个状态，则先，将任何有相互依赖的 feature 分支先合并再以单一 PR 并入 master。
如果合并后有 bug 使其变为无法发布状态，先 revert 再发布。

预生产本来就是团队的主观决定，一般预生产比测试环境更稳定这样。

另外我们发布是用 tag，比如 staging-1, demo-2, production-3 这样，我觉得比 branch 好很多。

[yang2yang]

只能说楼主家做法的跟我司基本上一致的

[zydrsnuo]

我们的流程也是这样的，拉一个新分支开发，然后合并到 dev 联调测接口，之后再合并到 pre 测整体功能和 bug。理论上 dev 是可以省略的，因为可以在新拉出来的分支上联调，然后直接合并到 pre。但是我们有个自动编译和部署的系统，合并到 dev 是为了通过它自动部署到测试环境。