git分支管理

末蓝、 2024-05-23 22:26 20阅读 0赞

## 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）;

#### **优势** ####

1.  过程简单，无多分支合并的困扰，节省项目一致性成本；
2.  随时可发布

#### **缺点** ####

1.  由于该模式没有本地和master主干的缓存区，因此需要确保本地提交的代码经过严格的测试。
2.  无法避免发布未完成的feature（例如我有一个功能feature1直接合并到master分支，让测试团队测试，但是另一个feature2要上线，就会把feature1给发布出去了）

#### **总结** ####

*  TrunkBased比较简单，只有一个master。适合如下场景项目：
 *  对项目定义清晰，**不适合**走IPD（ 集成产品开发 ）而形成的VRM产品线（V版本，指平台版本；R版本,指最终交付给客户的版本。M版本,指在R版本上为某些客户定制化的版本）
 *  对持续集成，每日构建，每日冒烟非常友好；
 *  为了减少本地代码到master之间的差异，发挥持续集成和每日构建的价值，在项目计划的WBS时，任务颗粒应该尽量小一些。因为颗粒越小，自测越迅速，提交越快，冲突越小。通常以人时为单位，原则上不允许一个任务超过8人时。通常在2到6左右。

#### **GitFlow** ####

*  ![在这里插入图片描述][28a32ef7107a4f60a0ee3e5ff5a78604.png]

#### **优势** ####

*  接下来是gitflow，主要改进是加入了feature分支，这样做就避免了TrunkBased多功能开发与发布冲突的问题。

#### **提交过程** ####

1.  初始环境。在 master 上打tag-0.1。
2.  初始环境。从 master 拉出 develop 分支。
3.  开发新功能。在 develop 分支上拉出 feature 分支，可能会有多个。
4.  提交新功能。将完成单元测试的 feature 合并回 develop。
5.  集成测试。在 develop 上可能存在多个 feature 集成测试的 bug，直接在 develop 上改。
6.  准备发布。当develop达到发布计划的要求时，就从develop提交到release。
7.  发布测试。在release上的bug，直接在release上改，改完merge回develop。
8.  部署上线。从release提交到master，并打上新tag-0.2，并从master部署上线。
9.  线上bug。如果不是紧急bug，还是可以按常规feature去做。如果是紧急bug，就从master拉出hotfixes，在hotfixes改和测，然后提交到master，merge到develop。

#### **缺点** ####

*  无法限定feature粒度的大小，如果粒度较大，比如模块级，会导致feature分支长期存在，等到feature完成进行代码合并的时候，容易出现大量的代码冲突。如果粒度过小，则会存在大量的feature分支，维护成本高，开发来回切换分支。容易把代码写到错误的分支上。
 *  对项目或产品计划要求较高 。产品计划里要做好各个 Feature 的编号和管理，这样才能更好的管理 develop 和 release 分支，使发布内容和过程可视度更高。比如有时 Feature 即使做完了也暂时不提交到 Develop。
 *  需要团队的每个人，都理解每一个提交点合并点的意义。应该从谁提交到谁，从谁 merge 到谁。而团队的能力总是分层的，总会有人不太理解，这时就会造成麻烦。

#### **Aoneflow** ####

*  ![在这里插入图片描述][7ae76769878f47a18d09a02596fef3ea.png]
 *  Aone Flow 采取了另外一个思路。只存在一个 Master 分支，当要开发时，就拉出新的 Feature 分支，可以同时存在多个 Feature，当达到发布计划时，就把需要合并的多条 Feature 分支合并起来，通过后再往 Master 上合并，并且tag下来。
 *  ![在这里插入图片描述][4c5d160d0bac4bda80c03fc7774dc80e.png]

[28a32ef7107a4f60a0ee3e5ff5a78604.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/16947ff9673049c4834d81f4b9d0fd79.png
[7ae76769878f47a18d09a02596fef3ea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/ed3892b3ea6a498983bc67dd203564ec.png
[4c5d160d0bac4bda80c03fc7774dc80e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/3b0eaffcedf841cdb5dab05c7d5f37a6.png