程序版本（分支）管理策略

程序版本（分支）管理策略

• 当前很多项目实施现场都采用登记簿（excel）的方式管理程序版本，而且每次版本部署都是采用增量发布class文件的方式。这种手工的管理方式，生产处理效率低下，开发人员或版本管理人员容易遗漏代码。如果管理不善，线上代码已经无法找到其源代码，还得靠反编译class的方式获取源代码。

• 当今互联网化的IT开发模式下，程序版本更迭快，运维需要打包、测试、发布等操作都线上自动化，上面这种手工管理模式已经无法满足，需要更为规范和高效的程序版本管理策略。

• Vincent Driessen提出了一个分支管理的策略，非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用。

主分支（Master）

• 程序库应用有且仅有一个主分支。所有提供给用户使用的正式版本，都在这个分支上通过Tag进行标记不同版本。主分支应该只有版本管理员才能有读写入权限，其他人员只有读权限，以此来保证主分支程序的正确性。一般在程序库未正式发布（上线）前，其主分支应该没有任何代码；当程序库正式发布第一个版本时，版本管理员会将该正式版本代码分支代码合并到主分支上，并打上Tag标记，这样就形成了第一个版本的主分支。

  Git主分支的名称Master。
  

开发分支（Develop）

• 主分支只是用来标记正式版本，并不用于开发。新建项目（还未发布）程序的日常开发应该在另一条分支上完成，这个分支我们称之为开发分支，也叫做Develop，通常使用git的管理者一般将该分支简写成dev。

• 正式对外发布第一个版本时，就可以将开发分支的最新代码合并到主分支上，且主分支Tag标记上第一个版本号。一旦项目代码已经发布第一个版本，所有开发人员都不能再使用开发分支（Develop）进行新的功能开发了（需要新建分支进行新功能开发，后面会讲到）。开发分支（Develop）此时就转换成了“集成分支”，其分支下的代码始终体现下个待发布版本的代码。
  

辅助性分支

• 辅助性分支与关键分支（master和develop）一起，用来支持团队成员们并行开发，使得易于追踪功能，协助生产发布环境准备，以及快速修复实时在线问题。与关键分支不同，这些分支总是有一个有限的生命期，因为他们最终发布后会被移除。
  辅助性分支主要有三种：

功能（feature）分支
预发布（release）分支
修复bug（fixbug）分支

功能（feature）分支

• 它是为了开发某种新需求功能建立的分支，是从Develop分支上面分出来的。功能分支只是这个功能处于开发状态时他就会存在，如果确认该功能将在下一个发布版本发布，则需要将该功能分支合并到Develop分支上；如果该功能确认不在需要，可以直接删掉该分支。这样就保证了Develop分支始终体现下一个待发布版本的代码。
• 功能分支一般采用feature-*的命名形式，一般功能分支以需求功能命名比较合适，不能以版本号命名，因为你还不知道具体的版本安排。一般软件生命周期：开发、SIT测试、UAT测试的几个阶段将使用功能分支来管理。
  

预发布（release）分支

• Release分支是从Develop分支创建而来，最后一定会合并到Develop和Master分支上，一般采用release-${版本号}的命名形式。
• Release分支是为新版本的发布做准备的，该分支允许我们在最后时刻做一些细小的代码修改、小BUG的修改，以及准备发布的元数据（版本号，发布时间等等）。在Release分支创建的时候要为即将发行版本分配一个版本号，因为直到此时，Develop分支反映的变化都是为了下一个发行版，但是在Release分支创建之前，下一个发行版到底叫0.8.0还是1.0.0是不明确的。这个决定是在Release分支创建时根据项目在版本号上的规则制定的。建议的版本号的分配规则：x.y.z，x、y、z都是大于等于零的整数，一般项目的第一个版本号：0.1.0

x：在发生重大功能变更时，又或者版本无法向下兼容时，该整数加一，同时y和z归零
y：在添加了新的业务功能或者删除了部分功能，该整数加一，同时z归零
z：解决了一些线上BUG、做了一些技术优化等非功能性，该整数加一

