github分支管理

 1.开发流程

1. 从 `master` 新建并切换至 `develop` ，在 `develop` 提交新版本功能开发（如 1.1.0 版本）的代码；
2. 当 `develop` 已完成 ***1.1.0*** 版本的开发并自测完毕后，将 `develop` 代码合并入 `release`；
3. 在 `release` 上打包并递交给测试进行提测；
4. 测试所报的 bug，均修复在 `release`；
5. （可选）根据实际情况，可以定时将 `release` 的变动合并到 `develop`（不建议 `release` 上每做一次提交，就执行一次合并，因为容易导致提交历史过于杂乱）；
6. 当测试完毕后，可以对 ***1.1.0***  版本进行封包，此时必须执行一次将 `release` 合并到 `develop` 的操作；
7. 当产品发通知允许将应用打包发布时，将 `release` 合并到 `master` 上，并同时打上 `tag` ***1.1.0***；

2.特殊场景的处理

1. 当正在进行下一个版本开始的过程中，发现线上正式版本有一个 `bug` 需要紧急修复时，怎么办？
   1. 从线上正式版本对应的 `tag` （比如 ***1.1.0***），创建一个 `hotfix_1.1.0` 分支；
   2. 将修改 `bug` 的代码，提交到 `hotfix_1.1.0`；
   3. 待测试通过后，将 `hotfix_1.1.0` 合并至 `master` ，并标记 `tag` ***1.1.1***；
   4. 将 `hotfix_1.1.0` 合并至 `release`，然后将 `release` 合并至 `develop`；
   5. 删除 `hotfix_1.1.0`；
2. 当 ***1.1.0*** 在提测后，需要开始并行开发 ***1.2.0*** 时怎么操作？
   1. 在进行 ***1.2.0*** 开发前，请确保将 `release` 合并到 `develop`；
   2. 在 `release` 上修复 ***1.1.0*** `bug`，在 `develop` 上开发 ***1.2.0*** 版本；
   3. 在并行过程中，请注意定时执行 `release` 合并到 `develop` 的操作；
   4. **警告**：不能执行 `develop` 合并到 `release` 的操作：不能把 ***1.2.0*** 的开发代码，污染正在提测的 ***1.1.0*** 代码；
3. 在问题 ***1*** 中，为什么不将 `hotfix_1.1.0` 先合并至 `develop`，再合并至 `release`？
   1. 参考问题 ***2*** 的第四步所说，为了保证开发流程的操作统一，所以这样规定
4. 在开发过程中，有一个 `feature`，不确定是否会在当前版本发布时，怎么做？
   1. 有不确定的 `feature`，可以基于 `develop` 创建 `feature_需求名` 分支
   2. 在 `feature_需求名` 提交代码
   3. 当确定该功能可以提测时，再将 `feature_需求名` 合并至 `develop`

 3. 其他注意事项

1. 在涉及本地分支和远程关联分支的同步时，请使用 ```git pull --base``` 代替 `git pull`；
2. 在进行不同分支的合并时，请使用 ```git merge```，而不是 ```git rebase```；