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

[unt]

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

[jones2000]

@unt 2 个人垒界面就够累的了，更不要提核心模块的研发了， 没有核心技术就靠开源堆出来的东西，没有门槛，也没有竞争力，路走不长的。

[unt]

@jones2000 #21 这你不用担心的，公司挺有钱的，不靠我们挣钱

[unt]

😩 😩 说错了说错了，4 个人的团队

[qwerthhusn]

一两个人，就 master 一条路走到黑

[AyaseEri]

dev 一条，qa 一条，master 一条。
一路 rebase 走到底。

[karott7]

说一条 master 分支走到黑的也太狠了吧，个人觉得一个长期项目即使是一个人开发也最好遵循某一个分支开发流程

[laolaowang]

我司 是 master / feature-*** 足矣

[mazai]

我司是主仓库 master （ pord ），dev （ test ，uat ）两个分支

每个开发 fork 主仓库到自己的仓库，在自己的仓库开发，push 之后，提交 PR 到主仓库，给领导 CR ，没问题就合并到主仓库的 dev 分支。

功能 dev 完毕没问题，就合并到主仓库的 master 分支，发布环境。

[fpure]

直接一个主分支，小改动就直接在上面改，大改动就建个新分支改完合并

[unt]

@fpure 你走吧，你是 1 铜币都不想要

[u823tg]

@unt #30 楼上说的也没多大错， 两个人太复杂的策略目测是坚持不下来的。 太复杂也会降低你们开发效率， 一个人在 n 个 feature n 个 fix dev master 切换。 人少精简点别自己给自己找麻烦。 人多了可以上那些开发策略

[imycc]

以前用的 gitflow ，实践中开始往 gitlab flow 靠，我觉得还行。
用 gitflow 最麻烦的问题是长生命周期的分支，在合并的时候会引入大量的差异，做 Code Review 很累人。尽量细化功能分支、多提交，多跟进主分支，能一定程度缓解问题。
同时去看了一些人在推荐的 trunk based development ，理念也不错，但要求不低。团队人力充足、有专职测试、发布频繁的，可以试试。

[GiantHard]

投 trunk based development 一票，记得完善自动化测试

[msg7086]

trunk based development 这个比较适合传统开发模式。
敏捷开发一般保证 dev/master 是随时可用，feature 上做功能。
传统开发一般保证 release/*是随时可用，dev/master 上做功能。（当然还是要配合 personal branch+MR 。）