项目代码分支管理

最新推荐文章于 2024-09-26 10:55:54 发布

<ZYH>

最新推荐文章于 2024-09-26 10:55:54 发布

阅读量652

点赞数 1

分类专栏： git 文章标签： git

本文链接：https://blog.csdn.net/weixin_55059461/article/details/130316013

版权

git 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Git是常用的代码管理工具，它的主要优点有：

分布式存储
优秀的分支模型，创建/合并分支非常方便
方便快速

当分支过多时，该如何进行分支管理呢？

主干发布 vs 分支发布

主干发布的特点是项目开发工作在master分支上，代码开发完毕后，经过功能测试没有问题后，在master分支上打release标签作为项目代码版本进行发布，是效率最高的一种项目开发方式。 发布完毕后，master主分支还继续做项目下一个功能版本的开发工作。如果线上代码出现bug，那么就在master分支上修复就可以了。

分支发布的项目开发工作在master分支上，代码开发完毕后，经过功能测试没有问题后，从master主分支上切出一个release分支，作为项目代码版本发布的专用分支，而master分支还继续做项目的下一个功能版本的开发工作。如果线上代码出现bug，那么就在release分支上修复即可，修复后的代码要最终合并到主干上，只有非常严重的缺陷修复才会从master合并到release分支上。

Git Flow模式

Git Flow是一种代码分支管理规范，属于主干开发-主干发布类型。遵循GitFlow规范的分支分为两种，长期分支和短期分支。
官方：https://nvie.com/posts/a-successful-git-branching-model/
在这里插入图片描述

长期分支

1 master分支

对外发布的唯一分支
只读不可修改
一般只能由hotfix或develop合并

2 develop分支

基于master分支克隆，只读不可修改
feature分支由该分支拉出，开发完成后合并到develop分支
分支上的功能经测试无误后，需要由该分支再次合并到master分支上

短期分支

一旦开发完成，就会合并到develop和master分支上，然后被删除。

1 feature分支

在这里插入图片描述

基于develop分支克隆，主要用于新需求新功能的开发

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

feature分支可同时存在多个
功能开发完毕并测试完成后合成到develop分支，合并后此分支删除【注：谁合并谁删除】

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

【注】--no--ff参数：强制关闭fast-forward方式合并，保留分支的commit历史，并生成一次合并的提交记录。（如图）
在这里插入图片描述

2 hotfix分支

基于master分支克隆，主要用于对线上的版本进行bug修复
修复完毕后，如果需要临时发版则需要打tag并推送到master/develop分支，如果不需要发版只需要推送到develop分支且不用打tag。

3 release分支

用于提交给测试人员进行功能测试，测试过程中发现的bug在本分支进行修复，修复完成上线后打tag并合并；
基于develop分支克隆
提测完成后合并到master/develop分支，然后删除该分支【注：谁合并谁删除】

补充说明

feature分支通常仅存在于开发人员存储库中，而不存在于origin（远程版本库）；
没有分支保护概念，任何开发人员都可以对develop进行合并和推送；
去中心化：每个开发人员单独一个分支开发，或者两个/多个一起开发一个大的新功能。
对于长期的feature分支可能存在严重的合并冲突问题，需要花费大量的时间解决；
feature分支之间相互隔离，CICD困难，单个功能可能没有问题，但合并以后是否会出现问题无法确定。

Github Flow

官方： https://docs.github.com/cn/get-started/quickstart/github-flow#address-review-comments
Github Flow是Git Flow的简化版，专门配合“持续发布”，是以部署为中心的开发模式。

Github Flow只有一个长期分支master；
Github Flow没有release分支，需求功能直接在feature分支上测试完毕merge到master，在master分支上进行发布；
每次feature分支merge到master上时可能会有冲突，这要求在feature发布前需要合并master代码到feature上，进行提前测试。

补充说明

Pull Request阶段可以进行Code review和一些自动检测；
要保证高质量，对于贡献者的素质要求较高；
github flow对于库、框架、工具这样并非最终应用的产品来说没问题，但如果一个产品是直接发布，可能就不合适了。

Gitlab Flow

官方：https://docs.gitlab.com/ee/topics/gitlab_flow.html#introduction-to-gitlab-flow
在这里插入图片描述
Gitlab Flow是Git Flow和Github Flow的综合，它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是Gitlab.com推荐的做法。

只存在一个主分支master，它是所有其他分支的上游‘
上游优先（upstream first） 原则，只有上游分支采纳的代码变化，才能应用到其他分支，必须先合并到master后才是其他；
对于持续发布的项目，它建议在master分支以外，再建立不同的环境分支。比如，开发环境的分支是master，测试环境的分支为pre-production，生产环境的分支是production。
版本发布流程，不是采用tag的形式，而是从master创建出分支，比如2-3stable、2-4stable等，注意master分支上的代码是稳定的；
线上bug修复：从master创建修复版本后，git cherry-pick到master，再部署对应的环境。