1.GIT Flow流程图

在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。
Git版本管理同样需要一个清晰的流程和规范。
Vincent Driessen 为了解决这个问题提出了GIT FLow
以下是基于Vincent Driessen提出的Git Flow 流程图

GIT Flow时间流程图.png

2.Git的分支简介

下面分支中提到的version应该替换为具体的版本，name应该替换为具体的开发人员姓名，content应该替换为需要优化的地方

2.1master分支

git的默认分支，主分支，一般不会轻易改动，上面的代码为生产环境的最新发布版本。在新版本发布后，将新版本代码合并到该分支，并在该分支上打tag标签,这个分支只能从其他分支合并，不能在这个分支直接修改

分支来源	命名规则	命名示例	合并目标	应用环境
-	-	-	-	生产

2.2develop分支

通常创建git项⽬目的同时就创建 develop ，是开发人员⽤的主要分支，以 master 为分⽀来源。其最新代码代表着开发⼈员为下一个发布版本提交的最新代码。不能代表最新的特性代码，也不代表正在发布的版本代码。

Develop.png

分支来源	命名规则	命名示例	合并目标	应用环境
master	-	-	release-version	开发

2.3feature分⽀

feature 分支，即新功能分支(有时也称之为特性分支)，主要被用于即将开发的或更长期的功 能开发。它有可能被合并到 develop 分支或者被废弃掉。

feature.png

分支来源	命名规则	命名示例	合并目标	应用环境
develop	feature-version	feature-1.0.0	develop	开发

2.4release分⽀

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支,release 分支专供测试使用，允许我们在发布前，做最后⼀点点改动，比如元数据(如版本信息、编译参数等)的修改等。

image.png

分支来源	命名规则	命名示例	合并目标	应用环境
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版中为了区分热修复而重命名。

Hotfix.png

分支来源	命名规则	命名示例	合并目标	应用环境
master	fix-version	fix-1.0.0	release	测试

2.7 refactor(feature)

refactor分支用户重构和优化代码，区别于修改 fix 分支，refactor分支不一定会在下一个版本中上线，而 fix分支一定会在下一个版本中上线。

分支来源	命名规则	命名示例	合并目标	应用环境
develop	refactor-content	refactor-layout	develop	开发

3.使用示例

市面上的公司基本上都是使用给流程，只不过命名方式上有可能不同

使用示例图.png

4.创建项目的经过

创建 master 分支，然后基于 master 创建出 develop 分支。

4.1新功能开发

1. 基于 develop 分支，创建 feature-version 分支，如果开发人员少，可以都在 feature-version分支上进行开发。如果开发人员比较多，基于feature-version 分支继续创建每个人的单独开发分支，命名如 feature-version-name。
2. 完成开发。
3. 联调代码，完成自测。
4. 如果有多个 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测试新功能

1. 检查 MR 到 develop 上的代码，确认后，同意 MR。
2. 在 develop 分支上创建 release-version 。
3. 检查 MR 到 release-version 上的代码，确认后，同意 MR，修改应用 versionCode 和 versionName，在 release-version 上打测试环境的安装包，提交给测试人员进行测试。
4. 如果测试人员发现BUG，基于 release-version 分支创建 release-fix-version分支，修复BUG，修复完成后，提交MR 到 release-version，删除 release-fix-version分支。
5. 重复进行步骤3、4，直到测试通过。

4.3发布新功能

1. 基于 release-version 分支打正式包，提交到应用市场。
2. 提交 MR 到 master 分支，同意后，在 master 分支上打 对应版本的 tag。
3. 提交 MR 到 develop 分支。
4. 删除 release-version 分支。

4.4修复线上BUG

1. 定位到 BUG 产生的地方，基于 master 分支 创建 fix-version 分支修复 BUG，这里的 version 为 BUG 产生的分支。
2. 修复完成后，提交 MR 到 release-version 上。
3. 检查 MR 到 release-version 上的代码，确认后，同意 MR，在 release-version 上打测试环境的安装包，提交给测试人员进行测试。
4. 如果测试人员发现BUG，基于 release-version 分支创建 release-fix-version分支，修复BUG，修复完成后，提交MR 到 release-version，删除 release-fix-version分支。
5. 重复进行步骤3、4，直到测试通过。
6. 如果 BUG 十分严重，需要马上发版，则修改应用 versionCode 和 versionName，剩下操作参照[11.3.4 发布新功能)](#11.3.4 发布新功能)。如果不严重，则提交 MR 到 develop 分支。

4.5重构代码

1. 基于 develop 分支，创建 refactor-content 分支。
2. 完成优化。
3. 测试优化。
4. 提交 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中的具体代码改变了哪些。

在这里插入图片描述

注意写明请求内容，分支来源和目标分支。最后“提交”。到此，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