?1.开发流程
- 从 `master` 新建并切换至 `develop` ,在 `develop` 提交新版本功能开发(如 1.1.0 版本)的代码;
- 当 `develop` 已完成 ***1.1.0*** 版本的开发并自测完毕后,将 `develop` 代码合并入 `release`;
- 在 `release` 上打包并递交给测试进行提测;
- 测试所报的 bug,均修复在 `release`;
- (可选)根据实际情况,可以定时将 `release` 的变动合并到 `develop`(不建议 `release` 上每做一次提交,就执行一次合并,因为容易导致提交历史过于杂乱);
- 当测试完毕后,可以对 ***1.1.0*** ?版本进行封包,此时必须执行一次将 `release` 合并到 `develop` 的操作;
- 当产品发通知允许将应用打包发布时,将 `release` 合并到 `master` 上,并同时打上 `tag` ***1.1.0***;
2.特殊场景的处理
- 当正在进行下一个版本开始的过程中,发现线上正式版本有一个 `bug` 需要紧急修复时,怎么办?
- 从线上正式版本对应的 `tag` (比如 ***1.1.0***),创建一个 `hotfix_1.1.0` 分支;
- 将修改 `bug` 的代码,提交到 `hotfix_1.1.0`;
- 待测试通过后,将 `hotfix_1.1.0` 合并至 `master` ,并标记 `tag` ***1.1.1***;
- 将 `hotfix_1.1.0` 合并至 `release`,然后将 `release` 合并至 `develop`;
- 删除 `hotfix_1.1.0`;
- 当 ***1.1.0*** 在提测后,需要开始并行开发 ***1.2.0*** 时怎么操作?
- 在进行 ***1.2.0*** 开发前,请确保将 `release` 合并到 `develop`;
- 在 `release` 上修复 ***1.1.0*** `bug`,在 `develop` 上开发 ***1.2.0*** 版本;
- 在并行过程中,请注意定时执行 `release` 合并到 `develop` 的操作;
- **警告**:不能执行 `develop` 合并到 `release` 的操作:不能把 ***1.2.0*** 的开发代码,污染正在提测的 ***1.1.0*** 代码;
- 在问题 ***1*** 中,为什么不将 `hotfix_1.1.0` 先合并至 `develop`,再合并至 `release`?
- 参考问题 ***2*** 的第四步所说,为了保证开发流程的操作统一,所以这样规定
- 在开发过程中,有一个 `feature`,不确定是否会在当前版本发布时,怎么做?
- 有不确定的 `feature`,可以基于 `develop` 创建 `feature_需求名` 分支
- 在 `feature_需求名` 提交代码
- 当确定该功能可以提测时,再将 `feature_需求名` 合并至 `develop`
?3. 其他注意事项
- 在涉及本地分支和远程关联分支的同步时,请使用 ```git pull --base``` 代替 `git pull`;
- 在进行不同分支的合并时,请使用 ```git merge```,而不是 ```git rebase```;
|