版权声明：本文为CSDN博主「小羊子说」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接
本文根据Git分支管理策略，结合Git Flow分支管理实践，制定了这个适合Android开发中的Git版本管理规范。同时结合实际操作演示了使用示例，希望对你有所帮助。
各分支简介
下面分支中提到的的 version 应该替换为具体的版本，name 应该替换为具体的开发人员姓名， content 应该替换为需要优化的地方。
master分支
git的默认分⽀，主分支，不轻易改动，上面的代码为生产环境的最新发布版本。在新版本发布后，将新版本代码合并到该分支，并在该分支上打 tag 标签。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| - | - | - | - | 生产 |
develop分支
通常创建git项⽬目的同时就创建 develop ，是开发人员⽤的主要分支，以 master 为分⽀来源。其最新代码代表着开发⼈员为下一个发布版本提交的最新代码。不能代表最新的特性代码，也不代表正在发布的版本代码。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| master | - | - | release-version | 开发 |
feature分⽀
feature 分支，即新功能分支(有时也称之为特性分支)，主要被用于即将开发的或更长期的功 能开发。它有可能被合并到 develop 分支或者被废弃掉。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| develop | feature-version | feature-1.0.0 | develop | 开发 |
release分⽀
release 分支专供测试使用，允许我们在发布前，做最后⼀点点改动，比如元数据(如版本信息、编译参数等)的修改等。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| develop 、 release-fix-version、 fix-version | release-version | release-1.0.0 | develop 、master | 测试 |
release-fix分⽀
release-fix分支用于解决测试人员对release代码分支提出的BUG。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| release | release-fix-version | release-fix-1.0.0 | release | 测试 |
fix分支
fix分支用于解决生产环境发现的BUG。标准的该分支一般命名为hotfixes,Android版中为了区分热修复而重命名。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| master | fix-version | fix-1.0.0 | release | 测试 |
refactor分支
refactor分支用户重构和优化代码，区别于修改 fix 分支，refactor分支不一定会在下一个版本中上线，而 fix分支一定会在下一个版本中上线。
| 分支来源 | 命名规则 | 命名示例 | 合并目标 | 应用环境 |
|---|---|---|---|---|
| develop | refactor-content | refactor-layout | develop | 开发 |
使用示例
根据需要整理了一个适用于Android团队的Git流程图，如下图所示：
创建项目
创建 master 分支，然后基于 master 创建出 develop 分支。
新功能开发
- 基于 develop 分支，创建 feature-version 分支，如果开发人员少，可以都在 feature-version分支上进行开发。如果开发人员比较多，基于feature-version 分支继续创建每个人的单独开发分支，命名如 feature-version-name。
- 完成开发。
- 联调代码，完成自测。
- 如果有多个 feature 分支，将其全部合并到 feature 分支，然后拉取 develop 分支的代码到 feature分支，解决可能存在的冲突，然后提交 MR 到 develop 分支，删除 feature 分支。
更多内容请阅读 原文链接
1136
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
