Git使用规范 Android 版

根据 Git 分支管理策略，结合 Git Flow 分支管理实践，以及 Android 实际开发状况，制定了这个适合 App 项目开发的 Git 使用规范 。

1、Git的⼏个理念

1. 分支

Git 的 master 分支并非⼀个特殊分⽀，它与其它分⽀没有任何区别。之因此几乎每⼀个仓库都有 master 分支，是由于 git init 命令默认建立它，而且⼤多数⼈都懒得去改动它。

2. 分支与合并

在 Git 中分支合并是很日常的事情，在开发过程当中要适应常常进行分⽀合并的操做。在Git中，分⽀只是一个指针，并不会进⾏物理拷贝，因此建立分⽀时异常⾼效与易用。

3. 彻底分布式

虽然都有⼀个 Git 服务器，即 origin ，实际上它与每一个开发人员本地仓库是平等的。 origin 主要⽤于永久保存代码，同时也便于开发人员之间协同工做。但从技术上来讲， origin 与开发人员的本地仓库没有什么不一样。

2、Git分支模型

分⽀模型，是对 Git 运用的⼀种约束，适配于团队的⽇常开发、新功能开发、bug修复；经过该模型以建⽴一套⾏之有效的开发、测试及上线发布流程。同时，分支模型约定全部的开发⼈员的操做规范，创建对应的处理流程，使得软件的开发过程更易于管理。

1. master分支

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

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
-	-	develop fix-*	release-* fix-*	-	⽆ Push 权限	生产

2. develop分支

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

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
-	master	feature-* release-*	feature-* release-* fix-*	-	⽆ Push 权限	-

禁⽌将下列分⽀合并入 develop 分支：

• 新功能未完成的 feature 分⽀；
• 测试环境未经过的 release 分支；
• 问题未修复的 fix 分支。

3. feature分⽀

feature 分支，即新功能分支(有时也称之为特性分支)，主要被用于即将开发的或更长期的功能开发。

它有可能被合并到 develop 分支或者被废弃掉。

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
feature-AppVersion feature-AppVersion-DeveloperName	develop	-	-	develop	all	开发

feature 分支的建立规则取决于需求复杂程度和开发人员数量，须要考虑开发效率、冲突出现的频次和解决冲突须要花费的时间和精力。

若是需求相对简单或者开发人员较少，可使用一个分支进行开发，命名规则采用 feature-AppVersion ，示例：feature-1.0.0。

若是需求相对复杂或者开发人员较多，建议每个开发人员一个分支，命名规则采用 feature-AppVersion-DeveloperName，示例：feature-1.0.0-zhangsan。

4. release分⽀

release 分支专供测试使用，容许咱们在发布前，作最后⼀点改动，包括少许BUG的修改、元数据(如版本信息、编译参数等)的修改等。当全部⼯做完成后， develop 分支再将这些修改所有合并回来，开始下⼀个版本的开发⼯做。

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
release-AppVersion	develop	-	-	develop master	Push 权限	测试

命名示例：release-1.0.0。

5. release-fix分⽀

release-fix 分⽀⽤于修复当前 release 分⽀的 bug。

release-fix 分⽀可由某开发人员建立，而且推送到 origin，可由多位开发者共同修复各⾃开发代码产⽣的 bug。每次修复完bug，直接打包给测试，测试经过后，发送 MR 请求到 release 分支。

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
release-fix-AppVersion	release-AppVersion	-	-	release-AppVersion	all	开发/测试

命名示例：release-fix-1.0.0。

6. fix分支

fix分支用于解决生产环境发现的BUG。

当生产环境发现BUG后，基于最新一次发布App的版本号，建立 fix 分支进行BUG修复。

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
fix-AppVersionc	master	-	-	develop	all	测试/生产

规范命名的 count 为该版本发现

7. optimize分支

优化代码分支，若是项目中使用的某个技术已通过时，或者随着技术的提高，感受以前的代码有更好的实现，在时间容许的状况下，能够考虑优化该部分代码。考虑到新代码可能出现BUG，通过严格测试后，才容许合并到 develop 分支，不然仅仅做为我的技术练习。

