代码冲突处理在现代 IDE 已经不算个事了吧，图形化操作

直接往 master 干，反正就一个人

我们比较简单粗暴，就在 master 上开发提交，然后 release 的时候再从 master 拉出 release 分支，修 bug 的时候把提交 cherry-pick 到各个需要修复的 release 版本

公共的就一个 master 分支，有新功能或者 bugfix 就自己基于 master checkout 一个新分支，写完后、测试后 merge 到 master ，打个 tag ，根据 tag 走发布

使用 github flow ，其实就是社区玩法，再融合一些企业特点的改变。
master 、release 、test 、dev：分别是部署环境的分支，需要部署才合并上来
n 个 feature 分支：需求开发的分支，理想状态下，需要每个 feature 测试完成再合并到 release 和 master ，但是实际的企业环境可能是多需求单测试环境，所以可以以下操作：
- 开发：测试自己的代码，但是由于依赖其他服务，feature 合并到 dev 分支，部署自测/联调
- 测试：feature 合并到 test 环境，给测试人员过测试用例
- 预发部测试：feature 合并到 release ，部署测试
- 正式发布：feature 合并到 master ，部署

PS：注意每次修复 bug ，到需要在 feature 分支修复，再合并到部署分支，因为需求可能随时回滚，部署分支可能会回退。这个工作流基本满足大部分开发团队和需求情况。

我也想走标准的 git-flow 流，奈何我司是小公司，迭代非常快，要支持这种场景，我司的 git 管理是这样的：只保留 master 这一个维护分支，不设置 dev 分支，多个 feature 分支

前端 12 个开发分支，后端 3 个开发分支，一个需求占一个，上线之前把 master 合并到当前的开发分支就行

每一个 需求/bug 一个分支，遵循 [type]/[title] 的分支名：

feat/add-user
feat/enable-rbac
feat/support-kubernetes-deployment
fix/issue-233
fix/npe-error
feat/JIRA-SERVICE-197
hotfix/JIRA-20240808

测试的时候都往某个专门的分支上 merge 或者走 pull request
developer A: branch feat/add-user merge into test
developer B: branch fix/issue-233  merge into test

此时 developer A 早已经准备上线了:
developer A: branch feat/add-user merge into prod （这时候其实可以 git tag ）

上线没问题，feat/add-user 就可以直接删了，或者放着不动，后续如果这个需求有 bug 了，一定不要继续用这个分支，直接从上次发布的分支上 checkout ，继续往返前面的操作就可以了。

永远不要使用自己的个人分支，不要把分支想象的一个很长远的东西；除了主要用于 发布 的分支，其他一切分支都视作临时的分支。你越是用自己个人固定的分支，冲突就越多，因为你总是要把 prod 分支往自己分支上 pull ，何必呢，看着都累。

之前在某美企，分支全都是用的 JIRA ID ，十多年的老项目，几万个历史分支，十几个人的团队，遇到冲突的情况很少。

GitLab Flow + Atomic MR ，小步快跑

@coderzhangsan 你这个 test 分支感觉和 dev 差不多