如题。
Ask and learn.
我习惯的是，基于master去创建一个带版本号的分支，开发测试完成后提交cr，最后合并到master上去。
最近接触到的是，开发过程中有个devlop分支，每个人创建自己的分支，最后发起pr合并到develop上去。 说实话，不太适应。
我们最近也是 master , develop 这种模型，用起来也觉得挺繁琐的。
两个分支还闲繁琐啊？哈哈
上上家公司用的 master + feature/bugfix branch 模型，用起来很舒服。
上家公司用的 master + develop + feature/bugfix branch 模型，但是合并流程管理并不严格，经常出现紧急的 bugfix 合并到了 master 却忘了合并 develop 的情况， master 的代码也很少向 develop merge，结果就是偶尔会因为这个出 BUG。
两种模型各有优劣，我的感觉是：第一种适合频繁迭代，每次发布只发一个 feature 的项目，比如多数后端项目或者 Web 项目；第二种适合定期发版，一次发布多个 feature 的项目，比如 Android 和 iOS 项目。
感觉 master + featue/bugfix 这种很简洁，不过对于有些 feature 如果在上生产环境前想在一个测试环境上跑一下，只有个 master 感觉比较难处理呢。
并不难啊，我来细讲一下之前我们 master + feature/bugfix branch 的开发和部署流程：
整个流程中有四个环境：
1. 开发环境，可以是你本地或者某个专用开发环境；
2. 测试环境，一般用于新功能测试，可以有多套；
3. 预发布环境，仅有一套，上线前最后的回归测试；
4. 生产环境。
下面开始讲流程：
1. 开始开发： 从 master 创建一个 branch 出来；
2. 开发完成准备测试： 将 master merge 到 branch，以防止你开发过程中 master 合入的新代码和你的 branch 有代码或者业务逻辑上的冲突；
3. 将 branch 部署到测试环境进行测试；
4. 测试完成后，再次将 master merge 到 branch，然后马上部署到 预发布环境进行回归测试，并将预发布环境锁定，禁止其他 branch 部署；
5. 预发布测试完成后将 branch 部署到生产环境，部署完成确认没问题后，将 branch 合并到 master，释放预发布环境。如果在生产环境发现了问题，马上将生产环境回滚到 master，然后根据具体情况来决定是在预发布环境修复、测试后重新上线，还是释放预发布环境回测试环境去测试、修复。
上上家公司时，几百人的技术团队都是照这个流程来走的；小公司或者创业团队规模比较小的时候，可以适当精简一下流程。
感谢，解释的这么详细。👍
有的公司对 git tree 也有洁癖，会要求尽量使用 rebase，不过我个人两种都能接受，只有有效就可以了。
要求 git tree 整齐的话，最后 merge master 的时候把整个 branch 合并为一个 commit 就可以了。master 本身也并没有必要保留 branch 中的每一个 commit。
我之前参加的团队，怎么操作的都有。这方面我比较随性，能适应团队需求就行。举2个例子：
例子1
master/beta/dev
1. 开发用dev分支开发，维护最新的代码
2. beta用来做内部演示环境，给测试的版本也会在这个branch上打tag
3. master是线上环境
例子2 extends 例子1
1. 开发每个story从dev上拉一个分支，然后提PR merge到dev上。这个流程相对正规点，但也麻烦点。好处是能根据每个story的所有改动。原来我们用gitlab的时候，自己写了小工具，能提高点效果。
这东西你会发现每个团队一个玩法，可能和大家的研发流程不完全一样有一定关系吧。
我们是master+dev，2个分支。master上就是线上版本，dev是开发版本。dev开发环境测完，合并到master，发布到集成测试环境测试，完了才打tag，发到正式环境。
我极力要求团队里用rebase，merge commitlog会重复，历史树太难看了。个人开发，rebase同步dev，切一个本地分支去开发。这个流程和参与开源项目的流程大体差不多，少了一个fork的步骤。
如果线上有bug，从master切出一个hotfix分支，修复bug，单独测试并发布到正式环境。然后再把hotfix合并到master上。
看来大部分都是 master dev
不喜欢太多分支，一般就2个，master+dev
我用的是master + develop模型，我更关心项目回退时，能够快速准确定位。楼上对比了merge和rebase的好坏，我感觉跟个人使用的工具【git CLI 还是 git GUI】也有关。二者其实可以搭配使用吧，使用rebase有条黄金法则【不要在公共分支上使用】。
gitflow
我这边有 开发环境 + 测试环境 + 内外灰度环境 + 正式环境 😇😇😇
挖出来一个陈年老帖 说一个分支策略和持续集成/发布的方案
spotify实践一种持续集成/部署的自动化流水线，分支策略大概是这样的
feature -> master/dev -> stg -> uat -> pre-production -> production
分支的合并永远是单向的：从左边流向右边，不允许逆流
一共有五个线上环境，分别对应dev, stg, uat, pre-production和production，和一个本地开发环境（对应feature分支）。其中pre-production和production应尽量保持相同的配置，用于预发布前最后的测试和hotfix 当然如果业务需要0 downtime的蓝绿部署的话保持pre-production和production相同配置就更有必要了。pre-production在做完最后测试验证通过后直接在路由把流量打到pre-production，此时production和pre-production角色调换
代码push和MR都会触发CI/CD流水线进行自动化测试和部署，如果测试没有通过，会对部署进行自动回滚，该次MR也会被撤销。需要开发团队从feature分支修复问题然后顺着流水线方向再次MR
hotfix的情况，从production切出来一条hotfix分支，本地环境验证完MR到pre-production进行最终测试。如果是蓝绿部署的，直接在路由端把线上流量打到pre-production并完成两个环境的角色互换；如果非蓝绿部署，则从pre-production MR到production进行部署发布。发布完成后从hotfix分支MR到master/dev
所有feature分支都应从master/dev切出来，以保证每个新迭代都是基于最新的代码
从master -> stg -> uat -> pre-production的MR是定期的，比如两周一次迭代，也可以配合敏捷开发的sprint周期设置。需要发布的迭代必须在预定时间前提交代码，否则应顺延到下一个发布周期。这里有一个“发布列车”的概念，即发布列车永远是定时定点开车的，所有需要发布的功能必须在开车前装载上车，否则要等下一班发布列车。如果本次迭代没有需要发布的功能，发布列车也会发车（空载）。这对各环境不会造成负面影响，但保证发布列车即使在空载情况也定期发车对保证流水线/集群自动、正常的发布非常有意义。
当然这个是16年左右看到的文章，不知道目前他们是否还采用这种分支策略。我个人觉得这个策略对于自动化集成和部署是非常有帮助的。在自动化脚本的帮助下，整个流程不需要太多的人工介入。是帮助敏捷开发（快速迭代和持续交付）落地的很好的一个实践。
还有其他的想到再补充
另外，我刚才一伙兄弟喜欢用merge。说是能看到谁合了代码，merge也有会多问题。如：在merge的那个commit时，看不到是具体哪个commit改的代码。还有log tree会非常乱。
另一伙人，喜欢用rebase。这样会维护一条非常漂亮的log tree，方便维护。我个人比较喜欢这种。
git flow 有新功能建一个feature，写完后，随便找个闲着的测试服务器切到对应分支供测试测试。测试通过后合develop，在测试一回，没问题后合master上线，嗯，灰度的只是华东，一天后，客服没炸，全面上线。
公司按照自己的名字新建分支，然后提交给指定的项目经理合并。提交代码注释写功能的需求号+全称，修改BUG代码提交注释需求号+功能+修改点。
master+develop+tag，用户都是基于develop拉取自己的分支开发，然后提交，最后统一的跟master做merge，master分支做发布使用，然后打tag。bufix也是基于master进行
Trunk-Based Development，所有提交直接去master，每次提交都会触发CI / CD
保持代码树干净，拉新代码用 git pull --rebase
尽量不用PR
第一次听说这种模式，那同事之间，如何 code review 呢？
基本所有代码都是结对编程产出的，pair 对象不固定。不过我们也会两周左右一起 review 一下大家的代码（都在 master 分支）
git-flow
1. 代码提交流程Commit 提交代码到本地仓库Pull 拉取远程仓库代码（如果有冲突，联系相关开发者，一起解决。）Push 推送本地仓库代码到远程仓库2. 代码分支规范分支含义主分支 -> master -> 主分支，需要发布版本的时候将dev合并到master发布发布分支 -> release.{v.1.0.1} 版本号 -> 发布master版本稳定后，创建分支resease_{版本号}，提供可回滚稳定版本。协同开发分支 -> dev -> 开发成员协同开发分支，在本地分支开发完以后合并到dev分支本地开发分支 -> dev_{local} 本地分支名称 -> 本地分支，按需求、BUG等创建本地分支，目的是在同时开发多个BUG的时候，各个BUG修复提交互相不冲突。3. 代码提交规范type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature，所有的type类型如下：feat： 新增featurefix：修复bugdoc：仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等refactor：代码重构，没有加新功能或者修复bugperf：优化相关，比如提升性能、体验test：测试用例，包括单元测试、集成测试等chore：改变构建流程、或者增加依赖库、工具等revert：回滚到上一个版本tag：标记或者打标签
根据具体的业务复杂度调整的gitflow
下载APP，能及时收到回复或进展
我习惯的是，基于master去创建一个带版本号的分支，开发测试完成后提交cr，最后合并到master上去。
最近接触到的是，开发过程中有个devlop分支，每个人创建自己的分支，最后发起pr合并到develop上去。 说实话，不太适应。
我们最近也是 master , develop 这种模型，用起来也觉得挺繁琐的。
两个分支还闲繁琐啊？哈哈
上上家公司用的 master + feature/bugfix branch 模型，用起来很舒服。
上家公司用的 master + develop + feature/bugfix branch 模型，但是合并流程管理并不严格，经常出现紧急的 bugfix 合并到了 master 却忘了合并 develop 的情况， master 的代码也很少向 develop merge，结果就是偶尔会因为这个出 BUG。
两种模型各有优劣，我的感觉是：第一种适合频繁迭代，每次发布只发一个 feature 的项目，比如多数后端项目或者 Web 项目；第二种适合定期发版，一次发布多个 feature 的项目，比如 Android 和 iOS 项目。
感觉 master + featue/bugfix 这种很简洁，不过对于有些 feature 如果在上生产环境前想在一个测试环境上跑一下，只有个 master 感觉比较难处理呢。
并不难啊，我来细讲一下之前我们 master + feature/bugfix branch 的开发和部署流程：
整个流程中有四个环境：
1. 开发环境，可以是你本地或者某个专用开发环境；
2. 测试环境，一般用于新功能测试，可以有多套；
3. 预发布环境，仅有一套，上线前最后的回归测试；
4. 生产环境。
下面开始讲流程：
1. 开始开发： 从 master 创建一个 branch 出来；
2. 开发完成准备测试： 将 master merge 到 branch，以防止你开发过程中 master 合入的新代码和你的 branch 有代码或者业务逻辑上的冲突；
3. 将 branch 部署到测试环境进行测试；
4. 测试完成后，再次将 master merge 到 branch，然后马上部署到 预发布环境进行回归测试，并将预发布环境锁定，禁止其他 branch 部署；
5. 预发布测试完成后将 branch 部署到生产环境，部署完成确认没问题后，将 branch 合并到 master，释放预发布环境。如果在生产环境发现了问题，马上将生产环境回滚到 master，然后根据具体情况来决定是在预发布环境修复、测试后重新上线，还是释放预发布环境回测试环境去测试、修复。
上上家公司时，几百人的技术团队都是照这个流程来走的；小公司或者创业团队规模比较小的时候，可以适当精简一下流程。
感谢，解释的这么详细。👍
有的公司对 git tree 也有洁癖，会要求尽量使用 rebase，不过我个人两种都能接受，只有有效就可以了。
要求 git tree 整齐的话，最后 merge master 的时候把整个 branch 合并为一个 commit 就可以了。master 本身也并没有必要保留 branch 中的每一个 commit。
我之前参加的团队，怎么操作的都有。这方面我比较随性，能适应团队需求就行。举2个例子：
例子1
master/beta/dev
1. 开发用dev分支开发，维护最新的代码
2. beta用来做内部演示环境，给测试的版本也会在这个branch上打tag
3. master是线上环境
例子2 extends 例子1
master/beta/dev
1. 开发每个story从dev上拉一个分支，然后提PR merge到dev上。这个流程相对正规点，但也麻烦点。好处是能根据每个story的所有改动。原来我们用gitlab的时候，自己写了小工具，能提高点效果。
这东西你会发现每个团队一个玩法，可能和大家的研发流程不完全一样有一定关系吧。
我们是master+dev，2个分支。master上就是线上版本，dev是开发版本。dev开发环境测完，合并到master，发布到集成测试环境测试，完了才打tag，发到正式环境。
我极力要求团队里用rebase，merge commitlog会重复，历史树太难看了。个人开发，rebase同步dev，切一个本地分支去开发。这个流程和参与开源项目的流程大体差不多，少了一个fork的步骤。
如果线上有bug，从master切出一个hotfix分支，修复bug，单独测试并发布到正式环境。然后再把hotfix合并到master上。
看来大部分都是 master dev
不喜欢太多分支，一般就2个，master+dev
我用的是master + develop模型，我更关心项目回退时，能够快速准确定位。楼上对比了merge和rebase的好坏，我感觉跟个人使用的工具【git CLI 还是 git GUI】也有关。二者其实可以搭配使用吧，使用rebase有条黄金法则【不要在公共分支上使用】。
gitflow
我这边有 开发环境 + 测试环境 + 内外灰度环境 + 正式环境 😇😇😇
挖出来一个陈年老帖 说一个分支策略和持续集成/发布的方案
spotify实践一种持续集成/部署的自动化流水线，分支策略大概是这样的
分支的合并永远是单向的：从左边流向右边，不允许逆流
一共有五个线上环境，分别对应dev, stg, uat, pre-production和production，和一个本地开发环境（对应feature分支）。其中pre-production和production应尽量保持相同的配置，用于预发布前最后的测试和hotfix
当然如果业务需要0 downtime的蓝绿部署的话保持pre-production和production相同配置就更有必要了。pre-production在做完最后测试验证通过后直接在路由把流量打到pre-production，此时production和pre-production角色调换
代码push和MR都会触发CI/CD流水线进行自动化测试和部署，如果测试没有通过，会对部署进行自动回滚，该次MR也会被撤销。需要开发团队从feature分支修复问题然后顺着流水线方向再次MR
hotfix的情况，从production切出来一条hotfix分支，本地环境验证完MR到pre-production进行最终测试。如果是蓝绿部署的，直接在路由端把线上流量打到pre-production并完成两个环境的角色互换；如果非蓝绿部署，则从pre-production MR到production进行部署发布。发布完成后从hotfix分支MR到master/dev
所有feature分支都应从master/dev切出来，以保证每个新迭代都是基于最新的代码
从master -> stg -> uat -> pre-production的MR是定期的，比如两周一次迭代，也可以配合敏捷开发的sprint周期设置。需要发布的迭代必须在预定时间前提交代码，否则应顺延到下一个发布周期。这里有一个“发布列车”的概念，即发布列车永远是定时定点开车的，所有需要发布的功能必须在开车前装载上车，否则要等下一班发布列车。如果本次迭代没有需要发布的功能，发布列车也会发车（空载）。这对各环境不会造成负面影响，但保证发布列车即使在空载情况也定期发车对保证流水线/集群自动、正常的发布非常有意义。
当然这个是16年左右看到的文章，不知道目前他们是否还采用这种分支策略。我个人觉得这个策略对于自动化集成和部署是非常有帮助的。在自动化脚本的帮助下，整个流程不需要太多的人工介入。是帮助敏捷开发（快速迭代和持续交付）落地的很好的一个实践。
还有其他的想到再补充
另外，我刚才一伙兄弟喜欢用merge。说是能看到谁合了代码，merge也有会多问题。如：在merge的那个commit时，看不到是具体哪个commit改的代码。还有log tree会非常乱。
另一伙人，喜欢用rebase。这样会维护一条非常漂亮的log tree，方便维护。我个人比较喜欢这种。
git flow
有新功能建一个feature，写完后，随便找个闲着的测试服务器切到对应分支供测试测试。
测试通过后合develop，在测试一回，没问题后合master上线，嗯，灰度的只是华东，一天后，客服没炸，全面上线。
公司按照自己的名字新建分支，然后提交给指定的项目经理合并。提交代码注释写功能的需求号+全称，修改BUG代码提交注释需求号+功能+修改点。
master+develop+tag，用户都是基于develop拉取自己的分支开发，然后提交，最后统一的跟master做merge，master分支做发布使用，然后打tag。bufix也是基于master进行
Trunk-Based Development，所有提交直接去master，每次提交都会触发CI / CD
保持代码树干净，拉新代码用 git pull --rebase
尽量不用PR
第一次听说这种模式，那同事之间，如何 code review 呢？
基本所有代码都是结对编程产出的，pair 对象不固定。不过我们也会两周左右一起 review 一下大家的代码（都在 master 分支）
git-flow
1. 代码提交流程
Commit 提交代码到本地仓库
Pull 拉取远程仓库代码（如果有冲突，联系相关开发者，一起解决。）
Push 推送本地仓库代码到远程仓库
2. 代码分支规范
分支含义
主分支 -> master -> 主分支，需要发布版本的时候将dev合并到master发布
发布分支 -> release.{v.1.0.1} 版本号 -> 发布master版本稳定后，创建分支resease_{版本号}，提供可回滚稳定版本。
协同开发分支 -> dev -> 开发成员协同开发分支，在本地分支开发完以后合并到dev分支
本地开发分支 -> dev_{local} 本地分支名称 -> 本地分支，按需求、BUG等创建本地分支，目的是在同时开发多个BUG的时候，各个BUG修复提交互相不冲突。
3. 代码提交规范
type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature，所有的type类型如下：
feat： 新增feature
fix：修复bug
doc：仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
refactor：代码重构，没有加新功能或者修复bug
perf：优化相关，比如提升性能、体验
test：测试用例，包括单元测试、集成测试等
chore：改变构建流程、或者增加依赖库、工具等
revert：回滚到上一个版本
tag：标记或者打标签
根据具体的业务复杂度调整的gitflow