核心内容摘要
八股文四（sql篇）
在现代软件开发中Git 已经成为版本控制的事实标准。
而 Git 的精髓无疑在于其强大而轻量的分支管理能力。
要想真正地、高效地利用 Git 进行团队协作和项目管理就必须深入理解其分支的底层工作机制。
这篇笔记将从 Git 的核心指针HEAD开始层层递进详细探讨分支的创建、合并、冲突解决并结合企业级开发流程分享包括--no-ff合并策略、git stash应急处理等在内的实战技巧。
Git 分支的核心机制与底层原理许多初学者对 Git 分支的理解停留在“复制一份项目代码”的层面这其实是一个误区。
Git 分支的高效性恰恰在于它几乎不产生任何文件复制的开销。
要揭开这个谜底我们必须从两个核心概念入手HEAD指针和分支的本质。
1 HEAD 指针与分支的本质在每一个 Git 仓库的.git目录下都存在一个至关重要的文件名为HEAD。
这个HEAD文件是一个指针它并不直接指向某一次具体的代码提交Commit而是指向当前我们正在工作的那个本地分支。
通常在初始化一个新仓库后HEAD会默认指向master或现在更常见的main分支。
HEAD文件的内容非常直白它记录了一个引用路径。
我们可以通过命令直接查看它的内容从而验证它的指向。
cat.git/HEAD执行该命令后通常会看到类似ref: refs/heads/master的输出。
这行文本明确地告诉我们HEAD当前正引用着refs/heads/master这个路径也就是master分支。
那么master分支本身又是什么呢在 Git 中“分支”并不是一个复杂的结构它同样是一个指针。
具体来说它是一个指向某次特定提交对象Commit Object的引用。
这个引用信息被存储在.git/refs/heads/目录下的同名文件中。
例如master分支的指针信息就存放在.git/refs/heads/master文件里。
这个文件里面记录的正是一个 40 个字符长度的 SHA-1 哈希值该哈希值唯一标识了master分支当前最新的那一次提交。
通过以下命令我们可以看到master分支指向的具体提交哈希cat.git/refs/heads/master这个哈希值961b
..就代表了当前master分支的“顶端”或“最新状态”。
所以整个关系链条是这样的我们通过 Git 命令工作。
HEAD指针告诉 Git 我们当前在哪一个分支上工作例如master。
分支指针例如master告诉 Git 这条分支的最新提交是哪一个。
每一次新的提交都会让当前分支的指针向前移动指向这个最新的提交。
这个指针系统是理解 Git 分支操作一切行为的基础。
无论是创建分支、切换分支还是合并分支其底层逻辑都是对这些指针文件进行读写操作而非大规模地复制工作目录中的文件。
分支的创建、切换与合并实战掌握了底层原理后我们来实际操作并观察 Git 内部发生了什么变化。
1 查看与创建分支首先使用git branch命令可以查看当前仓库中所有的本地分支并明确HEAD指针的指向。
gitbranch输出结果中master前面的*号是一个清晰的标识它表明HEAD指针当前正指向master分支。
这意味着我们后续的任何提交都将发生在master分支上。
接下来我们创建一个名为dev的新分支用于后续的开发工作。
gitbranch dev执行git branch dev命令后再次运行git branch会发现多了一个dev分支但*号依然在master前面。
这说明创建分支的操作并不会自动切换过去。
HEAD指针的位置没有发生改变。
那么git branch dev这个命令在底层究竟做了什么我们可以通过检查.git目录的内部结构来一探究竟。
tree .git/在.git/refs/heads/目录下可以观察到一个新文件dev被创建了出来与master文件并列。
这两个文件分别代表了两个分支的指针。
我们可以进一步查看它们的内容。
通过对比master和dev两个文件的内容可以发现它们存储的哈希值是完全一样的。
这揭示了创建分支的真相git branch branch-name命令仅仅是创建了一个新的指针文件并将当前分支指针的哈希值复制了过去。
在这一瞬间新分支dev和旧分支master指向的是同一个、完全相同的提交。
这个操作的成本极低几乎是瞬时完成的因为它不涉及任何工作区文件的复制。
这就是 Git 分支如此“廉价”和高效的根本原因。
2 切换分支与工作区隔离要在dev分支上进行开发必须先将HEAD指针切换过去指向dev。
这个操作由git checkout命令完成。
gitcheckout dev执行后再次查看分支状态。
gitbranch可以看到*号已经移动到了dev分支前面表示HEAD现在指向了dev。
git checkout命令主要做了两件事修改.git/HEAD文件的内容使其从ref: refs/heads/master变为ref: refs/heads/dev。
根据dev分支指向的提交快照更新工作目录中的文件内容。
由于此时dev和master指向同一个提交所以工作区的文件内容不会有任何变化。
3 在分支上独立开发现在我们处于dev分支可以安全地进行开发。
比如修改README文件并添加一行新内容。
修改完成后执行标准的git add和git commit流程将这次更改提交到版本库。
gitaddREADMEgitcommit -madd new feature on dev这次提交完成后Git 的内部状态发生了重要变化一个新的提交对象被创建。
由于HEAD指向dev所以dev分支的指针.git/refs/heads/dev文件中的哈希值被更新指向了这个新的提交对象。
master分支的指针则保持不变仍指向原来的提交。
至此dev分支已经领先于master分支一个提交两条分支的路径开始分叉。
4 分支隔离性的体现为了验证分支之间的隔离效果我们现在切换回master分支。
gitcheckout master切换成功后再次查看README文件的内容会发现我们在dev分支上添加的那行代码消失了。
这并非代码丢失而是 Git 在执行checkout时忠实地将工作区恢复到了master分支指针所指向的那个提交快照的状态。
这完美地展示了分支的隔离性——在一个分支上的修改不会影响到另一个分支。
git checkout命令的核心作用之一就是根据目标分支指针的位置精确地重置工作区的文件内容。
5 分支合并Fast-forward 模式当dev分支上的功能开发完毕并测试通过后就需要将其成果整合回主分支master。
这个过程就是“合并”Merge。
合并操作的一个重要前提是必须先切换到接收合并的目标分支。
在这个场景里我们的目标是让master分支包含dev的成果所以需要先切换到master分支。
gitcheckout mastergitmerge dev观察命令输出会看到一个关键信息“Fast-forward”。
这是一种特殊的、最简单的合并模式被称为“快进模式”。
它能够发生是基于一个特定的前提条件从dev分支创建以来master分支本身没有产生任何新的提交。
换句话说dev分支的历史记录完全包含了master分支的历史并且是它的直接下游。
在这种情况下Git 不需要进行复杂的计算或创建新的提交。
它所做的仅仅是将master分支的指针直接向前移动指向dev分支当前所指向的同一个提交。
合并完成后master和dev两个分支再次指向了同一个提交。
master分支已经成功吸收了dev分支的所有开发成果。
6 删除已合并分支既然dev分支的工作已经全部整合到master中它的历史使命就完成了。
为了保持仓库的整洁通常会删除这些已经完成任务的短期分支。
gitbranch -d dev注意Git 不允许删除当前所在的分支。
执行此命令前必须确保自己不在dev分支上我们已经在master分支了所以是安全的。
-d选项是--delete的缩写它会进行安全检查只允许删除已经被完全合并到当前分支的分支。
删除分支的操作在底层同样非常轻量它只是删除了.git/refs/heads/dev这个指针文件而已。
那些在dev分支上创建的提交对象并不会被删除因为它们现在正被master分支引用着是master历史的一部分。
处理合并冲突Fast-forward 合并是一种理想情况。
在真实的团队协作中更常见的情况是当你在dev分支开发时其他同事可能已经向master分支提交了新的代码。
这时master和dev分支的历史就出现了真正的分叉直接合并就会引发“冲突”。
1 制造冲突场景让我们来模拟这个过程在master分支修改文件首先切换到master分支修改README文件添加一行内容如 “test for conflict on master”然后提交。
在dev分支修改同一文件切换到dev分支在README文件的同一位置修改添加一行不同内容如 “test for conflict on dev”然后提交。
现在master和dev在同一个文件的同一个地方各自拥有了不同的修改。
Git 在合并时将无法自动决定应该保留哪个版本。
2 触发并识别冲突回到master分支尝试合并dev。
gitcheckout mastergitmerge devGit 会明确提示“CONFLICT”并告知冲突发生在哪个文件README。
此时合并过程被中断Git 会等待我们手动解决冲突。
打开README文件会看到 Git 插入的特殊标记用以标示冲突区域 HEAD test for conflict on master test for conflict on dev dev HEAD到之间的内容是当前分支即master因为HEAD指向它的修改。
到 dev之间的内容是来自被合并分支dev的修改。
3 手动解决冲突并提交解决冲突的过程本质上就是一次代码编辑。
我们需要做的就是打开冲突文件。
根据业务需求决定最终要保留的代码。
这可能意味着保留HEAD版本或保留dev版本或者将两者结合甚至写一段全新的代码。
手动删除 Git 插入的所有冲突标记(,,)。
保存文件。
解决完成后需要将这个“解决后”的文件状态告知 Git。
这通过git add命令完成。
gitaddREADME最后执行git commit来完成这次合并。
Git 会自动生成一个默认的提交信息如 “Merge branch ‘dev’”。
这次提交非常特殊它是一个“合并提交”Merge Commit它会有两个父提交分别指向合并前的master分支顶端和dev分支顶端从而将两条分叉的历史线汇合在一起。
使用带图形化参数的git log命令可以非常直观地看到这种分叉和汇合的拓扑结构gitlog --graph --prettyoneline --abbrev-commit
合并模式Fast-forward 与 --no-ff 的选择
1 Fast-forward 的隐患虽然 Fast-forward 模式合并后的历史记录非常整洁呈一条直线但它有一个显著的缺点丢失了分支信息。
一旦执行了 Fast-forward 合并并删除了开发分支从提交历史上将完全看不出某段开发曾经是在一个独立的分支上进行的。
所有的提交看起来都像是按顺序直接在master上完成的。
这对于需要进行代码审查、版本回溯、或者追溯某个功能是由哪个开发分支引入的团队来说是不利的。
2 使用--no-ff强制创建合并提交为了保留完整的分支历史即使在可以 Fast-forward 的情况下我们也可以强制 Git 创建一个合并提交。
这通过在merge命令后添加--no-ffNo Fast Forward参数来实现。
gitmerge --no-ff -mMerge feature-branch, preserving historydev使用--no-ff参数后Git 会执行一次标准的三方合并并生成一个新的合并提交即使master分支没有动过。
这样做的好处是从提交历史的拓扑图中可以清晰地看到每一次功能的集成点每一次分支的开启与闭合都一目了然极大地提高了项目历史的可读性和可追溯性。
在团队协作中推荐优先使用--no-ff模式进行功能分支的合并。
企业级分支策略与实战流程在个人项目中分支管理可能比较随意。
但在团队协作中必须遵循一套清晰、规范的分支策略以确保开发的有序和代码库的稳定。
Git Flow 是业界一种非常流行且成熟的分支管理模型。
Git Flow 模型定义了几个关键分支各自承担不同职责Master (或 Main)主分支。
存放的是随时可以部署到生产环境的、最稳定版本的代码。
任何时候都不允许直接在该分支上进行开发。
代码来源只能是从其他分支合并。
Develop (或 Dev)开发主分支。
它是所有功能开发的汇集点包含了项目最新的、但尚未发布的功能。
可以看作是“集成了所有功能的预发布版”。
Feature功能分支。
这是开发者日常工作的主要阵地。
每当要开发一个新功能时都应从Develop分支拉出一个新的Feature分支如feature/user-login。
开发完成后再合并回Develop分支。
Release发布分支。
当Develop分支上的功能积累到一定程度准备发布一个新版本时会从Develop拉出一个Release分支。
在这个分支上只进行 Bug 修复、文档生成等与发布相关的收尾工作不再添加新功能。
发布完成后Release分支需要同时合并到Master和Develop分支。
Hotfix热修复分支。
当线上Master分支出现紧急 Bug 需要立即修复时应从Master分支拉出一个Hotfix分支。
修复完成后同样需要将Hotfix分支同时合并回Master和Develop分支以确保开发分支也包含了此修复。
现场急救Bug 分支与 Stash 功能开发过程中一个常见的紧急情况是正在feature分支上开发一个复杂功能代码写了一半状态混乱无法提交。
但此时线上突然出现一个紧急 Bug 需要立刻修复。
如果直接切换分支未提交的修改可能会带到master分支造成污染甚至因为文件冲突导致切换失败。
这时git stash就派上了用场。
1 使用git stash保存现场git stash命令可以将当前工作区和暂存区的修改内容“储藏”起来让工作区恢复到上一次提交时的干净状态。
假设我们当前在dev分支并且对README文件做了一些修改但工作尚未完成。
此时执行git stash。
gitstash执行后Git 会将我们的修改打包存放在一个“储藏栈”中并提示Saved working directory and index state...。
此时再次查看工作区状态会发现它变得“clean”了。
现在工作区是干净的可以安全地切换到任何其他分支去处理紧急任务。
2 创建并修复 Bug遵循规范我们不能直接在master上修改。
正确的流程是切换到master分支。
从master拉出一个临时的FixBug分支。
gitcheckout mastergitcheckout -b FixBug在这个FixBug分支上进行 Bug 修复然后提交。
修复完成后切换回master分支将FixBug分支合并进来并推荐使用--no-ff以保留修复历史。
最后删除临时的FixBug分支。
# ...修复并提交...gitcheckout mastergitmerge --no-ff -mFix critical bug #123FixBuggitbranch -d FixBug
3 恢复现场与同步修复紧急任务处理完毕我们需要回到dev分支继续之前的工作。
gitcheckout dev切换回来后执行git stash pop来恢复之前储藏的工作内容。
gitstash popgit stash pop命令会做两件事将储藏栈顶的内容恢复到工作区。
从储藏栈中删除这条记录。
如果只想恢复而不删除可以使用git stash apply工作现场恢复了但此时存在一个重要问题master分支已经包含了 Bug 修复而我们的dev分支是从旧的master拉出来的它并不知道这个修复的存在。
最佳实践是在继续开发前主动在dev分支上合并master分支将线上的修复同步到当前的开发分支中。
gitmerge master这样操作后dev分支就既包含了我们正在开发的新功能也同步了线上的 Bug 修复避免了未来合并时可能出现的冲突或 Bug 回归问题。
强制删除分支前面提到git branch -d是一个安全命令它会阻止我们删除未被合并的分支。
Git 会报错并提示该分支的工作“not fully merged”。
这是 Git 的一种保护机制防止我们意外丢失代码。
但在某些情况下我们确实需要放弃某个分支上的所有工作比如一个失败的功能尝试。
这时可以使用大写的-D参数进行强制删除。
gitbranch -D dev3git branch -D会无视分支的合并状态直接、彻底地删除该分支指针。
该分支上独有的、未被任何其他分支引用的提交将会变成“悬空”状态并在未来某个时间被 Git 的垃圾回收机制清理掉。
这是一个不可逆的危险操作使用前必须三思。