1.GIT Flow流程图
在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。
Git版本管理同样需要一个清晰的流程和规范。
Vincent Driessen 为了解决这个问题提出了GIT FLow
以下是基于Vincent Driessen提出的Git Flow 流程图
2.Git的分支简介
下面分支中提到的version应该替换为具体的版本，name应该替换为具体的开发人员姓名，content应该替换为需要优化的地方
2.1master分支
git的默认分支，主分支，一般不会轻易改动，上面的代码为生产环境的最新发布版本。在新版本发布后，将新版本代码合并到该分支，并在该分支上打tag标签,这个分支只能从其他分支合并，不能在这个分支直接修改
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| - | - | - | - | 生产 |
2.2develop分支
通常创建git项⽬目的同时就创建 develop ，是开发人员⽤的主要分支，以 master 为分⽀来源。其最新代码代表着开发⼈员为下一个发布版本提交的最新代码。不能代表最新的特性代码，也不代表正在发布的版本代码。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| master | - | - | release-version | 开发 |
2.3feature分⽀
feature 分支，即新功能分支(有时也称之为特性分支)，主要被用于即将开发的或更长期的功 能开发。它有可能被合并到 develop 分支或者被废弃掉。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| develop | feature-version | feature-1.0.0 | develop | 开发 |
2.4release分⽀
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支,release 分支专供测试使用，允许我们在发布前，做最后⼀点点改动，比如元数据(如版本信息、编译参数等)的修改等。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| develop release-fix-versionfix-version | release-version | release-1.0.0 | develop master | 测试 |
2.5release-fix分⽀
release-fix分支用于解决测试人员对release代码分支提出的BUG。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| release | release-fix-version | release-fix-1.0.0 | release | 测试 |
2.6Hotfix分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
fix分支用于解决生产环境发现的BUG。标准的该分支一般命名为hotfixes,Android版中为了区分热修复而重命名。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| master | fix-version | fix-1.0.0 | release | 测试 |
2.7 refactor(feature)
refactor分支用户重构和优化代码，区别于修改 fix 分支，refactor分支不一定会在下一个版本中上线，而 fix分支一定会在下一个版本中上线。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| develop | refactor-content | refactor-layout | develop | 开发 |
3.使用示例
市面上的公司基本上都是使用给流程，只不过命名方式上有可能不同
4.创建项目的经过
创建 master 分支，然后基于 master 创建出 develop 分支。
4.1新功能开发
- 基于 develop 分支，创建 feature-version 分支，如果开发人员少，可以都在 feature-version分支上进行开发。如果开发人员比较多，基于feature-version 分支继续创建每个人的单独开发分支，命名如 feature-version-name。
- 完成开发。
- 联调代码，完成自测。
- 如果有多个 feature 分支，将其全部合并到 feature 分支，然后拉取 develop 分支的代码到 feature分支，解决可能存在的冲突，然后提交 MR 到 develop 分支，删除 feature 分支。剩下操作参照[11.3.3 测试新功能)](#11.3.3 测试新功能)。
补充说明：feature-version 分支上开发时 在单独的开发分支上可以commit和push代码进行同步代码，只是在该迭代开发完成后才进行合并代码(MR)到develop,此时没有push权限,只能请求合并权限(MR)，MR在gitlab中操作。
4.2测试新功能
- 检查 MR 到 develop 上的代码，确认后，同意 MR。
- 在 develop 分支上创建 release-version 。
- 检查 MR 到 release-version 上的代码，确认后，同意 MR，修改应用 versionCode 和 versionName，在 release-version 上打测试环境的安装包，提交给测试人员进行测试。
- 如果测试人员发现BUG，基于 release-version 分支创建 release-fix-version分支，修复BUG，修复完成后，提交MR 到 release-version，删除 release-fix-version分支。
- 重复进行步骤3、4，直到测试通过。
4.3发布新功能
- 基于 release-version 分支打正式包，提交到应用市场。
- 提交 MR 到 master 分支，同意后，在 master 分支上打 对应版本的 tag。
- 提交 MR 到 develop 分支。
- 删除 release-version 分支。
4.4修复线上BUG
- 定位到 BUG 产生的地方，基于 master 分支 创建 fix-version 分支修复 BUG，这里的 version 为 BUG 产生的分支。
- 修复完成后，提交 MR 到 release-version 上。
- 检查 MR 到 release-version 上的代码，确认后，同意 MR，在 release-version 上打测试环境的安装包，提交给测试人员进行测试。
- 如果测试人员发现BUG，基于 release-version 分支创建 release-fix-version分支，修复BUG，修复完成后，提交MR 到 release-version，删除 release-fix-version分支。
- 重复进行步骤3、4，直到测试通过。
- 如果 BUG 十分严重，需要马上发版，则修改应用 versionCode 和 versionName，剩下操作参照[11.3.4 发布新功能)](#11.3.4 发布新功能)。如果不严重，则提交 MR 到 develop 分支。
4.5重构代码
- 基于 develop 分支，创建 refactor-content 分支。
- 完成优化。
- 测试优化。
- 提交 MR 到 develop 分支。
5.代码评审
在两个及两个以上开发人员的项目中，应该进行代码评审，检查代码风格和是否有潜在的BUG。
MR时需要做简易Code Review,项目发布后做详细Code Review 之后在重构分支上合并,此分支测试后手于Master合并，测试风险控制)
6.Android studio提交规范
git commit --amend //提交后会与最后一次提交进行合并生成一个新的提交，之前的提交会被废弃掉。
修改的文件已被git commit，但想再次修改不再产生新的Commit.
git commit --amend -m"说明"
目的：如果你仍然有文件没有提交，想追加到最后这个commit上的话，用上述命令，可以保持commit提交历史的干净性。
代码更新及提交规范小结：先执行Pull拉取服务器最新代码，更新时选择“Merge”和“Using Stash”,最后Commit和push到相应分支。
如果先创建本地提交，然后在执行更新操作，这样会导致Git自动生成一个合并提交，导致提交历史不够简洁。
扩展合并 commit 保持分支干净整洁
7主库权限管理
项目权限分配：
Owner：拥有主库的所有权限。
Committer：具有将开发人员的合并请求（MR）合入主库的权限。基于安全考虑，我们设置为只能通过MR的方式将代码合入主库，而不能直接push到主库。
Developer：只能从自己的个人代码库（服务端）提交合并代码的请求（MR），是否能够合入，由Committer进行审核。
7.1git分支管理中用到的命令汇总
预发布分支
- 创建一个功能分支(
feature-x)并切换到当前分支：
git chechout -b feature-x (develop)
- 开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x
//注意：切换分支前 记得先缓存 stash
- 删除feature分支：
//删除本地分支
git branch -d feature-x //如果分支上的代码没有合并，会失败
git branch -D feature-x //强制删除
//删除远程分支
git push origin --delete feature-x
//or
git push orgin :feature-x （origin有空格）
//查看remote地址，远程分支，还有本地分支与之相对应关系等信息
git remote show origin
//在本地删除远程不存在的分支
git remote prune origin
注：删除前 本地分支不能是即将要删除的分支 ,需要先切换到不同分支后再删除其他分支，不能当前分支删除所在的分支。
- 创建一个预发布分支(
release-1.x)：
git checkout -b release-1.x develop
- 确认没有问题后，合并master分支：
git checkout master
git merge --no-ff release-1.x
- 对合并生成的新节点，做一个标签
git tag -a V1.x -m "标签说明"
- 再合并到develop分支：
git checkout deveop
git merge --no-ff release-1.x
- 最后，删除预发布分支：
git branch -d release-1.x
修复分支
- 创建一个修补bug分支：
git checkout -b fix-0.1 master
- 修补结束后，合并到master分支：
git checkout master
git merge --no-ff fix-2.x
git tag -a 2.x
再合并到develop分支
git checkout develop
git merge --no-ff -fix-2.x
最后删除 修补bug 分支
git branch -d fix-2.x
其他：如本地缓存策略、回滚（慎用）等等。
//存储你的工作区间
git stash
//查看存储列表
git stash list
//应用相应的缓存列表
git stash apply --index
8.避免代码冲突Tips
为了尽量避免冲突发生，养成如下开发习惯：
- 编码前先更新
- 提交前先更新
- 提交前检查是否有编译错误
- 提交粒度尽可能小，描述尽可能准确
- 修改了公共文件，尽早通知其他成员更新
- 最后一条，也是最重要的，团队分工要明确
9.Andorid迭代开发中git使用示例
9.1 准备开始
应用场景示例：下面即将开始版本号1.8.0的迭代开发工作。
创建 master 分支，然后基于 master 创建出 develop 分支。(此处操作往往在上一次开发结束后就已完成)
基于 develop 分支，创建 feature-1.8.0（迭代版本号）迭代开发分支
git checkout -b feature-1.8.0
创建好后 立即push到服务器。
如果没有push前，pull(更新)会失败，因为无法追踪当前分支，当前分支不在远程服务器上。
无论push成功还是失败，都会出现提示
9.2开发中
小组成员之间都有该分支 的pull和push权限。开发中按照Git提交规范和Android studio提交规范执行。
git提交命令分类如下：
feat： 新功能（feature）
fix： 修复bug
docs： 文档（documentation）
style： 格式（不影响代运行的变动）
refactor： 重构（既不是新增功能，也不是修改bug的变动）
test： 增加测试
chore： 构建过程、辅助工具、编辑器配置的变动
操作提示：
fix(首页)：修复缓存异常
feat(用户)：新增修改用户头像的功能
9.3 开发完成
准备提交测试。开发完成后，将功能分支合并到develop分支。
目的：将当前的开发分支（如feature-1.8.0）合并到develop分支
操作方法：在GitLab主页中去操作，创建合并请求（MR），操作步骤见下文。
权限管理： 涉及到安全、权限、流程规范等因素，不能直接用git命令合并。所以需要在GitLab中去MR。
下面介绍常用的两种代码合并方式。
9.3.1 方式一：无权限设置
如果不涉及到权限、审核等安全因素，可以直接用以下操作用命令或Android stutdio上操作。
git checkout develop
git merge --no-ff feature-x
9.3.2 方式二：有权限设置
团队开发按照流程规范我们统一采用方式二。
权限设置如下所示，可以设置各个分支的权限。
此处的设置一般会放在Git流程规范形成后，开发迭代任务前完成。开发过程中检查一次即可。
创建MR步骤
1.在项目的仓库主页中找到Create Merge request
2.填写请求内容
注意Title和内容的的填写规范：可参考《MR注释规范》
查看MR中的具体代码改变了哪些。
注意写明请求内容，分支来源和目标分支。最后“提交”。到此，MR完成。
3.处理MR(Merge Requests)
紧接着，会邮件通知委托人，进行MR处理，确认没有问题时，会通过，合并完成。如果发现有问题，则关闭请求，合并失败，需要请求人修改代码后重新MR.
回到Android studio中，查看git log操作记录。可以发现已经合并完成。此时develop上已经合并了feature-1.8.0的最新代码。
OK,开始打包预发布测试版本。
9.4 预发布
由于此前的迭代开发分支feature-1.8.0的代码已合并到develop上。现在develop创建 release-1.8.0 。
git切换到release-1.8.0打测试环境的安装包给测试。
操作示例：
1.创建release-1.8.0 并切换到当前分支
git checkout -b release-1.8.0
2.打包（测试环境）（打包命令需要在build.gradle中配置）
Mac环境：./gradlew clean resguardCtest
Windows环境：gradlew clean resguardCtest
9.5 Bug修复
测试反馈难免会有bug或细节调整，此时需要创建修复分支，方法如下：
1.基于release-1.8.0创建 release-fix-1.8.0_1 同时记录修复次数。注：最后一位数字表示修复次数。
git checkout -b release-fix-1.8.0_1
2.修复完成后，提交MR到release-1.8.0,在提交MR时删除release-fix-1.8.0_1。同时在release-1.8.0打包测试。在当前分支打包 流程细节参考预发布流程。
3.重复进行步骤1、2，直到测试通过。
小结： 实际开发中，可以根据实际需要减少重复的开发分支的合并和建立，注意在git上记录操作节点，方便后期查询追踪。
9.6 发布App
最后一次给测试的包测试环境通过后，需要打正式环境的包，提交应用市场。
操作示例：
1.切换到发布分支release-1.8.0
git checkout release-1.8.0
2.打包（正式环境）
Mac环境：./gradlew clean resguardRelease
Windows环境：gradlew clean resguardRelease
打包成功后，生成的母包 用python命令打包成对应App市场的渠道包，准备进行分发，上传应用市场。
3.代码合并、tag管理、删除多余分支
提交 MR 到 master 分支，同意后，在
master分支上打 对应版本的tag(v1.8.0)。提交 MR 到
develop分支。删除
release-1.8.0分支。 最后git上只有master、develop分支和tag历史版本记录。
至此，当前迭代开发工作结束。开始准备创建分支重构代码、线上bug修复等等。
总结： git的使用规范在项目开发至关重要，文中的使用示例 是在项目中的实际操作总结。以上，供你参考。
https://blog.csdn.net/jun5753/article/details/97135871