Git 使用规范 (Android 版)

Posted 小羊子说

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Git 使用规范 (Android 版)相关的知识，希望对你有一定的参考价值。

引言

本文根据Git分支管理策略，结合Git Flow分支管理实践，制定了这个适合android开发中的Git版本管理规范。同时结合实际操作演示了使用示例，希望对你有所帮助。

文章目录

1. 各分支简介

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

master分支

git的默认分⽀，主分支，不轻易改动，上面的代码为生产环境的最新发布版本。在新版本发布后，将新版本代码合并到该分支，并在该分支上打 tag 标签。

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

develop分支

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

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

feature分⽀

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

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

release分⽀

release 分支专供测试使用，允许我们在发布前，做最后⼀点点改动，比如元数据(如版本信息、编译参数等)的修改等。

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

release-fix分⽀

release-fix分支用于解决测试人员对release代码分支提出的BUG。

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

fix分支

fix分支用于解决生产环境发现的BUG。标准的该分支一般命名为hotfixes,Android版中为了区分热修复而重命名。

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

refactor分支

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

分支来源命名规则命名示例合并目标应用环境
developrefactor-contentrefactor-layoutdevelop开发

各分支关系图

以经典的Git 流程图为例，适用于所有开发。

2. 提交规范

feat： 新功能（feature）

fix： 修复bug

docs： 文档（documentation）

style： 格式（不影响代运行的变动）

refactor： 重构（既不是新增功能，也不是修改bug的变动）

test： 增加测试

chore： 构建过程、辅助工具、编辑器配置的变动

示例：

fix(首页)：修复缓存异常
feat(用户)：新增修改用户头像的功能

3. 使用示例

根据需要整理了一个适用于Android团队的Git流程图，如下图所示：

3.1 创建项目

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

3.2 新功能开发

  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中操作。

3.3 测试新功能

  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，直到测试通过。

3.4 发布新功能

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

3.5 修复线上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 分支。

3.6重构代码

  1. 基于 develop 分支，创建 refactor-content 分支。
  2. 完成优化。
  3. 测试优化。
  4. 提交 MR 到 develop 分支。

4. 代码评审

在两个及两个以上开发人员的项目中，应该进行代码评审，检查代码风格和是否有潜在的BUG。

MR时需要做简易Code Review,项目发布后做详细Code Review 之后在重构分支上合并,此分支测试后手于Master合并，测试风险控制)

5.Android studio提交规范

git commit --amend  //提交后会与最后一次提交进行合并生成一个新的提交，之前的提交会被废弃掉。

修改的文件已被git commit，但想再次修改不再产生新的Commit.

git commit --amend -m"说明"

目的：如果你仍然有文件没有提交，想追加到最后这个commit上的话，用上述命令，可以保持commit提交历史的干净性。

扩展：合并 commit 保持分支干净整洁

Android Studio中 在更新代码（pull）时，

  • Update type:
    • Merge：更新时执行合并操作。等价于执行git fetch && git merge或者git pull --no-rebase。
    • Rebase：更新时执行rebase操作。等价于执行git fetch && git rebase或者git pull --rebase。
    • Branch Default：在.git/config文件中指定不同分支的更新类型。

注：不能选择"Rebase",只能选择 “Merge”或Branch Default。因为Rebase(变基)除了了给你带来看上去简洁的历史记录，只会让你的⼯工作变得更更加困难且更更容易易犯错，因为它会擦掉分⽀支的提交历史，并且提交记录并⾮非按时间有序显示。

  • clean working tree before update: 选择默认选项：Using Stash
    • Using Stash：使用git stash储藏本地修改。
    • Using Shelve：使用IDEA内置的Shelve功能储藏本地修改。

通常选择Merge和Using Stash即可，单击OK后，IDEA执行步骤如下：

  • 第1步：使用git stash储藏本地修改

  • 第2步：执行git fetch && git merge拉取远程分支并合并

  • 第3步：执行git stash pop恢复储藏

代码更新及提交规范小结：先执行Pull拉取服务器最新代码，更新时选择“Merge”和“Using Stash”,最后Commit和push到相应分支。

如果先创建本地提交，然后在执行更新操作，这样会导致Git自动生成一个合并提交，导致提交历史不够简洁。

6.主库权限管理

项目权限分配：

  • Owner：拥有主库的所有权限。

  • Committer：具有将开发人员的合并请求（MR）合入主库的权限。基于安全考虑，我们设置为只能通过MR的方式将代码合入主库，而不能直接push到主库。

  • Developer：只能从自己的个人代码库（服务端）提交合并代码的请求（MR），是否能够合入，由Committer进行审核。

7.git分支管理中用到的命令汇总

预发布分支

  • 创建一个功能分支(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的迭代开发工作。

  1. 创建 master 分支，然后基于 master 创建出 develop 分支。(此处操作往往在上一次开发结束后就已完成)

  2. 基于 develop 分支，创建 feature-1.8.0（迭代版本号）迭代开发分支

    git checkout -b feature-1.8.0

  3. 创建好后 立即push到服务器。

    如果没有push前，pull(更新)会失败，因为无法追踪当前分支，当前分支不在远程服务器上。

pull失败时会出现：

push成功时会出现：

  1. 在gitlab中查看当前分支是否存在。


或者用命令直接查看


OK. 开始开发功能。

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

或者在Android stuio中直接操作：步骤如下：

此时会出现和develop不同的分支 如果没有需要合并的代码或已合并，列表中就不会再出现分支。

注意，合并操作需要在GitLab中进行，

注意，默认策略为"recursive"

如果没有设置合并权限，会合并成功。如果 设置了合并权限,只能完成本地的合并，push时会失败，需要在Gitlab中去创建合并请求 MR。相应的人员审核后，代码才能合并成功。

9.3.2 方式二：有权限设置

团队开发按照流程规范我们统一采用方式二。

权限设置如下所示，可以设置各个分支的权限。

此处的设置一般会放在Git流程规范形成后，开发迭代任务前完成。开发过程中检查一次即可。

创建MR步骤

1.在项目的仓库主页中找到Create Merge request

2.填写请求内容

注意Title和内容的的填写规范：可参考《MR注释规范》


查看MR中的具体代码改变了哪些。

注意写明请求内容，分支来源和目标分支。最后“提交”。到此，MR完成。

3.处理MR

紧接着，会邮件通知委托人，进行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的使用规范在项目开发至关重要，文中的使用示例 是在项目中的实际操作总结。以上，供你参考。

以上版本是初始版本，后来在团队中最终统一规范时进行了精简，具体可以查看：点击前往

扩展阅读： Android开发代码规范总结

Android之路路漫漫，欢迎关注我的github.
（Android开发知识库汇总，专注性能和架构设计）

以上是关于Git 使用规范 (Android 版)的主要内容，如果未能解决你的问题，请参考以下文章

git 提交规范

Git Commit Log提交规范

GIT 简单版

Git使用

Git 分支模型与开发规范

Android开发规范和接口规范