【git分支管理策略】

文章目录

  • 前言
  • 一、分支管理策略简介
  • 二、git基本操作
  • 三、git分支
    • 远程分支
    • 本地分支
  • 四、gitflow分支管理策略
    • 分支定义
    • gitflow分支管理策略评价
  • 五、GITHUB FLOW分支管理策略
    • 分支使用流程
    • 创建分支(Create a branch)
    • 新增提交(add and commit)
    • 提出 Pull 请求(Open a pull request)
    • 讨论和评估你的代码(Discuss and review your code)
    • 部署(Deploy)
    • 合并(Merge)
    • github flow分支关了策略评价
  • 六、GITLAB FLOW分支管理策略
    • 分支定义
    • 分支使用方案
  • 总结


前言

随着开源软件和分布式版本控制系统(如 Git)的普及,分支策略已成为软件开发和项目管理中的重要概念。在本文中,我们将深入探讨 Git 中的分支策略,以及如何有效地使用它们来提高团队协作和项目管理效率。
本文目标:

  • 介绍git基本操作以及整合idea的git插件使用

  • 解读git分支的作用

  • 解读git flow分支管理策略
    读完本文后:

  • 掌握git的使用

  • 了解gitflow相关分支的命名和作用


提示:以下是本篇文章正文内容,下面案例可供参考

一、分支管理策略简介

分支策略是指在版本控制系统中使用分支来管理代码更改的方法。在 Git 中,分支允许开发人员在同一个项目中并行工作,每个分支代表一个独立的开发线。这使得团队能够更高效地处理并行任务、快速迭代以及错误修复。

二、git基本操作

git操作的前提条件:

  • 本地windows安装git
  • 学习idea中的插件使用

idea的git基本操作:

  • 远程仓库remote: git remote
  • 更新fetch:git fetch
  • 拉取pull: git pull
  • 上传push: git push
  • 合并merge: git merge 合并分支
  • 本地提交commit:git commit
  • 分支branch: git branch 查看分支或者 切换分支
    上述命令属于非常常见的git操作命令,基本使用git必用到的,但是相对来讲,使用idea插件会弱化他们原生命令的使用.
    好处是简单,坏处是对底层命令不熟悉,会导致在插件中的各种选项问题困扰.本文基于idea的git插件,不需要过多了解,如有兴趣和需要请自行查询相关官方文档即可.

三、git分支

为了方便资源版本更新中对多人协作的并行开发进行有效的管理,git存在分支的概念.
我们可以利用分支记录一个稳定或者测试通过的版本,在新分支开发新功能,而在出现问题后及时切换回去.
同时一个功能过于复杂的时候,也可以建立并行的多个分支,多人同时开发最终合并等.
在git分支管理中存在远程分支和本地分支两种类型.

远程分支

托管中心平台或者服务器中可以查看的分支.一般是本地提交上传的同步.

本地分支

开发者操作的本地git仓库内容,一般会与远程分支在数量和名称上保持同步.

四、gitflow分支管理策略

企业中,分支决不能想创建就创建,想删除就删除,必须要遵循一定的规范和约定,那么分支管理策略就诞生了.
gitflow 最完善,最严格,最复杂的分支管理策略.

分支定义

Git Flow 是最早出现也是最经典的一种分支管理策略,它由两个长期分支和三种类型的临时分支组成。
1、永久分支:
Master 分支 (product stable)
主分支。用于存放经过测试,完全稳定的代码。永远都是可发布分支。
Develop 分支
开发分支一开始从master分离而来,用于存放基本稳定的代码。当该分支代码稳定,可发布版本时,合并到master分支上。
2、临时分支
Feature 分支
功能模块分支,从dev分支分离而来,用于开发项目功能,当开发新功能时以
feature -xxx命名,开发完成后,合并到develop上,合并后删除自己。
Release 分支
版本预发布分支,当v2.0版本发布时,可以从develop分支签出release-2.0,进行测试,测试出现问题,在release-2.0.1进行修改,测试完毕后准备发布将代码合并至master分支和develop分支上,给master打上v2.0.1的标签,合并后删除自己,这样做可以不影响下个版本功能的开发。
Hotfix 分支
线上紧急bug修复的分支,命名为hotfix-xxx,修改完成后,合并到master分支和develop分支,合并到master后打上修复版本的tag,合并后删除自己。
【git分支管理策略】_第1张图片

gitflow分支管理策略评价

Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。
更大问题在于,这个模式是基于"版本发布"的,目标是一段时间以后产出一个新版本。但是,很多网站项目是"持续发布",代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。
所以一般网站项目不采用gitflow分支管理策略,而严格版本发布的项目比如游戏,可能采纳gitflow更多.

五、GITHUB FLOW分支管理策略

相比于gitflow的繁重和复杂,github flow可谓是轻盈小巧.其核心目的就是应对长期持续发布的项目.

