关于Git分支模型的思考

现状

现有分支 feature,develop (测试),release (沙箱),master(生产)

提交的顺序为 master -> feature -> develop -> release -> master

问题

目前develop的代码一定会被提交到release，同时很多时候为了测试和前后端联调，需要临时把代码合并到 develop 分支上面去，就会导致临时测试的代码会被裹挟到 release 分支上面去，导致沙箱环境代码被污染，所以测试分支的代码需要和沙箱环境的代码解耦，也就是测试分支 develop 代码不允许被合并到 release 分支上面去。

改进

改进后的代码提交顺序如下图：

改进重点就是 develop 和 release 解耦合, 不用再担心上述问题, 且不需要修改任何 devops 设置.

进一步改进

新增一种分支 feature-relase 特性-预发布分支，在大型任务的时候非常有用

大型分支一般有以下的特点

• feature分支多，彼此之间需要经常同步代码
• feature分支多，分散，不利于代码的审查

feature-release 分支一般用来提前同步开发好的代码，既能方便代码审查又能及时的同步各个特性分支的代码（注意箭头是双向的），分支名一般取当前分支名的英文名即可。

技术 Leader 可以直接在 feature-release 上进行代码修改, 组员手头的 feature 分支再进行同步.

结论

git 工作流无疑已经成为大部分程序员代码协作的工作，在使用的过程中可以根据项目的特点，进行改造，加快工作的效率。另外，在拆分任务的时候，尽可能的拆分足够的小，足够的独立，这样尽可能的避免代码冲突的问题，如果任务比较大，需要几个人同时进行开发，需要及时的同步代码，可以有效地避免冲突。