2020-09_Git 使用规范流程

Git 使用规范流程

在开发过程中，遵循一个合理、清晰的GIT使用流程，是至关重要的。否则，每个人都提交一堆杂乱无章的commit,会增加后期协调和维护的复杂度。

• 分支提交流程图示
  

• 分支合并流程图示
  

第一章 分支管理

一 分支命令及说明

• 主分支 (master)
  • master 为主分支，用于部署生产环境的分支
  • master 分支由develop或hotfix分支合并而来，任何时间都不能直接修改其代码
  • 合并到 master 分支的代码，必须保证充分的测试
• tag
  • tag 为master 分支部署到生产环境后，在master分支节点上标注的一个标签。
  • tag 的命名规则：x.y.z。依次为主版本号，次版本号，bug修复号。
• 开发分支(develop)
  • develop 为开发分支，始终保持最新完成的功能和bug修复后的代码。
• 功能分支(feature/xxx)
  • 开发新功能时，以develop 为基准创建feature分支。
  • 分支命名规则： feature/modules,modules为要新增的功能模块
• 修复分支(fix/xxx)
  • 修复开发过程中发现的问题，以develop为基准创建fix分支
  • 分支命令规则：fix/problem,problem 为要修复的问题。
• 紧急修复分支(hotfix/xxx)
  • 当线上出现紧急问题，需要及时修复，以master分支为基线，创建hotfix分支，问题修复完成并验证后，分别合并到master分支和develop分支。
  • 分支命令规则：hotfix/problem,problem 为要修复的问题。

二 提交并合并

• 应对 master 和 develop 分支加锁，不允许直接提交。
• 提交commit时，必须给出完整扼要的提交信息，包括功能及改动原因；问题及注意事项。
• 提交到远程仓库的分支，可在gitlab 上新建 pull request（提交PR时勾选删除原分支）,由持续集成服务和人工 code review 确保代码质量后，相关人员对分支进行合并然后删除该分支。

第二章 版本管理

一 发布流程

• develop 分支切出 release 分支
• release 分支更改版本号并提交
• release 分支合并至master 分支
• master 分支推送至远程仓库
• 在 master 分支上打上版本号(tag),推送至远程仓库

二 紧急修复流程

• 切至出现问题的版本(以1.1.0为例)，切出分支 hotfix/1.1.1。
• 若由一人修复缺陷，则直接在hotfix/1.1.1 分支上提交代码，待所有问题修复完毕且测试通过，将hotfix/1.1.1 合并至master 分支并打上tag推送至远程仓库。
• 若由多人修复缺陷，则每人分别从 hotfix/1.1.1 分支上切出分支提交代码，再合并至hotfix/1.1.1 分支，待所有问题修复完毕且测试通过，将hotfix/1.1.1 合并至master 分支并打上tag推送至远程仓库。
• 将hotfix/1.1.1 合并至develop分支，推送至远程。

第三章 Git命令

• (feature/xxx):提交本地修改暂存

git add -A

• (feature/xxx): 提交至本地分支

git commit -a -m “message”

• (feature/xxx): 合并提交笔数，使用详细参考文章

git rebase -i HEAD~n

• (feature/xxx): 推送至远程仓库分支

git push -f origin feature/xxx