git分支处理？

Question

想问问，你们公司是如何处理Git分支的？

你们公司会有几个分支？分别是哪几个分支？

线上bug是从哪个分支上拉取修改？然后如何合并？

Answer 1

当前项目的远程仓库上面三个分支 main，test-stage，test-dev。
长期存在的分支只有 main。test-stage 和 test-dev 其实作用差不多，只是为了区分多个测试环境。

开发的时候基于 main 拉出来本地开发分支。修BUG会看情况，线上环境还是测试环境上面的BUG会基于不同分支来修复。

线上BUG一般会从主线分叉出来修复，测试完成没有问题就直接合并回主线了。
后续开发分支功能完成之后会 rebase 到主线最新的版本（或者开发分支提前 rebase 都可以），并不会有影响。

这个主要是看你们 gitflow 是如何规定的。如果没有的话，可以借鉴几个比较成熟的git工作流，然后选择适合你们自己的就好。

---

之前我也问过一个相同的问题 👉 HXDM你们的Git分支有几个？

Answer 2

每人一个分支，或者每个小任务一个分支
这样最大的好处就是，不会发生分支冲突报错的问题，因为分支的使用者就一个人
然后某个人的任务完成了，发起合并请求，让主分支审核一下，OK的话就合并过来
这样管理起来就舒服了

Answer 3

3个分支：
master：用于定版，打tag，合入的代码必须是最稳定的版本。
dev：用于开发，各开发人员自行在dev分支解决代码冲突。
release：每次部署现场，该分支必须同步现场部署的代码。

Answer 4

git flow 了解一下

Answer 5

dev --> 本地开发分支
test --> 测试环境分支
master --> 生产环境分支
hotfix --> 线上环境紧急修复分支

一般是dev开发完，代码合并到test分支，打包部署到测试环境
经测试没问题，代码合并到master分支，打包部署线上环境

如果线上有紧急bug需要修复，则从master分支拉一个hotfix分支出来，代码修复完合并到test分支进行测试，没问题合并到master分支。

最后把代码合并到dev分支，让不同分支都同步修改过的代码。

Answer 6

版本控制系统采用何种flow, 与团队的规模，人员组织架构，交付的软件在类型（如编译分发的客户端app, 提供给第三方的SDK, 服务端web页面/API等)都有关系，像上面大家回答的git flow, gitlab的MR, github的PR, 都有其适用场景。《Pro Git》中有论述，但不多。从切面讨论的书籍，只看到有《Git团队协作》，如有需要可参看一下。

VCS只是工具，找到适合自己的团队工作流并不断优化才是最好的，有时也可以参看一下像linux kernel, freebsd这样经典的开源项目是如何run的，也能带来一些启发。

好多看起来是技术的问题，比如日常要解决大量的冲突，往往根本原因是这个团队在需求的管理上就是混乱的。最后体现在了技术人员解决冲突而已。

Answer 7

• master，主分支用于生产
• develop，用于开发（所有人都是基于这个分支开创建自己本地分支）
• ......各种特殊功能分支比如（i18n、v1、v2等等）

但是我们必须些CHANGELOG.md