客户端版本代码分支管理

发表于 更新于

20201217客户端版本代码分支管理

前言

在使用Git作为代码版本管理工具的背景下，为了适应较快的迭代速度，降低代码冲突、覆盖等错误出现，以及提高协作效率，特此给出以下代码分支管理规范。

最佳实践

这里简单列举一些Git操作中较好的最佳实践：

  1. 不要将巨量修改提交在一个commit中，不利于记录查询乃至回退。类似于“少食多餐”的思想，每一次功能修改、每一个问题修复、每一个独立的特性引入后都做一个独立的commit进行提交
  2. 使用命令行进行Git操作，工具会隐藏很多Git操作背后的细节。一方面不利于开发者理解Git，另一方面可能会夹带私货，携带预期外的参数或操作
  3. 对于没有稳定预期的内容做单独分支进行管理，以避免污染主要开发分支

几个Git操作准则（必须遵守）

合并 merge

做分支合并时，应使用非快进式合并（no fast forward）。如使用的是命令行，则应添加--no-ff参数，如：

1
git merge --no-ff [from_branch]

通过IDE的VCS或其他GUI管理工具时，应注意选择：

原因：使用快进式合并时会将新老分支的commit记录合并为一条线，而非快进式合并只会在两个分支的交汇点构造一个新的merge commit，其他commit的记录会依然存留在原有分支上。在查询代码提交的历史记录时这样的操作会使得操作者看的更加清晰。

更新 pull

通常更新代码只需要通过git pull即可，但这里给出的规范是需要加入--rebase参数，即更新代码时引入变基操作。变基是Git操作中较为复杂的概念，有兴趣的同学可以自行了解。在Git Pull操作中加入变基属性的大意是：认为远端的最新代码版本是本地代码的基础。

这样的好处是，本地提交前永远会以远端为最新记录。换句话说，先提交者的代码版本会被认为是新的，而本地未提交的代码会被认为是旧的。若产生冲突，开发者需要在本地解决冲突后再进行提交。遵循冲突解决的规范后，将不会对远端代码产生覆盖。

冲突解决

当需要解决冲突时，必须仔细甄别每一个冲突节点，并主动联系相关开发者协同解决。切忌自行决定。

因错误解决冲突造成的功能缺失、BUG甚至Crash等问题的开发者将承担相关事故责任。

master不可被合并

即：任何分支不可以将master分支的内容合并过来，对于master分支来说，永远只是它接受其他分支的单向合并。

永远不要force push

永远不要执行force push操作，这种操作在正常、规范的Git操作环境下不会用到。极特殊情况下，如果需要，请联系组长及协调各方，确认后再做执行。

六种分支

固定分支：

  • master 分支，有且仅有一个。这个分支作为归档分支，归档已经发版的代码。不可进行手工提交，只可以接受来自dev分支的合并操作
  • dev或develop分，有且仅有一个。此分支为待发版分支，即此分支上的代码将在下一个即将发版的版本中集成上线。内容包括：新特性开发、老BUG修复等

动态分支：

假设下一个版本名为N，则：

  • vN分支
    • 何时创建？在N版本投入开发时，此分支由dev衍生，用于开发N版本上的需求
    • 开发过程中：应不停从dev合并代码过来（若dev有更新，此时的更新代码多为线上问题修复）。此合并操作由每一位在此分支上开发的开发者主动进行
    • 何时合并？当此分支对应的版本提测后，此分支需要合并回去dev分支
  • vN+1分支
    • 何时创建？当N+1版本投入开发时，若此版本不依赖上一个版本，则由由dev分支衍生而来；若依赖N版本上的开发内容，则由vN分支衍生而来。dev或vN分支称为其父分支，当vN提测后，则dev为其父分支
    • 开发过程中：同样的，应由相关开发者主动的从父分支合并代码过来，以保持更新
    • 何时合并？当此分支对应的版本提测后，此分支需要合并回其父分支

PS：当vN分支已经提测后，意义上vN+1此时也就变成了vN分支。

以上两个分支用来在可能产生穿插开发的背景下起到协同作用。

特殊分支：

  • feat_X或feature_X分支，用于承载不确定发布版本或风险较高的需求开发内容
    • 何时创建？确定相关需求投入开发时，选择合适的父分支进行衍生创建
    • 如何更新？开发过程中，应由相关开发者主动合并父分支内容过来，以保持更新
    • 何时合并？当此分支对应需求进入提测状态，并已经确定发版版本后，此分支合入对应版本分支
  • hotpatch_vX分支，用于在版本发布后发现问题时修复线上问题使用，即：用于发布hotpatch或增发版本。此分支由releaseTag或master分支衍生，其衍生节点必须与对应版本的最终提交节点完全一致。问题修复后，dev/develop分支应使用cherry-pick方式将相关调整内容同步回来（禁止将master分支合并回dev/develop分支）

一个Tag

在每次发版后，由对应的发版打包负责人在此版本的最后一次master合并节点上打一个新的Git Tag，命名规范为：

1
release_v[Version]

作用：此Tag可以用于历史版本代码的精准留存。如，需要打出某个历史版本的线下测试包时。

一张图