Git分支:什么是分支,如何管理分支?

一、前言

如果有人问你,当下最流行的“版本管理系统”(Version Control System)是什么,那你一定要毫不犹豫的告诉他,非Git莫属。

在这里插入图片描述

Git

相比同类软件,Git有很多优点。其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便。有些传统的版本管理软件,分支操作实际上会生成一份现有的代码的物理拷贝,而Git只生成一个指向当前版本(又称”快照“)的指针,因此非常快捷易用。
但是,太方便了也会产生副作用,如果你不注意,很可能留下一个到处都是分支,完全看不出主干发展的脉络。而本篇文章正是为了避免开发分支混乱而生。

在这里插入图片描述

二、分支管理

1.历史分支

相对使用仅有的一个master分支,Gitflow工作流使用2个分支来记录项目的历史。master储存正式发布的历史,develop分支作为功能的集成分支。这样也方便master分支上的所有提交分配一个版本号。

在这里插入图片描述

2.功能分支

每个新功能位于一个自己的分支,这样可以push到中央仓库以备份和协作。但功能分支不是从master分支上拉出来的新分支,而是使用develop分支作为父分支。当新功能完成时,合并回develop分支。新功能的提交不直接与master交互。


在这里插入图片描述

3.发布分支

一旦develop分支上的功能到了发布日期,就从develop分支fork一个发布分支(一般叫release)。release分支用于预发布测试,所以从这个时间点开始后新的功能不再加到这个分支上,release分支只应该做bug修复、文档生成和其他面向发布的任务。一旦release测试完毕并准备发布后,将其合并到master分支并分配一个版本号打上Tag。另外,release上做的bug修改要合并回develop分支。
使用一个专门用于发布的分支,是一个团队可以在完善发布版本的同时,另一个团队继续开发下一个版本功能。


在这里插入图片描述

4.维护分支

维护分支(一般叫hotfix)是唯一可以直接从master分支fork出来的分支,用于线上版本bug修复。修复完成后,应马上合并回master和develop分支,同时master分支用新版本号打上Tag。


在这里插入图片描述

结语

通过上面几个图文的解释,大家是不是都明白了呢,其实Git分支并不复杂,无非是master(线上),develop(开发),release(预发布),hotfix(线上bug修复)这四种常用的分支,只要理解他们的作用和应用场景并实践于工作中,相信一定会提高开发效率,降低管理成本。下一篇我将通过具体案例来讲解分支在日常团队开发中的具体应用,同时介绍一些git常用命令行。我们下期再见~

hello大家好,昨天我已经讲了Git分支的理论部分没有看的同学请点击这里Git分支那点事儿(上):什么是分支,如何管理分支?,马克思爷爷说过,理论要与实践相结合,那么今天,我们就以在办公中常见的开发场景为例,来具体介绍分支的用法,同时附带一些简单的Git指令,下面让我们开始吧~

一、新项目来啦

公司里来了一个新项目,大A是开发组长,小b小c是开发组员,接到任务后,大A首先在中央仓库建立一个项目仓库,master为主分支,然后大A在本地为master配套一个develop分支,push到服务器上

在这里插入图片描述

git branch develop
git push -u origin develop

以后develop分支将会包含项目的全部历史,而master只包含部分历史。当小b和小c需要开发时,他们应该先链接中央仓库,然后检出develop分支

git checkout -b develop origin/develop

checkout命令加 -b 代表创建并切换,相当于以下两条命令

git branch develop
git checkout develop

二、小b和小c开始开发新功能

大A给小b小c分配完任务后,他们开始各自的开发,这时,他们需要为各自的功能创建相应的分支,新的分支应基于develop分支,而不是master分支。

在这里插入图片描述

git branch branch-name develop

这里的branch-name自己可以随意定义名称,但是千万别用test,因为我试过,这个名字非法,哈哈哈

三、小b小c完成功能开发

开发功能完成后,小b小c觉得功能ok了,这时候他们就可以把自己的分支合并到develop上,然后push到中央仓库

在这里插入图片描述

git pull origin develop
git checkout develop
git merge branch-name
git push
//如果觉得当前分支不需要了,可以执行
git branch -d branch-name

第一条pull,是确保在合并功能前develop分支是最新的,注意,功能只能合并到develop分支

四、组长准备功能发布

组长大A在看到组员功能完成后,准备发布第一个功能测试版本


在这里插入图片描述

git branch release/v0.1.0 develop

这个分支是清理发布、执行所有测试、更新文档的地方,一个用于专门改善发布功能的分支。
只要把这个分支push到中央仓库,这个分支的功能就是冻结的。任何在develop的分支中的新功能都推到下一个release中

五、完成发布

一旦release测试完毕,这是,需要将release合并到master上,修改后的release同时也要合并回develop上,因为改好的功能在以后的develop分上也要体现出来

在这里插入图片描述

git checkout master
git merge release/0.1.0
git push
git checkout develop
git merge release/0.1.0
git push
git branch -d release/0.1.0

在release合并到master后,还要给master分支打tag以方便跟踪。

git tag -a v0.1.0 -m "initial public release" master
git push --tags

