Git 三大分支策略， 2 个人的前端团队，开发一个中型应用，适合用哪种策略

[unt]

现在哪种策略比较主流，易于操作

[zhlxsh]

那三大？

[1217950746]

https://github.com/fork-dev/TrackerWin/issues/1432

[unt]

@1217950746 先赞为敬

[unt]

@zhlxsh gitflow githubflow gitlabflow

[1217950746]

@unt 这个分支结构更加简单和灵活，我之前用 gitflow 比较多，后来就换这种简单结构了（不全用）

[1217950746]

@unt 更多的时候，我会选择 Rebase 干掉 Merge xxxx 之类的记录

[AngryPanda]

人少的话，我投 gitlab flow 一票

[Vaspike]

请问各自 fork 一个主仓库然后各自向主仓库 pull request(merge request)的方式有啥名字不

[guchengzhihuan]

一人一个开发分支，做好了往主分支合并就完了

[gzyguy]

@Vaspike github flow 吧

[caixiangyu17]

trunk based development

[unco020511]

很简单,一个主分支,n 个 feature 分支,通过 mr(pr)往主干合

[jones2000]

就 2 个人还要什么策略，各管各开发。2 个人负责独立的模块，不要有耦合，交互定义好接口协议或接口函数就行了。后期联调就完事了。

[leiuu]

这种 case 简单的主干开发模式可能比较适合 这三个都不用

[janus77]

2 个人不是 master 一把梭？还有策略？

[justicelove]

赞楼上

[unt]

@jones2000
@janus77 哈哈，两个人很多了（哭泣），最近在招人，差不多 4 个人，长期项目

[unt]

谢谢，全赞了一遍

[zhuweiyou]

直接主分支开发

[seth19960929]

上面的人都是疯了吗, 直接 master 开发, 这要是代码还在测试有 bug 继续修复怎么上.
我个人认为比较实用的

master => prod
dev => 测试

A, B 开发者(对于你们两个人)
开发新功能就从 master checkout 一个 feature 分支. 然后开发完成推到线上, 合并到 dev 分支, 然后部署到测试环境.

测试通过验收后, feature 分支合并到 master 分支, 部署线上