git分支管理
何为分支
- 分支就是版本库中记录版本位置（支线），分支之间项目会影响，使用分支可以对项目起到保护作用；
- 分支就是一条时间线，每次提交就在这条时间线上形成一个版本；
分支特性
- 创建一个新的版本库，默认创建一个主分支（master/main分支）
- 每个分支可以进行单独管理（常规分支、保护分支、只读分支）
- 分支是可以合并的
常用命令
- 查看分支：git branch
- 创建分支：git branch branch_name
- 切换分支：git checkout branch_name
- 剪出分支（创建一个新分支并切换到此分支）：git checkout 项目版本 -b branch_name
- 合并分支：git merge branch_name（将branch_name合并到当前分支上）
- 删除本地分支：git branch -d localBranchName
- 删除远程分支：git push origin（远程仓库名称） --delete remoteBranchName（分支名字）
git分支管理模型
- 分支管理模型是日常开发中尤为重要的环节，为了防止协同人员无规则的随便commit。本节重点讲解git使用规范。各分支的特性以及提交要求。
- 首先，介绍master分支，master是维护项目最稳定的分支。禁止没经测试的代码直接提交到master分支；master是稳定分支，其他分支都是不稳定分支。
- 一个分支只能做一件事（包括但不限于功能开发，修复BUG，整合，发布，紧急修复等），如果要做多件事情，最好开多个分支。尽量避免多个人在同一个分支上做事。
- 如果一个分支做完一件事，分支的生命周期就结束了，要删除这个分支。分支的生命周期越短越好，不要长期持有一个分支。
- 分支的上游只能是master，下游只能是release。
- 本节将分别讲解最常见的分支管理模型 TrunkBased 和 GitFlow ，以及阿里的分支管理模型AoneFlow。
TrunkBased 模式
- TrunkBased模式是持续集成思想所崇尚的工作方式，它由一个主分支和许多发布分支组成，每个发布分子在特定版本的提交节点从主分支创建出来，用来进行上线部署以及热修复（Hotfix）;
优势
- 过程简单，无多分支合并的困扰，节省项目一致性成本；
- 随时可发布
缺点
- 由于该模式没有本地和master主干的缓存区，因此需要确保本地提交的代码经过严格的测试。
- 无法避免发布未完成的feature（例如我有一个功能feature1直接合并到master分支，让测试团队测试，但是另一个feature2要上线，就会把feature1给发布出去了）
总结
- TrunkBased比较简单，只有一个master。适合如下场景项目：
- 对项目定义清晰，不适合走IPD（ 集成产品开发 ）而形成的VRM产品线（V版本，指平台版本；R版本,指最终交付给客户的版本。M版本,指在R版本上为某些客户定制化的版本）
- 对持续集成，每日构建，每日冒烟非常友好；
- 为了减少本地代码到master之间的差异，发挥持续集成和每日构建的价值，在项目计划的WBS时，任务颗粒应该尽量小一些。因为颗粒越小，自测越迅速，提交越快，冲突越小。通常以人时为单位，原则上不允许一个任务超过8人时。通常在2到6左右。
GitFlow
优势
- 接下来是gitflow，主要改进是加入了feature分支，这样做就避免了TrunkBased多功能开发与发布冲突的问题。
提交过程
- 初始环境。在 master 上打tag-0.1。
- 初始环境。从 master 拉出 develop 分支。
- 开发新功能。在 develop 分支上拉出 feature 分支，可能会有多个。
- 提交新功能。将完成单元测试的 feature 合并回 develop。
- 集成测试。在 develop 上可能存在多个 feature 集成测试的 bug，直接在 develop 上改。
- 准备发布。当develop达到发布计划的要求时，就从develop提交到release。
- 发布测试。在release上的bug，直接在release上改，改完merge回develop。
- 部署上线。从release提交到master，并打上新tag-0.2，并从master部署上线。
- 线上bug。如果不是紧急bug，还是可以按常规feature去做。如果是紧急bug，就从master拉出hotfixes，在hotfixes改和测，然后提交到master，merge到develop。
缺点
- 无法限定feature粒度的大小，如果粒度较大，比如模块级，会导致feature分支长期存在，等到feature完成进行代码合并的时候，容易出现大量的代码冲突。如果粒度过小，则会存在大量的feature分支，维护成本高，开发来回切换分支。容易把代码写到错误的分支上。
- 对项目或产品计划要求较高 。产品计划里要做好各个 Feature 的编号和管理，这样才能更好的管理 develop 和 release 分支，使发布内容和过程可视度更高。比如有时 Feature 即使做完了也暂时不提交到 Develop。
- 需要团队的每个人，都理解每一个提交点合并点的意义。应该从谁提交到谁，从谁 merge 到谁。而团队的能力总是分层的，总会有人不太理解，这时就会造成麻烦。
Aoneflow
Aone Flow 采取了另外一个思路。只存在一个 Master 分支，当要开发时，就拉出新的 Feature 分支，可以同时存在多个 Feature，当达到发布计划时，就把需要合并的多条 Feature 分支合并起来，通过后再往 Master 上合并，并且tag下来。