命名规范	分支来源	分支目标	合并来源	合并目标	权限	应用环境
optimize-content	develop	-	-	develop	all	开发

命名规范中的 content 为准备优化的地方，例如：optimize-layout-layer。

feature 分支 和 optimize 分支区别：feature 分支靠需求驱动，optimize 分 靠技术驱动。

fix 分支 和 optimize 分支区别：fix分支必定会在下一个版本上线，而 optimize 分支不必定在下一个版本上线。

3、Git使用流程

1. 建立项目

1. 在 Gitlab 上建立项目，将项目拉取到本地。

2. 建立如下文件：

   • README.md ：工程说明；
   • CHANGELOG.md：变动说明日志，记录每一个版本作的事情，相似于应用市场上发布的版本说明；
   • .gitignore：配置不须要 Git 进行管理的文件。
3. 将修改提交到远程，这个时候Git 会默认建立 master 分支。
4. 基于 master 分支建立 develop 分支。

2. 新功能开发

1. 基于 develop 分支建立 feature 分支。
2. 按照需求和UI完成开发任务。
3. 联调代码，完成自测。
4. 若是本次开发建立了多个 feature分支，将其合并到一个 feature 分支上，若是只是一个 feature 分支，则不进行操做。
5. 拉取 develop 分支上的代码到 feature 分支，若是存在冲突，解决冲突。
6. 提交 MR 到 develop 分支，MR 经过后删除 feature 分支。

3. 测试新功能

1. 检查 MR 到 develop 上的代码，确认后，赞成 MR。
2. 基于 develop 分支建立 release-version 分支，修改应用 versionCode 和 versionName，更新 CHANGELOG.md 文件中的说明日志。
3. 在 release-version 上打测试环境的安装包，提交给测试人员进行测试。
4. 若是测试人员发现BUG，基于 release 建立 release-fix 分支修复BUG，BUG修复后直接在 release-fix分支打测试环境的安装包，提交给测试人员进行测试。
5. 重复步骤4，直到测试经过。
6. 提交 MR 到 release 分支，MR 经过后删除 release-fix 分支。

4. 发布新版本

1. 基于 release 分支打正式包，提交到应用市场。
2. 提交 MR 到 master 分支，赞成后，在 master 分支上打对应版本的 tag，tag的命名规则为 v + version，示例：v1.0.0。
3. 提交 MR 到 develop 分支，MR 经过后删除 release 分支。

5. 修复线上BUG

1. 基于 master 分支，使用最新一次发布App的版本号，建立 fix 分支进行BUG修复。
2. BUG修复后直接在当前分支打测试环境的安装包，提交给测试人员进行测试。
3. 测试未经过，继续修复。
4. 若是须要当即发版，则基于 fix 分支建立 release 分支，修改应用 versionCode 和 versionName，更新 CHANGELOG.md 文件中的说明日志，删除 fix 分支，剩余步骤参考4. 发布新版本完成发版。

   若是不严重，则提交 MR 到 develop 分支，MR 经过后删除 fix 分支。

6.优化代码

1. 基于 develop 分支，建立 optimize 分支。
2. 完成优化。
3. 测试优化。
4. 提交 MR 到 develop 分支，MR 经过后删除 optimize 分支。

4、提交规范

Git 每次提交代码，都要写 Commit message（提交说明），不然就不容许提交。通常来讲，commit message 应该清晰明了，说明本次提交的目的，包括：代码做用的位置、代码变更的类型、简要描述代码的功能。

变更类型	描述
feat	新功能（feature）
fix	修复bug
docs	文档的变更，注释的变更
style	代码格式的变更，好比：方法顺序、字段顺序、方法命名、字段命名等。
refactor	对已上线代码进行优化，不涉及到需求，只是从技术上去优化代码
test	测试的变更
chore	构建过程、辅助工具、编辑器配置的变更

示例：

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

注意：每次提交代码前，应该先执行 pull 拉取服务器最新代码，防止提交的代码有冲突。

并且若是先建立本地提交，而后在执行更新操做，这样会致使 Git 自动生成一个合并提交，致使提交历史不够简洁。

