Git分支说明

  1. master分支git默认分支，主分支，不轻易改动，代码为生产环境的最新发布版本。在新版本发布后，需要将新版本代码合并到该分支，并在改分支上打tag。 | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | - | - | developfix- | release-fix-* | - | ⽆ Push 权限 | 生产 |

  2. develop分支是开发人员使用的主要分支，以master为分支来源。其最新代码代表着开发人员为下一个发布版本提交的最新代码。不能代表最新的特性代码，也不代表正在发布的版本代码。禁止将下列分支合并到develop分支： | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | - | master | feature-release- | feature-release-fix-* | - | ⽆ Push 权限 | - |

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

  3. feature分支feature分支，新功能分支，主要用于即将开放的或周期更长期的功能分支。有可能合并到develop分支或者废弃掉。feature分支的创建规则取决于需求复杂程度和开发人员数量，需要考虑开发效率、冲突出现的频次和解决冲突需要花费的时间和精力。如果开发人员较少，可以使用一个分支进行开发，命名规则采用feature-appversion，示例：feature-1.0.0;如果开发人员较多，需求相对复杂，可以每个开发人员一个分支，命名规则feature-appversion-name，示例：feature-1.0.0-lss;如果需求特别多而复杂，可以每个需求一个分支，命名规则feature-appversion-function，示例：feature-1.0.0-ble。 | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | feature-AppVersionfeature-AppVersion-DeveloperName | develop | - | - | develop | all | 开发 |

  4. release分支release分支专供测试使用，允许发布前，做最后一点改动（修改bug，版本信息等）。测试通过验证后，再合并到develop分支，开始下一个版本的开发工作。命名示例：release-1.0.0 | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | release-AppVersion | develop | - | - | develop master | Push 权限 | 测试 |

  5. release-fix分支release-fix分支主要是用来修复当前release分支的bug。release-fix分支可以由开发人员创建，并且推送到origin，可由多位开发者共同修复各自开发代码产生的bug。每次修复完bug，直接打包给测试，测试通过后，发送MR请求到release分支。命名示例：release-fix-1.0.0。 | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | release-fix-AppVersion | release-AppVersion | - | - | release-AppVersion | all | 开发/测试 |

  6. fix分支fix分支用于解决生产环境发现的BUG。当生产环境发现BUG后，基于最新一次发布App的版本号，创建 fix 分支进行BUG修复。规范命名的 count 为该版本 | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | fix-AppVersionc | master | - | - | develop | all | 测试/生产 |

  7. optimize分支优化代码分支，如果项目中使用的某个技术已经过时，或者随着技术的提升，感觉之前的代码有更好的实现，在时间允许的情况下，可以考虑优化该部分代码。也可以将一些公共的工具类，公共使用的代码放到这个分支。考虑到新代码可能出现BUG，经过严格测试后，才允许合并到 develop 分支，否则仅仅作为个人技术练习。命名规范中的 content 为准备优化的地方，例如：optimize-layout-layer。feature 分支 和 optimize 分支区别：feature 分支靠需求驱动，optimize 分 靠技术驱动。fix 分支 和 optimize 分支区别：fix分支一定会在下一个版本上线，而 optimize 分支不一定在下一个版本上线。 | 命名规范 | 分支来源 | 分支目标 | 合并来源 | 合并目标 | 权限 | 应用环境 | | —- | —- | —- | —- | —- | —- | —- | | optimize-content | develop | - | - | develop | all | 开发 |

Git使用流程

