版权声明:本文为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 分支。
更多内容请阅读 原文链接