就在这周，因为代码分支管理的问题，公司大群里发生了一场小争论，所以先把这个话题记下来。当然，从技术角度来说，***的结论永远是没有对错之分。所以一切仍然取决于使用它的人或团队。试想，屠龙刀落在不同的人手中，威力是完全不同的。Git分支管理策略Git的分支管理策略通常有两个“派系”：GitOneTrack和Gitflow。当然，也有不少人将这两种方法混用。但需要说明的是，分支管理并不是给团队“分猪肉”，而是参考团队的发展习惯和管理方式做出的选择。上一篇文章提到，一个ScrumTeam的规模在7人左右，不要因为团队规模比较大，就让一个大团队拆分成多个分支进行简单的管理，然后让不同的团队独立开发。如果是这样，在同一个产品上做代码合并（***在同一个可运行的包上）将是考验你内心的时候。在分团队的时候，总会遇到需要开发一个比较大的产品的时候。比如唯品会要做一个订单系统，这不是7个开发+测试就能完成的。那么是不是应该组织一个几十人的团队一起来做呢？我个人的理解还是7个人的原则。先从产品做起，想办法把一个大产品拆分成多个小产品，不同的小产品之间有明确的接口，所以考虑在小产品的规模上组建团队。每个小产品团队可以考虑自己的代码分支管理策略，同时将小产品做成一个可以独立运行的交付物，可以独立自包含、自测试，实现团队自主管理。一般来说，GitOneTrackOneTrack是指整个ScrumTeam基本上都是围绕Dev分支（或版本分支）进行开发。无论是每一个新特性还是Bug修复，都在这个分支上。当然，当我们需要同时维护多个版本（不是多个特性）时，我们就需要在多个版本上进行开发。但是这里需要强调的是，在对一个版本进行分支时需要谨慎，因为当你需要修复一个问题或者增加一个新特性时，你需要在不同的分支上手动进行。最好的办法是，当一个版本基本稳定，并且从产品的角度来看，这个版本刚好进入维护周期，就可以开一个新的版本分支。或者最新的代码在Dev分支，当一个版本处于维护期时，就开一个维护分支。下图是一个轨道的示意图。onetrackOneTrack***的特点是：ScrumTeams在一个分支上工作，易于管理，CI/CD可以通过一个Jenkinsjob来完成。提交代码之前的每次拉取都可能发生冲突。如果不同的成员工作为了减少相似文件上的冲突，操作经验通常建议经常拉取，不要长时间在本地工作。每次提交都要保证jenkinsbuild->Test等作业必须通过。每个提交都是一个小粒度的任务，而不是大块的代码。每个小任务都是可运行的，确保测试很容易立即跟进。某种程度上，版本策略的选择与团队中开发测试的合作模式有一定的关系。GitflowGitflow通常有一个概念，即任何更改都是Branching，无论是feature还是hotfix，都应该作为branch来完成。这种做法也受到很多人的推崇。包括Sourcetree等很多工具也是直接内嵌支持的。这种方式在管理上看似比较干净，但实际上容易进入误区，给代码合并带来更多麻烦。具体什么是Gitflow在这里就不啰嗦了，大家可以看看下图：gitflowGitflow中容易引起的误区：因人而异的目的是为了解决人与人之间的开发冲突。究其根本原因在于作品“分肉”，开发等之间的合作存在一些局限性。需求/设计管理上的不足，导致每个特性划分过多，一个特性需要做一周甚至一个月，导致分支与主体分离时间过长，不同分支之间的冲突分支太大。提前规划，通常是为了某个目的，不是去开发当前发布版本的内容，而是开始做接下来几个阶段或者更远期的功能规划。我们有句话叫“不要过度设计”，但是对于开发来说，“不要过度开发”更为重要。Gitflow在管理上还需要注意额外的成本，包括是否为每个feature分支配置相关的jenkins用于CI/CD，如何配合后续测试，尤其是测试与开发同步时，它容易造成团队冲突太多，因为在一个分支上测试好了，回到主分支可能需要重测或者重测。然后测试失败。似乎这种方法更适合自动化测试，或者测试和开发之间有明确界限的团队（但是我在上一篇文章中提到过，我反对开发和测试之间的测试概念）。***，俗话说，没有完美的方式，只有最合适的方式，一切都取决于团队的磨合。版本管理无论什么样的开发模式，什么样的代码管理策略，都要发布最好的版本。所以版本管理就显得尤为重要。但是这里有一个误区，版本管理通常认为是发布。其实版本管理更多的体现在如何推广，如何维护，发布后如何为下一个版本打基础。就是因为很多人误以为版本管理就是发布，所以为了避免升级管理等麻烦，总是希望发布一个稳定的版本。那么还有一个比较可笑的问题，什么时候是“最后一个版本”。从产品生命周期的角度来看，所谓“最后一个版本”，就是产品即将“消亡”。真正有生命力的产品，体现在版本的不断创新上。那么什么是版本管理呢？我的理解是每个版本都可以在以下几个方面体现出一个明确的目标，具体完成哪些功能，或者实现性能KPI等某些方面的提升（或者像SRE上说的KPO）每个版本都应该有一个相应的推广计划。因为每次出新版本，总会有保守的团队问“有人用过吗？稳定吗？”但如果没有先行者去尝试，友好的用户去当小白鼠，那么这个问题将是无解的。因此，每发布一个版本，都需要提前有合适的推广对象，并以某种方式推动他们先行尝试。当然，该方法将考验产品团队的才华。留一只手。看似每次发布一个版本，但实际上，从版本管理的角度来说，你的手上需要有一个“回滚版本”。毕竟不是每个版本都能如愿成为稳定版，所以为了避免没有可用的版本，在发布促销版本时需要有明确的版本回滚策略。这对于提供开发框架的产品尤为重要。如果出现兼容性变化，很可能没有可用的版本，必须谨慎对待这种风险。多版本维护。由于需要对多个版本进行推广尝试以规避风险，同时也会带来副作用，即在生产中同时运行多个版本，对维护和支持造成一定的压力，包括时间、人力等和成本。因此，在通过不同版本的试用后，需要确定一个稳定的版本，并推动升级，使版本一起成为这个稳定的版本。通常，这种方法称为“版本基线收敛”。对于Scrum模式，我们强调每个sprint应该有一个可运行的版本。但是每个版本都需要正式发布给大家使用吗？其实不是的，在运营上，可以每次迭代发布一个版本，但是具体推送给大家可以根据各种情况来决定。如果有可能有一小部分功能不完整（不是不能运行，而是实现场景不完整），那么这个版本只是一个内部版本。对于版本监控问题。尤其是在基础框架软件等通用软件的使用中，必须要有一些手段来监控生产中运行了多少个版本。同时可以第一时间找到对应版本的用户。这样当出现问题时，可以第一时间发现用户并进行处理。同时也可以很好的规划下一个版本谁是最合适的试用用户。我们的做法是通过埋点的方式将信息打成文件，然后收集到APM软件上进行查询和展示。版本号的管理好像没什么好说的。设置一个版本号比如1.0还不够吗？事实上，我们部门内部已经就这个问题进行过多次辩论。主要问题体现在使用3位编码格式还是4位编码格式。虽然本质上不会有太大的区别，但更多的是体现在人们心理上的不同。比如1.0.1和1.1.0，大部分人还是觉得1.0.1用起来比较安全，改动比较小。其实有可能是1.0.1改的比较多，因为定义这个版本号的人有误导别人的意思。因此，版本号的格式的使用最好有比较明确的规则信息。目前我们的操作规程如下，供您参考：管理方式为3位编码，x.y.z。X代表大版本变更，不同大版本可能不兼容。比如1.0.0和2.0.0不兼容。Y代表功能版本。本次版本变更表明引入了新的特性，不同版本之间的相同特性是兼容的。Z代表hotfix版本，解决bug，不引入任何新功能。不同版本完全兼容。多版本带来的坑为了规避风险，同时维护多个版本还有一个风险，就是不同版本之间的兼容风险。比如一个客户端和服务端的程序，不同的客户端版本和服务端版本之间的兼容性可能会出现问题。所以在一定时间后，关闭版本非常重要。我们遇到过API版本不同导致的OOM问题。对于多版本的维护，测试人员在设计测试点时也需要将其作为一个重要的方面来考虑。当然，如果DevOps再好点，最后可能会维护一个版本上线。但是，当公司业务部门众多，业务发展节奏完全不一致时，要维护一个统一的版本是极其困难的。没有强大的推动力是做不到的。可能需要CTO级别的管理人员来提拔。升级路径同时维护多个版本时，需要明确升级路径策略，让用户清楚的知道版本变更应该去哪里，也让维护者思考维护什么样的版本最好的。比如我们的一个产品的升级路径是：1.0.10->1.1.11.0.10->1.1.21.0.10->1.1.31.1.1->1.1.21.1.1->1.1。3有了明确的升级路径策略后，测试同学还需要跟进设计不同路径的测试点，避免多版本带来的各种坑。【本文为专栏作者“VIPDOCKER-Leoge”原创文章，如需转载请通过联系作者】点击此处查看该作者更多好文