六、用户发现bug

对外发布后,发现有bug,为了处理bug,小b(小c)从master分支拉出来一个hotfix维护分支,提交修改以解决问题,然后直接合并回master和develop分支

在这里插入图片描述


合并完毕后,删除hotfix分支。

最后推荐一个可视化的git工具,SourceTree,方便新手同学使用

<think>好的,用户现在问的是版本控制工具是什么意思,以及Git是用来做什么的。之前用户已经问过框架的相关问题,可能他现在在逐步学习软件开发的基础工具和概念。首先,我需要确定用户对版本控制是否完全不了解,还是有一些基础。从他的提问来看,可能是个刚入门的开发者,所以需要从基本概念讲起。 版本控制工具的定义是必须的,但要简明扼要,避免太技术化。需要解释为什么需要版本控制,比如团队协作、历史记录、回退等。然后要区分集中式和分布式,因为Git是分布式的,这点可能对用户来说很重要。 接下来,用户问到了Git的具体用途。这里需要将Git和版本控制工具的关系说清楚,Git是最流行的分布式版本控制系统。要列举Git的主要功能,比如跟踪变更、分支管理、远程协作等。最好用一些例子,比如代码回退、分支合并,这样用户更容易理解。 还要考虑用户可能的后续问题,比如GitGitHub的区别,或者基本命令的使用,但当前问题不需要深入这些细节,但可以稍微提到,帮助用户建立整体认识。同时,强调Git的优势,比如高效、灵活,适合各种规模的项目,这样用户能明白为什么Git如此受欢迎。 用户之前的问题是关于框架的,现在转向版本控制,可能他正在系统学习开发流程。因此,可能需要强调版本控制工具在团队协作和项目管理中的重要性,而Git作为其中的核心工具,是必须掌握的技能。 需要避免使用过多专业术语,用日常例子来比喻,比如版本控制就像写论文时的不同版本保存,这样用户更容易联想。同时,注意结构清晰,分点说明,让回答更有条理。 最后,检查是否有遗漏的重要点,比如Git的基本工作流程(工作区、暂存区、仓库),或者常用命令(commit, push, pull),但根据问题,可能不需要详细展开,只要概括即可。确保回答准确,同时易于理解,符合初学者的认知水平。**</think>版本控制工具**是用于 **追踪和管理文件变更历史** 的软件,它能记录文件每一次修改的内容、时间和作者,并支持回退到任意历史版本。在软件开发中,它尤其重要,因为代码需要频繁迭代,且多人协作时需避免冲突。 --- ### **为什么需要版本控制?** 1. **历史追溯** - 查看代码如何从 V1.0 演进到 V2.0,定位 Bug 何时引入。 2. **团队协作** - 多人同时修改同一文件时,自动合并变更或提示冲突。 3. **安全回退** - 若新代码导致故障,可快速恢复到稳定版本。 4. **分支管理** - 并行开发多个功能(如开发新功能时修复紧急 Bug)。 --- ### **版本控制工具分类** - **集中式**(如 SVN): 所有文件历史存储在中央服务器,用户需联网提交代码。 - **分布式**(如 **Git**): 每个用户本地都有完整仓库,可离线工作,再与服务器同步。 --- ### **Git 是什么?** Git 是当前最流行的 **分布式版本控制工具**,由 Linux 之父 Linus Torvalds 开发,最初用于管理 Linux 内核代码。 #### **Git 的核心功能** 1. **跟踪文件变更** - 记录代码增删改的细节,精确到行级。 - 示例:修改代码后,用 `git commit` 保存当前快照。 2. **分支与合并** - 创建独立分支开发新功能,完成后合并到主分支。 - 示例:`git branch new-feature` → 开发 → `git merge new-feature`。 3. **远程协作** - 通过 GitHub、GitLab 等平台,多人共享代码并同步变更。 - 示例:`git push` 上传代码,`git pull` 下载他人代码。 4. **回退与修复** - 撤销错误提交,或从历史版本恢复文件。 - 示例:`git reset --hard commit_id` 回退到指定版本。 --- ### **Git 的典型使用场景** 1. **个人项目** - 本地记录代码修改历史,防止误删或覆盖。 2. **团队开发** - 多人通过 Git 提交代码,解决冲突后合并到主分支。 3. **开源贡献** - 从 GitHub 克隆(`git clone`)开源项目,修改后提交 Pull Request。 --- ### **Git vs 其他工具(如 SVN)** | 特性 | Git(分布式) | SVN(集中式) | |--|--------------------| | **网络依赖** | 可离线操作 | 必须联网提交 | | **速度** | 本地操作,更快 | 依赖服务器,较慢 | | **数据安全** | 每个用户有完整备份 | 服务器单点故障风险 | | **学习成本** | 较高(命令较多) | 较低(操作简单) | --- ### **Git 基本概念** - **仓库(Repository)**:代码存储的目录,包含所有历史记录。 - **提交(Commit)**:一次变更的保存,类似“存档点”。 - **分支(Branch)**:独立开发线,默认主分支为 `main` 或 `master`
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

゛Smlie。

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值