共计 2158 个字符，预计需要花费 6 分钟才能阅读完成。
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 的使用
