团队项目的Git分支管理规范

Posted 2023-05-10

参考技术A 创建项目时（一般是服务型项目，工具型或辅助型项目可以简单一些），会针对不同环境创建三个常设分支：

平时开发工作中，会根据需要由开发人员创建两类临时分支：

并行开发（即前一个版本已经仿真测试完成但未上线，后一个版本又已在开发中并部分合并到了develop分支）过程中，转测后测试环境发现的bug需要修复，但是develop分支此时又有新内容且该部分内容目前不计划转测，可以release切出一个bug修复分支。完成之后需要同时merge到release分支与develop分支。merge时参考“正常开发流程”。流程示意图如下

生产环境的Bug分两种情况：

紧急Bug：严重影响用户使用的为紧急Bug，需立即进行修复。如关键业务流程存在问题，影响用户正常的业务行为。
非紧急Bug或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急Bug，可规划到后续版本进行修复。

参考 半路雨歌的博客# 团队项目的Git分支管理规范

前端项目中使用git来做分支和合并分支，管理生产版本

最近由于公司前端团队扩招，虽然小小的三四团队开发，但是也出现了好多问题。最让人揪心的是代码的管理问题；公司最近把版本控制工具从svn升级为git。前端H5组目前对git的使用还不是很熟悉，出现额多次覆盖代码和提交冲突的问题。还有最近一次产品版本迭代的时候出现额一个问题： 一个正在开发的版块在下一次版本迭代中不需要上线了，而是修改了这个版块的一些小细节。这个正在开发的版块需要在下下一次产品迭代的时候上线。

 

这里来简单的记录下使用git做代码版本控制的方法：（主要是建立分支，在分支上修改当前版本的bug，随时准备上线新修复的bug的当前版本；以及同时在主干上继续开发新的功能，为下个版本做准备）

 

整个的流程图是这样的：  

 

如果不是有这个分支hotfix，那么当你一直在主干上开发新功能的时候，产品或者测试通知你： 你需要在生产版本上修改一些地方，并马上上线时，你只能撤回已经开发好的代码，并进行修改，然后再把撤销的代码在修改上线后再补回去。但是如果是多人操作呢？

 

于是我们来用git解决这个问题：

创建项目

 

 线上发布1.0版本 

 

 1.0版本是这个样子的：

 

 

 

 

 

创建分支并切换到分支 

 

 

创建一个分支： git branch 分支名

查看所有分支： git branch

这时候在当前分支前会有一个 * 号

 

在分支上修改bug（给当前内容加一个样式）

 

 

 

当前分支变成了这个样子 

 

 提交分支的内容： 

 

切换到主干继续开发新功能 

 

这时候你会看到git已经把你的代码切换到了主干代码

 

 目前主干还是1.0版本上线时候的样子

 

 

 我们在主干上开发新功能（加了一个h1标签）

 

 

目前主干上的样子

提交主干的新功能 

 

 

 这里commit 的-a是去掉多余的提交

 

这时候2.0版本准备上线，合并主干和分支 

 

 

使用git pull && git push 拉取并提交代码

 

你会发现你的代码已经具备了上线的全部内容：

 

 

 

 目前是这个样子的；

 

 

 这对于多人开发，和经常性的版本迭代是非常重要的。希望能帮助到大家