5、MR使用规范

1. MR使用流程

本示例基于 Gitlab。

1. 建立MR请求

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

2.填写请求内容

注意Title和内容的的填写规范：可参考MR注释规范，确认分支来源、目标分支和委托人不要填写错误。

分支说明：

2. 处理MR请求

Gitlab 会经过邮件通知到委托人，处理 MR。

1.查看 MR 中代码改变了哪些。

2.确认没有问题，经过 MR，合并完成。若是发现有问题，则关闭请求，合并失败，须要请求人修改代码后从新MR.

2. MR注释规范

全部的 MR 请求者，须要详细说明提交注释，以下:

源分支	目标分支	注释Title	Descrition
release	master develop	release-version 测试已经过，提交发布 示例：release-1.0.0 测试已经过，提交发布	-
feature	develop	feature-version 完成全部功能的开发并联调经过，提交测试 示例：feature-1.0.0 完成全部功能的开发并联调经过，提交测试	-
fix	develop（线上Bug下次发版）	fix-version 修复了如下bug并测试经过，提交合并fa'bu 示例：fix-1.0.0 修复了如下bug并测试经过，提交合并	1. bug1 2. bug2 3. bug3
fix	master（线上Bug当即发版）	fix-version 修复了如下bug并测试经过，提交发布 示例：fix-1.0.0 修复了如下bug并测试经过，提交发布	1. bug1 2. bug2 3. bug3
release-fix	release	release-fix-version 修复了如下bug并测试经过，提交发布 示例：release-fix-1.0.0 修复了如下bug并测试经过，提交发布	1. bug1 2. bug2 3. bug3

6、代码评审

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

考虑到开发时间，MR时须要作简易 Code Review，项目发布后作详细 Code Review，若是须要调整代码，新建优化分支进行调整，具体流程参考优化代码

7、经常使用Git命令示例

1. 建立分支

这里以在本地建立 feature 分支举例，其余分支建立须要注意是基于哪一个分支建立，同事还须要注意分支命名规则。

// 切换到 develop 分支
git checkout develop

// 基于 develop 分支建立 feature 分支
git checkout -b feature-1.0.0 

// 将 feature 分支推送到远程
git push origin feature-1.0.0:feature-1.0.0

// 设置本地 feature 分支关联远程 feature 分支
git branch --set-upstream-to=origin/feature-1.0.0 feature-1.0.0

2. 删除分支

// 删除本地分支
// 通常删除，若是分支上的代码没有合并，会失败
git branch -d feature-1.0.0 
// 强制删除
git branch -D feature-1.0.0 

// 删除远程分支
git push origin --delete feature-1.0.0
// or
git push orgin :feature-1.0.0 //（origin 和冒号之间是有空格的）

3. 更新代码

git pull --no-rebase

4. 添加Tag

// tag 通常在 master 分支添加，因此先切换到 master 分支
git checkout master
// 添加 tag
git tag -a v1.0.0 -m 'tag描述，通常来讲就是一句话描述新增代码的功能'

8、注意事项

1. 避免代码冲突

为了尽可能避免冲突发生，养成以下开发习惯：

• 编码前先更新
• 提交前先更新
• 修改了公共文件，尽早通知其余成员更新
• 须要提交 MR 到目标分支，先将目标分支的代码拉到当前分支，若是有冲突，先解决冲突再 MR，没有冲突则直接提交MR。
• 最后一条，也是最重要的，团队分工要明确

2. 更新代码使用Merge而不是Rebase

这里不使用 rebase，缘由是会把当前分支的 commit 放到公共分支的最后面，因此叫变基。就好像你从公共分支又从新拉出来这个分支同样，改变了commit 的实际提交顺序，这样其余从这个公共分支拉出去的人，都须要再 rebase。

1. 使用命令行更新代码

git pull --no-rebase

2. 使用Android Studio更新代码

按下图配置更新选项：

补充：

Update Type 类型：

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

写在最后
这个版本是团队最终统一规范时进行了精简后造成的版本，初始版本中总结了更详细的用法及注意事项，具体请：点击前往