分支使用流程

和gitflow不太一样,github减轻了流程的重量,只有一个长期分支master,并且没有复杂的短期分支release hotfix.

创建分支(Create a branch)

在你开发任何新功能完成之前,都在当前版本创建一个新分支,这时不需要管其他开发者在做什么.但是你的新分支最好具有具体的功能描述命名,让其他开发者一看就知道他在干什么.
【git分支管理策略】_第2张图片

新增提交(add and commit)

【git分支管理策略】_第3张图片
只要你创建了分支,就说明你要对它进行修改啦!无论添加、修改、还是删除文件,你都必须进行提交,将它们同步到你的分支上。当你在分支上工作的时候,这些提交操作可以跟踪你的工作进度。
提交操作也建立一个关于你工作的透明历史,通过查看这些提交记录,其他人可以知道你做了什么和为什么这么做。每个提交操作都有一个相关的提交信息(Commit messages),用于描述你做出的修改。此外, 每一个提交操作都被视为一个“修改单元”。如果发现了 bug 或者决定走不同的开发方向,你也可以通过这些“修改单元”进行回滚操作。
提示(ProTip)
提交信息非常的重要,特别是当你将修改的内容提交到服务器之后,Git 可以追踪到你的修改内容并展示它们。通过写清楚的提交信息,你可以让其他人更容易跟上我们的思路并提供反馈。

提出 Pull 请求(Open a pull request)

当你的开发实现了阶段性内容的时候,可以提交pull request.等待审核人员审核.
【git分支管理策略】_第4张图片

讨论和评估你的代码(Discuss and review your code)

当你提出 Pull 请求的时候,审查你的更改内容的人或团队可能有一些问题或者意见。也许你的编码风格与项目规范不符,或者缺少单元测试,也有可能所有的东西看起来都很棒,条理清晰。Pull 请求的目的就是鼓励和捕捉这种类型的对话。
你也可以在大家讨论和给出关于你提交内容的反馈时,继续 Push 你的分支。如果有人评论说你什么没有做,或者代码中有 bug,你也可以及时把它修复,然后 Push 这些修改。GitHub 将会给你展示出最新评论和反馈,你也可以在 Pull 请求的视图中统一接收这些消息。
【git分支管理策略】_第5张图片

部署(Deploy)

只要你的 Pull 请求被审查并且通过了你的测试,你就可以部署这些修改,在生产环境中验证她们。如果分支发生了问题,你也可以回滚到之前的状态。
【git分支管理策略】_第6张图片

合并(Merge)

现在, 你修改的内容已经在生产环境中验证了,是时候将你的代码合并到master分支啦!合并之后,Pull 请求就保存了一份关于你修改代码的历史记录。因为它们是可搜索的,所有任何人都可以通过搜索了解你为什么这么修改以及如何修改的。
【git分支管理策略】_第7张图片

github flow分支关了策略评价

Github flow 的最大优点就是简单,对于"持续发布"的产品,可以说是最合适的流程。
问题在于它的假设:master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。
可是,有些时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master分支。
上面这种情况,只有master一个主分支就不够用了。通常,你不得不在master分支以外,另外新建一production分支跟踪线上版本。

六、GITLAB FLOW分支管理策略

分支定义

工作流提供了一种简单、透明和有效的 git 工作方式,并与问题跟踪系统相结合。
可以说是gitflow和github flow的综合体现.
GitLab 推荐用生产分支来解决上述问题:
【git分支管理策略】_第8张图片
Gitlab flow 的最大原则叫做"上游优先"(upsteam first),即只存在一个主分支(开发环境)develop,它是所有其他分支的"上游"。只有上游分支采纳的代码变化,才能应用到其他分支。

分支使用方案

  • 持续发布
    对于"持续发布"的项目,它建议在develop分支以外,再建立不同的环境分支。比如,"开发环境"的分支是develop,“预发环境"的分支是pre-production,“生产环境"的分支是production。
    开发分支是预发分支的"上游”,预发分支又是生产分支的"上游”。代码的变化,必须由"上游"向"下游"发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到develop,确认没有问题,再cherry-pick到pre-production,这一步也没有问题,才进入production。
    只有紧急情况,才允许跳过上游,直接合并到下游分支。
  • 版本发布
    对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从develop分支拉出一个分支,比如2-3-stable、2-4-stable等等。
    以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。
  • gitlab flow分支管理策略的缺点
    命名没有严格的规范,只要遵循易读原则。

总结

通过实施有效的 Git 分支策略,团队可以更好地管理代码更改、提高协作效率并降低错误风险。随着项目的发展和团队规模的扩大,持续改进分支策略将有助于确保项目的成功和维护的顺利进行。

你可能感兴趣的:(git,java,intellij,idea,网络)