git 管理

git 管理
以下流程可能会有不足，在日后工作中随时改进
git上手教程
常用分支作用
master 分支：用于部署生产环境的分支
master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性，任何时间都不能直接修改master分支代码。每次开发、测试、产品确认功能开发完成、没有问题后，由组内负责人将release分支合并至master分支，建立相应tag（版本及版本描述）并部署至生产环境。
release 分支：预上线分支（测试人员测试分支）
release 为预上线分支，发布提测阶段，每次测试人员只需确认开发人员是否已将相应分支合并至release分支，然后部署release分支到相应环境即可开始测试，而无需关心其他分支。

当有新功能分支feature-***或bug修复分支fix-***开发或修复完成（注意是开发或修复完成，而不是开发中），会合并到release分支，开发人员提测，测试人员测试阶段。
当测试人员测试完成之后，由组内负责人合并release分支到master分支，此时master为最新完成代码，然后建立相应tag用作上线。

develop 分支：开发分支（开发共用分支）
develop 为开发分支，一般开发人员开发新功能或修复bug时，将相应分支合并至develop分支部署测试。

注意非特殊情况，不要部署自己的分支到测试环境，可能会影响到前端、测试或其他开发人员
feature 分支：新功能分支
开发新功能时，以最新的master分支为基准创建feature分支
feature分支命名:
命名规则: feature-分支描述-。。。。前两项必须，后面的自己可以随意添加
示例：新增购物车功能feature-AddShoppingCart或feature-增加购物车

(master)$: git checkout -b feature-AddShoppingCart # 从master建立
(feature-AddShoppingCart)$: blabla # 开发
(feature-AddShoppingCart)$: git add xxx
(feature-AddShoppingCart)$: git commit -m ‘commit comment’
fix 分支：修复bug分支
以最新的master分支为基准创建fix分支
fix 分支命名
命名规则: fix-bug号-分支描述-。。。。前三项必须，后面的自己可以随意添加
示例：新增购物车功能fix-WC-51-微官网模板中去掉字样-blabla

(master)$: git checkout -b fix-WC-51-微官网模板中去掉字样-blabla # 从master建立
(feature-AddShoppingCart)$: blabla # 开发
(feature-AddShoppingCart)$: git add xxx
(feature-AddShoppingCart)$: git commit -m ‘commit comment’
optimize分支： 优化代码分支
命名规则: optimize-分支描述-。。。。前两项必须，后面的自己可以随意添加
other分支： 如果有其他类型使用other开头
日志规范
编写良好的Commit messages可以达到3个重要的目的：

加快review的流程
帮助我们编写良好的版本发布日志
让之后的维护者了解代码里出现特定变化和feature被添加的原因

格式
<type>: <subject>

type: 本次 commit 的类型，诸如 fix docs style 等
subject: 简明扼要的阐述下本次 commit 的主旨

Type的类别说明：

feat: 添加新特性
fix: 修复bug
docs: 仅仅修改了文档
style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
chore: 改变构建流程、或者增加依赖库、工具等
other: 如果有其他情况

示例
(test)$: blabla # 开发
(test)$: git add xxx
(test)$: git commit -m ‘fix: 修复了什么什么bug’
(test)$: git commit -m ‘docs: 修改了什么什么文档’
(test)$: git commit -m ‘other: 其他情况’
提交远程分支建议
建议使用gitlab的merge request，这样做的 原因是 方便日后回顾，也不用自己再去 记着 需要合并哪个分支
操作示例
找到自己的分支

点击merge request

写好 标题 和描述，然后选对 想要合并 和 被合并的 分支点击提交

常见问题
如果测试人员在测试release分支过程中遇到bug，开发人员应该怎么办
如果测试过程中存在bug需要修复，则由开发者在自己相应的feature-***或fix-***分支修复bug，然后合并到release分支并推送到远程库。

注意确认bug修复完后再合并到release分支，未确认时，合并到develop分支自己测试
如果 develop 分支和 release 分支 合并错代码，怎么办

最简单粗暴的方法：

如果已经推送到远程分支， 则删除相应远程分支，以master分支为基准，新建相应分支，推送到远程仓库，继续合并想要合并的分支
如果没有推送到远程分支，删除本地分支，重新拉取

git revert的使用