git分支管理 末蓝、 2024-05-23 22:26 0阅读 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
还没有评论,来说两句吧...