git 在工做中的使用以及与git flow比较

描述：

1. 最稳定的代码放在 master 分支上（至关于 SVN 的 trunk 分支），咱们不要直接在 master 分支上提交代码，只能在该分支上进行代码合并操做，例如将其它分支的代码合并到 master 分支上。
2. 咱们平常开发中的代码须要从 master 分支拉一条 develop 分支出来，该分支全部人都能访问，但通常状况下，咱们也不会直接在该分支上提交代码，代码一样是从其它分支合并到 develop 分支上去。
3. 当咱们须要开发某个特性时，须要从 develop 分支拉出一条 feature 分支，例如 feature-1 与 feature-2，在这些分支上并行地开发具体特性。
4. 当特性开发完毕后，咱们决定须要发布某个版本了，此时须要从 develop 分支上拉出一条 release 分支，例如 release-1.0.0，并将须要发布的特性从相关 feature 分支一同合并到 release 分支上，随后将针对 release 分支部署测试环境，测试工程师在该分支上作功能测试，开发工程师在该分支上修改 bug。
5. 待测试工程师没法找到任何 bug 时，咱们可将该 release 分支部署到预发环境，再次验证之后，均无任何 bug，此时可将 release 分支部署到生产环境。
6. 待上线完成后，将 release 分支上的代码同时合并到 develop 分支与 master 分支，并在 master 分支上打一个 tag，例如 v1.0.0。
7. 当生产环境发现 bug 时，咱们须要从对应的 tag 上（例如 v1.0.0）拉出一条 hotfix 分支（例如 hotfix-1.0.1），并在该分支上作 bug 修复。待 bug 彻底修复后，需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支。

对于版本号咱们也有要求，格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。针对每一个微服务，咱们都须要严格按照以上开发模式来执行。

与Git Flow模型分支管理的区别点：

• feature分支开发完成后，暂时不合并至develop，而是基于develop开启release分支，将feature分支合并到release分支，进行测试；
• release分支测试经过后，部署到生产环境，将release分支代码合并到develop分支与master分支，并在master分支打一个tag；