关于代码控制管理的一些想法

最近工作中遇到一个开发团队，对代码的版本控制管理居然没有要求，导致了种种问题。

1.由于分支没有规范，最后一个小版本上线合代码居然化了几个小时，最后开发人员自己都不知道合到哪个分支。

2.一些人把所有的代码都提交到master上，造成在维护的时候，难以得到想要的高效的稳定的版本，也无法区分版本管理节点

3.代码提交的说明，很多人都不注意这个，随意写写就ok了。后期想要明确某次提交修改的问题点时，往往需要重复看代码才能明确，

   在向主干分支提交（merge）代码时，代码说明往往该作为一个模块的修复，而不是一个一个问题点，细节点的修复。

   （比如，提交了一版代码，忽然发现有个变量命名不规范，又提交了一版，一会又发现漏提交了某个问题，又提交一次，

     这对于主干分支来说，就没能发挥代码版本控制的功能，说的不好听一点，这种版本控制管理就只是相当于一个代码的暂存控件而已，

      谈不上控制和管理）

4.虽说是使用版本控制，但很多人都不明确，这个版本控制到底是什么，多数人只怕还停留在“代码存储”的概念上吧。

。。。

还有很多，列举起来种种难以穷尽。

当然，在实际的工作中，虽然没有完美的工作流，但是，我却相信是有更好更佳的工作流的。

比如，版本控制来说，对后期代码维护，版本维护，客户问题应急响应等方面都是很有帮助的。

拿 GitLab 来说，它很好地支持了多分支代码版本，需要利用这个特性来提高开发效率，上图就是目前的分支管理规范。

 

以下是个人在工作中的一点总结，分享出来大家共同勉励。有不足之处，希望大家多多交流，以求共同进步。

最稳定的代码放在 master 分支上，不要直接在 master 分支上提交代码，只能在该分支上进行代码合并操作，例如将其它分支的代码合并到 Master 分支上。



开发中的代码需要从 master 分支拉一条 develop 分支出来，该分支所有人都能访问，但一般情况下，也不会直接在该分支上提交代码，代码同样是从其它分支合并到 develop 分支上去。



当需要开发某个特性时，需要从 develop 分支拉出一条 feature 分支，例如 feature-1 与 feature-2，在这些分支上并行地开发具体特性。



当特性开发完毕后，决定需要发布某个版本了，此时需要从 develop 分支上拉出一条 release 分支，

例如 release-1.0.0，并将需要发布的特性从相关 feature 分支一同合并到 release 分支上，随后将针对 release 分支推送到测试环境，测试工程师在该分支上做功能测试，开发工程师在该分支上修改 bug。



待测试工程师无法找到任何 bug 时，可将该 release 分支部署到预发环境，再次验证以后，均无任何 bug，此时可将 release 分支部署到生产环境。
待上线完成后，将 release 分支上的代码同时合并到 develop 分支与 master 分支，并在 master 分支上打一个 tag，例如 v1.0.0。



当生产环境发现 bug 时，需要从对应的 tag 上（例如 v1.0.0）拉出一条 hotfix 分支（例如 hotfix-1.0.1），并在该分支上做 bug 修复。待 bug 完全修复后，需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支。



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

 

 

需要善用代码版本控制系统，我曾经遇到一个开发团队，由于分支没有规范，最后一个小版本上线合代码居然化了几个小时，最后开发人员自己都不知道合到哪个分支。拿 GitLab 来说，它很好地支持了多分支代码版本，需要利用这个特性来提高开发效率，上图就是目前的分支管理规范。
最稳定的代码放在 master 分支上，不要直接在 master 分支上提交代码，只能在该分支上进行代码合并操作，例如将其它分支的代码合并到 Master 分支上。
日常开发中的代码需要从 master 分支拉一条 develop 分支出来，该分支所有人都能访问，但一般情况下，也不会直接在该分支上提交代码，代码同样是从其它分支合并到 develop 分支上去。
当需要开发某个特性时，需要从 develop 分支拉出一条 feature 分支，例如 feature-1 与 feature-2，在这些分支上并行地开发具体特性。
当特性开发完毕后，决定需要发布某个版本了，此时需要从 develop 分支上拉出一条 release 分支，例如 release-1.0.0，并将需要发布的特性从相关 feature 分支一同合并到 release 分支上，随后将针对 release 分支推送到测试环境，测试工程师在该分支上做功能测试，开发工程师在该分支上修改 bug。
待测试工程师无法找到任何 bug 时，可将该 release 分支部署到预发环境，再次验证以后，均无任何 bug，此时可将 release 分支部署到生产环境。待上线完成后，将 release 分支上的代码同时合并到 develop 分支与 master 分支，并在 master 分支上打一个 tag，例如 v1.0.0。
当生产环境发现 bug 时，需要从对应的 tag 上（例如 v1.0.0）拉出一条 hotfix 分支（例如 hotfix-1.0.1），并在该分支上做 bug 修复。待 bug 完全修复后，需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支。
对于版本号也有要求，格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。针对每个微服务，都需要严格按照以上开发模式来执行。