1.创建项目

  1. 在 Gitlab 上创建项目，将项目拉取到本地。
  2. 创建以下文件：
    • README.md ：工程说明；
    • CHANGELOG.md：变更说明日志，记录每个版本做的事情，类似于应用市场上发布的版本说明；
    • .gitignore：配置不需要 Git 进行管理的文件。
  3. 将修改提交到远程，这个时候Git 会默认创建 master 分支。

  4. 基于 master 分支创建 develop 分支。

    2.新功能开发

  5. 基于 develop 分支创建 feature 分支。

  6. 按照需求和UI完成开发任务。
  7. 联调代码，完成自测。
  8. 如果本次开发创建了多个 feature分支，将其合并到一个 feature 分支上，如果只是一个 feature 分支，则不进行操作。
  9. 拉取 develop 分支上的代码到 feature 分支，如果存在冲突，解决冲突。

  10. 提交 MR 到 develop 分支，MR 通过后删除 feature 分支。

    3.测试新功能

  11. 检查 MR 到 develop 上的代码，确认后，同意 MR。

  12. 基于 develop 分支创建 release-version 分支，修改应用 versionCode 和 versionName，更新 CHANGELOG.md 文件中的说明日志。
  13. 在 release-version 上打测试环境的安装包，提交给测试人员进行测试。
  14. 如果测试人员发现BUG，基于 release 创建 release-fix 分支修复BUG，BUG修复后直接在 release-fix分支打测试环境的安装包，提交给测试人员进行测试。
  15. 重复步骤4，直到测试通过。

  16. 提交 MR 到 release 分支，MR 通过后删除 release-fix 分支。

    4.发布新版本

  17. 基于 release 分支打正式包，提交到应用市场。

  18. 提交 MR 到 master 分支，同意后，在 master 分支上打对应版本的 tag，tag的命名规则为 v + version，示例：v1.0.0。

  19. 提交 MR 到 develop 分支，MR 通过后删除 release 分支。

    5.修复线上BUG

  20. 基于 master 分支，使用最新一次发布App的版本号，创建 fix 分支进行BUG修复。

  21. BUG修复后直接在当前分支打测试环境的安装包，提交给测试人员进行测试。
  22. 测试未通过，继续修复。

  23. 如果需要立即发版，则基于 fix 分支创建 release 分支，修改应用 versionCode 和 versionName，更新 CHANGELOG.md 文件中的说明日志，删除 fix 分支，剩余步骤参考\4. 发布新版本完成发版。如果不严重，则提交 MR 到 develop 分支，MR 通过后删除 fix 分支。

    6.优化代码

  24. 基于 develop 分支，创建 optimize 分支。

  25. 完成优化。
  26. 测试优化。
  27. 提交 MR 到 develop 分支，MR 通过后删除 optimize 分支。

    提交规范

    Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。一般来说，commit message 应该清晰明了，说明本次提交的目的，包括：代码作用的位置、代码变动的类型、简要描述代码的功能。
变动类型 描述
feat 新功能（feature）
fix 修复bug
docs 文档的变动，注释的变动
style 代码格式的变动，比如：方法顺序、字段顺序、方法命名、字段命名等。
refactor 对已上线代码进行优化，不涉及到需求，只是从技术上去优化代码
test 测试的变动
chore 构建过程、辅助工具、编辑器配置的变动

示例：
fix(首页)：修复缓存异常
feat(用户)：新增修改用户头像的功能
注意：每次提交代码前，应该先执行 pull 拉取服务器最新代码，防止提交的代码有冲突。
而且如果先创建本地提交，然后在执行更新操作，这样会导致 Git 自动生成一个合并提交，导致提交历史不够简洁。

常用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描述，一般来说就是一句话描述新增代码的功能’

MR使用规范

MR使用流程，本示例基于 Gitlab。

1. 创建MR请求

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

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

分支说明：

2. 处理MR请求

Gitlab 会通过邮件通知到委托人，处理 MR。
1.查看 MR 中代码改变了哪些。

2.确认没有问题，通过 MR，合并完成。如果发现有问题，则关闭请求，合并失败，需要请求人修改代码后重新MR.

3. MR注释规范

所有的 MR 请求者，需要详细说明提交注释，如下:

源分支 目标分支 注释Title Descrition
release masterdevelop 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

代码评审

在两个及两个以上开发人员的项目中，应该进行代码评审，检查代码风格和是否有潜在的BUG。
考虑到开发时间，MR时需要做简易 Code Review，项目发布后做详细 Code Review，如果需要调整代码，新建优化分支进行调整，具体流程参考优化代码

注意事项

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文件中指定不同分支的更新类型。


参考

Git使用规范 Android 版
Android开发规范：Git版本管理规范
Android团队项目开发之统一代码规范
Android - 代码管理