一、git安装及介绍
1.卸载git步骤：
先删除环境变量中与git有关的变量再通过控制面板卸载即可。
2.下载git
官网：git-scm.com/downloads 由于官网下载太慢我通过淘宝的开源镜像下载 网址：npm.taobao.org/mirrors/git…
下载版本根据自己的需求选择即可。
3.安装git
next ->修改安装目录（或默认安装在C:\Program Files\Git）->接下来一直next 直至安装完毕
4.配置git
点击电脑左下角开始即可看见Git Bash
ps:Git CMD 是windows 命令行的指令风格 而Git Bash 是linux系统的指令风格（个人建议使用Git Bash）Git GUI是图形化界面（新手学习不建议使用）
打开Git Bash 后如下图所示即代表安装完成
接下来配置用户名和邮箱（用于git识别你的身份）
git config --global user.name "自己的用户名"
git config --global user.emal "自己的邮箱"
输入后没有报错即代表设置成功
通过git config -l 检查一下是否配置成功 至此git安装及配置全部完成。
补充：
git修改默认编辑器指令：git config –global core.editor vim （编辑器名）
5.连接远程仓库
（展示使用的是gitee码云，其他平台同理）
先生成ssh公钥，打开Git Bash 输入命令 ssh-keygen -t rsa 随后一直空格即可
2，找到图中地址目录 用记事本打开该文件
打开后复制所有内容
然后登录码云 网址：gitee.com/ ——>点击设置
点击左下角SSH公钥
接下来按下图操作，最后看见验证成功弹窗即代表密钥绑定成功
二、git基本使用流程
- 先搭建好远程仓库
- 在本地文件先进行git初始化 使用指令git init
- 添加文件到work tree 使用指令 git add .（符号 “点"代表全部添加）
- 提交文件到本地仓库 使用指令 git commit -m "要提交的信息"
- 查看状态 使用指令 git status
- 提交到远程仓库 使用指令 git push -u origin master
- 在本地文件先进行git初始化 使用指令git init
- 从仓库拉区文件 使用指令 git clone 要克隆的仓库ssh链接
- 拉取更新的代码 使用指令git fetch origin （取回服务器端最新代码）
- 更新代码到本地仓库 使用指令 git pull origin master （表示同步到自己的本地master版本）
//git使用参考文档：git.mydoc.io/?t=180676、
//使用参考图：
三、版本控制规范
1.分支管理
每个项目有两个永久分支和多个临时分支，各个分支介绍如下：
Master 分支
主分支，保存的是最近已发布到生产环境的代码，最近发布的 Release，会使用 tag 来记录发布的版本。master 分支是不允许提交代码的，只能将代码合并到 master。 该分支的代码与代码与生产环境的版本保持一致，只有该项目的 master 管理员有权限处理该分支内容。
注意： 所有向 master 分支的 Push 推送都应当打TAG 标签做记录,方便追溯。
Develop(dev)分支
主开发分支，基于 master 创建，是所有开发分支的母体。 通常情况下，只在 develop 上开发一些基础的代码。而对于一些新的功能，不直接在 develop 上开发，而是在feature 开发，开发完成后合并到 develop 分支。
Release分支【临时分支】
发布分支 基于 develop 创建，用于准备发布新阶段版本。当一次迭代的功能开发并自测完成后，就可以创建发布分支。该分支通常用于测试，我们不能在该分支上完成除 Bug 修复外的其他工作。 Release 分支基于Develop 分支创建，打完Release 分支之后，我们可以在这个Release 分支上测试，修改 Bug 等。 发布 Release 分支时，合并 Release 到 Master 和 Develop， 同时在 Master 分支上打个 Tag 记住 Release 版本号，然后可以删除 Release 分支了。
注意： 一旦打了 Release 分支之后不要从 Develop 分支上合并新的改动到 Release分支。
Hotfix 分支【临时分支】
修复分支，从 master 创建。当我们在生产环境发现 Bug 的时候，会从 master 分支上对应的 tag 处创建新的 hotfix 分支，用来修复 bug。完成 Hotfix 后，合并回 Master 和 Develop 分支，所以 Hotfix 的改动会进入下一个 Release。 合并回 Master 和 Develop 分支后，删除 Hotfix 分支。
注意： 合并完成后，须在Master 上打一个tag。
Feature分支【临时分支】
功能分支，从 develop 创建。主要是用来开发新的功能，开发完成后，会合并回Develop 分支。 Feature 分支做完后，必须合并回 Develop 分支, 合并完分支后删掉这个 Feature 分支。
注意： 上述提到的 Tag，用于记录每次发布的版本，须与应用、产品版本号对应。
2.开发规范
Commit原则
在具体开发工作中主要需要遵守的原则就是使每次提交都有质量，需做到以下几点：
- 提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
- 用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；
- 不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误；
Commit Message 格式
建议参考规范： <type>(scope)：<subject>
实例：fix(首页模块)：修复弹窗 JS Bug。
type 表示 动作类型，可分为：
- fix：修复 xxx Bug
- feat：新增 xxx 功能
- test：调试 xxx 功能
- style：变更 xxx 代码格式或注释
- docs：变更 xxx 文档
- refactor：重构 xxx 功能或方法
- scope 表示 影响范围，可分为：模块、类库、方法等。
subject 表示 简短描述，最好不要超过 50 个字，如果有相关 Bug 的的编号，建议在描述中加上。
3.版本管理
主版本号
使用 1 位数字，当功能模块有较大的变动或子版本号满，即可升级，每次升级主版本号加 1
子版本号
使用 2 位数字，从 0 开始。每个迭代周期为一个版本，版本号依次递增，最大的版本号为 99
维护版本号
使用 2 位数字，从 0 开始。系统上线后，发现缺陷或者有较少改动，则通过维护版本号发布
四、开发场景
接下来举几个开发场景。
开发流程：开发编码->测试发布->功能测试->测试环境功能验收->生产发布->生产环境功能验收
新需求加入
有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？
- 如果 存在 未测试完毕的需求，就基于 master 创建。
- 如果 不存在 未测试完毕的需求，就基于 develop 创建。
需求在 feature-order 分支开发完毕，准备提测时，要先确定 develop 不存在未测试完毕的需求，这时研发人员才能将代码合并到 develop，然后（可选合并到测试分支test-xxx）供测试人员测试。
测试人员在 测试环境 测试通过后，研发人员再将代码发布到 release （UAT）供测试和验收。
在 release （UAT）测试通过后，研发人员再将代码发布到 master （正式环境上线）供测试人员上线测试验证。
在 master (正式环境上线) 验证通过后，研发人员需要删除 feature-order 分支。
普通迭代
有一个订单管理的迭代需求，如果开发工时 < 1d，直接在 develop 开发，如果开发工时 > 1d，那就需要创建分支，在分支上开发。
开发后的提测上线流程 与 新需求加入的流程一致。时间供参考，动态调整
修复测试环境 Bug
在 develop 测试出现了Bug，如果修复工时 < 2h，直接在 develop 修复，如果修复工时 > 2h，需要在分支上修复。
修复后的提测上线流程 与 新需求加入的流程一致。时间供参考，动态调整
修改预上线环境 Bug
在 release 测试出现了Bug，首先要回归下 develop 分支是否同样存在这个问题。
如果存在，修复流程 与 修复测试环境 Bug流程一致。
如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
修改正式环境 Bug
在 master 测试出现了Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。
如果存在，修复流程 与 修复测试环境 Bug流程一致。
如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。
紧急修复正式环境 Bug
需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。
紧急修复的意思是没时间验证测试环境了，但还是建议验证下预上线环境。
如果 release 分支存在未测试完毕的需求，就基于 master 创建 hotfix-xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 release 和 develop 分支，同时删掉 hotfix-xxx 分支。 如果 release 分支不存在未测试完毕的需求，但 develop 分支存在未测试完毕的需求，就基于 release 创建 hotfix-xxx 分支，修复完毕后发布到 release 验证，后面流程与上线流程一致，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix-xxx 分支。 如果 release 和 develop 分支都不存在未测试完毕的需求， 就直接在 develop 分支上修复完毕后，发布到 release 验证，后面流程与上线流程一致。
并行提测
在一个项目中并行开发了两个需求，并行提测，但是上线日期不同。
两种方案：
- 再部署一套可供测试人员测试的分支
- 使用 git cherry-pick “挑拣”提交