• 按照上面的版本号的规则，Release分支应该在y上加一，即：原版本号是：0.1.0，下个发布的Release版本号应该是：0.2.0。当然也可能是x上加一，即：原版本号是：0.1.0，下个发布的Release版本号应该是：1.0.0，者取决于该预发布版本功能变更的情况。
• 从Develop分支创建新的Release分支的关键是Develop分支达到了预发布的理想状态，也就是所有这次要发布的features分支必须在这个时点及时合并到Develop分支。对于所有下一个版本准备发布的features分支必须等到Release分支创建以后才能再合并，实际操作中建议等该Release版本发布后，且已经将代码合并到Develop和Master分支上以后，才能将下一个版本准备发布的features分支合并到Develop分支上，再安排下一个版本的Release分支。
• Release分支创建完成后，需要版本管理员对比Release分支与Master分支之间的代码，如果发现明细问题的程序需要修改并测试。另外需要安排该预发布分支进行上线前的回归验证测试，验证测试发现的BUG开发人员应该在该分支上进行修改（而不是修改到Develop分支上），直到测试达到预期目标该版本程序稳定并封版。在Release分支上严谨增加大的features新功能代码，正确做法应该是基于Develop分支建立单独的功能分支，进行开发、SIT测试、UAT测试后，再将这些新功能分支合并到Develop分支上，然后等待创建下一次的预发布分支（版本）。为了便于版本先后的管理，未来发布版本的Release分支有且只有一个。
• 当一个Release分支回归测试完成后，准备好成为一个真正的发行版的时候，下面这些工作必须完成。
• 第一步、需要再次核对当前Release分支与Master分支之间的代码，避免未测试的程序偷偷的被上线；
• 第二步、当前Release分支下构建部署物（当前架构中多用Maven进行管理），并上传部署物到生产环境准备，完成部署后进行生产验证；
• 第三步、生产验证正常的情况下，将Release分支要合并到Master上，合并后Master分支就是最新的程序版本了。然后对Master分支打一个版本标签Tag（标签的命名建议采用Tag-${版本号}格式），以便以后更加方便的引用这个历史版本。最后，在Release分支上的修改必须合并到Develop分支上，以便未来发行版也包含这些已经发行的功能；如果实际分支管理中出现了多个在途的预发布（Release）分支，版本管理员必须在生产验证正常的情况下，将刚上线的Release分支的代码合并到其他在途Release分支上去(最好不要出现这种多个在途Release分支的情况)，合并是注意版本号的冲突；
• 第四步、合并完成后，删除该Release分支；
  Release、Feature、Develop分支的关系如下图：
  

修复bug（fixbug）分支

• 应用软件正式发布后，难免会出现一些BUG。BUG应该根据问题的紧急层度，分而治之。不太紧急的BUG可以在某个功能（feature）分支下修改代码，并放到下一个预发布（Release）的版本进行发布。比较紧急的BUG就需要创建当前这种修复bug分支，一般采用fixbug-${版本号}的命名形式。
• 修复bug（fixbug）分支与预发布（Release）分支很相似，它们都是为新的生产版本发布做准备，尽管这未在你的生产版本计划之内。修复bug（fixbug）分支应该基于Master分支上对应与生产版本的标签Tag创建而来。其本质是团队中大部分成员在其Feature分支、Release分支的工作可以继续，而修复bug的人员准备基于Fixbug分支进行生产环境问题的快速修复。
• 同Release分支一样，Fixbug分支在创建时也要指定其具体的版本号，按照上面的版本号的规则，Fixbug分支应该在z上加一，即：原版本号是：0.1.0，下个发布的FIxbug版本号应该是：0.1.1。
• 在整个Fixbug分支下进行bug修复开发后，也需要安排该Fixbug分支进行上线前的验证测试，验证测试发现的BUG开发人员应该在该分支上进行修改，直到测试达到预期目标该版本程序稳定并封版。为了便于版本先后的管理，未来发布版本的FIxbug分支有且只有一个。
• 当一个Fixbug分支测试完成后，准备好成为一个真正的发行版的时候，下面这些工作必须完成。
• 第一步、需要核对当前FIxbug分支与Master分支之间的代码，避免未测试的程序偷偷的被上线；
• 第二步、当前Fixbug分支下构建部署物（当前架构中多用Maven进行管理），并上传部署物到生产环境准备，完成部署后进行生产验证；
• 第三步、生产验证正常的情况下，将Fixbug分支要合并到Master上，合并后Master分支就是最新的程序版本了。然后对Master分支打一个版本标签Tag（标签的命名建议采用Tag-${版本号}格式），以便以后更加方便的引用这个历史版本。最后，在Fixbug分支上的修改必须合并到Develop分支上，以便未来发行版也包含这些已经修复的bug；如果实际分支管理中出现了多个在途的FIxbug分支，版本管理员必须在生产验证正常的情况下，将刚上线的Fixbug分支的代码合并到其他在途Fixbug分支上去(最好不要出现这种多个在途Fixbug分支的情况)，合并是注意版本号的冲突；
• 第四步、合并完成后，删除该Fixbug分支；
• 关于Release分支与Fixbug分支有一个例外，两者分支同时并存的情况，我们分两种情况来讨论：
  正常情况下Fixbug分支应该比Release分支先进行生产发布，那么Fixbug分支除了合并到Develop分支和Master分支外，应该还要合并到该Release分支中。避免出现该Release分支发布时不含Fixbug分支修改的内容；
• 如果出现Release分支比Fixbug分支先进行生产发布，可以同上将Release分支合并到Fixbug分支。另外大多数情况下Fixbug分支下修改的代码量较小，也可以重新从合并该Release分支的Master分支中拉一个新的Fixbug分支，并将当前Fixbug分支的修改代码合并到新的Fixbug分支上，并将原Fixbug分支删除；
  Master、Fixbug、Develop分支的关系如下图：
  
• 程序版本（分支）管理没有太多新颖的东西，主要是要求版本管理人员的细心，以及与其他开发人员的协同。整个程序版本管理并不是版本管理人员一个人的事情，需要整个团队人员都要理解并遵照执行，才能达到预期效果，我们再也不能通过手工台账的方式进行版本管理了。