Git分支

简介: Git分支的模型的优越性,是Git脱颖而出的关键

 几乎所有的版本控制系统以某种形式支持分支

使用分支意味着你可以把你的工作从主线分列开来

在很多版本控制系统中,因为需要创建一个源代码目录的副本

所以既会浪费空间、又会耗费很多时间。

有人把Git分支的模型,称之为大杀器。也正是因为这一特性,让Git从众多版本控制中脱颖而出。

Git为何如此的出众呢?是因为Git处理分支的方式可谓是难以置信的清亮。Git创建分支,几乎可以在一瞬间完成。并且分支之间的切换及其的便捷。

因此,Git 鼓励在工作流中频繁的使用分支与合并。


官网上是这么说的:

理解和精通这一特性(鼓励频繁使用分支与合并),你便会意识到 Git 是如此的强大而又独特,并且从此真正改变你的开发方式。


那为何Git有这样的特性呢?

分支简介:

Git 保存的不是文件之间的差异,而是一些快照。

当你进行commit提交时,你会创建一个提交对象,而这个提交对象里面存储的是提交者的姓名、邮箱、提交时携带的信息、以及指向父节点的指针。

我知道,这听起来有点抽象。举个例子:

假如你把如下:

README test.rb LICENSE

image.gif

这三个文件存入暂存区,并提交。

$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'

image.gif

当你存入暂存区时,会发生这些:

首先,Git会把内容,以快照的形式存入git仓库中的blob,并且会用(SHA-1哈希算法)计算出校验和(唯一标识),并将这个校验和放入暂存区。注意⚠️,放在暂存区的是这个唯一标识,不是修改的具体内容。

紧接着,文件会计算出子目录的校验和,放在树对象中,而这个对象,里面存储的是,子目录下各个文件的blob的唯一标识。

注意,tree对象中,存储的是目录结构和blob对象索引。

只是各个文件之间的关系,而不储存具体内容。

存储具体内容(快照)的工作,是git仓库做的事。

最后提交对象(commit)会指向tree对象。

三者的关系是:commit -> tree -> blob/子树

image.gif

而每次提交都会产生commit对象,并且指针指向父节点(上一次提交的commit对象)。

注意,若你是第一次提交,则你不会拥有父节点,因为你本身就是跟节点

image.gif

当然还有特殊情况,如果此时你刚刚进行了不同分支之间的合并,那么,你将会有多个父节点。

分支创建:

要谨记,master不是一个特殊的分支,他与其他分支一样,只不过git init 的时候,默认建立了这个分支。算是约定俗成吧。

image.gif

创建一个新的testing分支

$ git branch testing

image.gif

image.gif

其中HEAD是指,此时你正在处于哪个分支。

image.gif

想信此刻,你对一下代码,已经不在感到陌生与害怕了吧😉😁

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

image.gif

由于 Git 的分支实质上仅是包含所指对象校验和(长度为 40 的 SHA-1 值字符串)的文件,所以它的创建和销毁都异常高效。

创建一个新分支就相当于往一个文件中写入 41 个字节(40 个字符和 1 个换行符),如此的简单能不快吗?

这也是为什么鼓励创建分支....


https://git-scm.com/book/zh/v2 (Git官网)


接下来就是个人技术专栏,里面记录了几个简单且常用的命令:

在往gitee上推送时:

image.gif

大家推送远程仓库的时候,一般默认的都是origin。

这里是方便区分。如下github、gitee,其实你也可以自定义其他名字。

# GitHub 仓库
git remote add github git@github.com:user/repo.git
# Gitee 仓库
git remote add gitee git@gitee.com:user/repo.git

image.gif

# 同时推送到两个平台
git push github main && git push gitee main

image.gif

遇到过的问题:

首先(两件套)

git add . # 暂存
git commit -m # 提交版本号

image.gif

1、拉取远程分支

git pull origin develop

image.gif

2、合并本地分支

git merge develop

image.gif

(有冲突的时候,用如下方式解决)

  • 打开冲突文件,手动删除 Git 标记(<<<<<<<=======>>>>>>>),保留需要的代码。

并且你要明白git merge  会保留“分叉历史” 。

                     git rebase 会将提交记录合并,变成线性的。

3、推送

git push origin feature/wdx

image.gif

4、对分支的常见操作

git branch
git checkout develop

image.gif

切记旧版本,无法覆盖新的版本。


历程:

2025/07/29:发布博客,并记录了分支简介/创建

2025/09/21:遇到了奇葩的分支,得此感悟(旧版本不可覆盖新版本),故来完善


借鉴:

1、https://git-scm.com/book/zh/v2 (Git官网)



目录
相关文章
|
1月前
|
网络安全 Go Docker
CI/CD全流程
记录 后端go 算法平台 / python 爬虫网关 / 前端vue项目 CI-CD部署流程
280 8
|
1月前
|
缓存 安全 测试技术
GO项目开发规范文档解读
本篇博客的目的,更多是为快速翻阅与回忆使用。
188 1
|
1月前
|
存储 缓存 安全
一文带你读懂 Go 1.24 map 重构了什么?
本文聚焦 Go 1.24 map 底层重构,解释它如何从旧版 bucket + overflow 方案,演进为 Swiss Table + 局部 split 的新结构,以及它所带来的性能提升。
184 1
一文带你读懂 Go 1.24 map 重构了什么?
|
1月前
|
设计模式 Java Go
Go中的switch的8种使用场景:没有你想的那么简单
在 Go 中灵活使用 switch,可以使代码更清晰、更易维护。 switch 是 Go 中不可或缺的控制结构之一
831 1
|
1月前
|
SQL Go
Go反射指南
反射与接口息息相关
131 2
|
1月前
|
算法
动态规划-01背包
本文深入解析动态规划经典问题——01背包及其四大变式:分割等和子集、最后一块石头的重量II、目标和、一和零。从暴力回溯切入,对比O(2ⁿ)与O(N·W)动态规划解法,详解状态定义、递推公式、二维/一维滚动数组优化,并配以清晰代码与图示,助你透彻掌握背包问题核心思想与实战技巧。
207 1
|
1月前
|
存储 数据库连接 Go
项目跑起来之前的那些事
项目运行前都需要怎么设计?做那些准备呢?本篇博客将会拆解 Go 应用启动的核心代码逻辑
91 1
|
1月前
动态规划之打家劫舍
最后在此,送坚持到这里的读者一句话。简单题,用来培养方法;难题,用来突破自我;两者结合,方能突破至高;当难题,难得你受不了时,恰恰是因为你没有重视简单题!希望大家有所收获。
102 1
|
1月前
|
算法
动态规划之完全背包
本文详解完全背包问题:作为动态规划经典题型,区别于01背包(每物限选1次),其特点是每种物品可无限次选取。文章从定义、状态转移方程(dp[i][j] = max(dp[i-1][j], dp[i][j-w]+v))、二维/一维实现到遍历顺序对组合数与排列数的影响,结合零钱兑换II、组合总和IV等5道典型例题深入剖析,助力掌握核心思想与编码技巧。
196 1
|
1月前
|
NoSQL 关系型数据库 MySQL
面向对象的七大设计原则
经艺术设计过的接口,就像蝴蝶一样在指尖翩翩起舞,令人沉醉....
108 0