企业官网建设流程全解析

深圳微商城网站设计多少钱,广州微信网站建设,阿里云做网站的代码,用shopify 做网站文章目录Git仓库基本结构Git 提交的基础操作Git 版本库的底层存储结构Git 提交的完整逻辑链路Git 提交的完整逻辑链路常见误区总结结语上一篇博客我们创建了一个Git仓库#xff0c;这篇博客我们就来一起讨论Git的添加与修改命令及其具体原理。 上一篇博客传送门#xff1a;G…文章目录Git仓库基本结构Git 提交的基础操作Git 版本库的底层存储结构Git 提交的完整逻辑链路Git 提交的完整逻辑链路常见误区总结结语上一篇博客我们创建了一个Git仓库这篇博客我们就来一起讨论Git的添加与修改命令及其具体原理。上一篇博客传送门Git的从零全平台安装配置与 Unity 项目配置Git仓库基本结构我们在这之前来讲一个糖猫米雪儿的故事吧米雪儿把欧泊的战斗数据文件拖进了战斗数据管理的Git仓库文件夹就一溜烟找小熊玩耍去了。隔天信黑着脸来找她要昨天的战斗记录翻遍仓库却一无所获。米雪儿叉着腰气鼓鼓地甩甩尾巴“才不是我的问题喵我明明把数据拖进仓库文件夹里了肯定是你电脑出毛病啦”话音刚落信的脸色更沉一个闪身就消失在了原地留下一句 “自己守B吧”。于是米雪儿一人在B点凌乱~事后去找心夏问为什么回这样心夏揉了揉米雪儿的脑袋温柔又耐心地解释“Git仓库就像一个带‘登记台账’的专属档案柜——你把文件拖进柜子仓库文件夹只是把文件放在了档案柜的工作区却没在台账上登记‘这份文件归档案柜管理’执行git add git commit。这些没登记的文件就像游离在档案柜规则外的‘无主文件’Git既不会追踪它的修改也不会把它同步到远端仓库信那边自然查不到啦。真正的Git仓库版本库认的是台账上登记过的文件可不是单纯放在柜子里的文件哦。”米雪儿的错误就是误以为把文件放到工作区文件就会被Git管理了但是实际上文件被Git管理要把文件放到版本库中我们可以用 Git 仓库的物理结构来理解。Git 仓库文件夹里除了隐藏的.git文件夹之外其余可见的部分都是工作区—— 这是我们日常操作文件的区域但在工作区里对文件的增删改并不会自动被 Git 记录和管理。只有通过git add git commit这两步操作文件的修改才会被存入版本库也就是.git隐藏文件夹真正纳入 Git 的版本管控。注意.git 文件夹是 Git 的核心文件目录git文件一定不能我们手动修改会导致我们当前的本地仓库直接爆炸Git之所以能实现精准的版本控制核心是通过版本库内部不同区域的分工协作把文件的每一次修改都“追踪”并“固化”下来。版本库.git目录内部主要包含三个关键功能区域它们各司其职共同完成版本的维护1. 对象库objects 图中绿色存储所有修改的“原始数据”对象库是Git版本控制的“数据仓库”工作区中每一次文件修改都会被封装成一个独立的Git对象存储在这里。这些对象记录的是文件修改的具体内容而非完整文件是版本控制的最小数据单元维护好这些对象就等同于保留了文件从创建到当前的所有修改轨迹这是Git实现版本追溯的基础。2. 暂存区stage/index 图中蓝色待提交修改的“临时索引”暂存区是工作区和分支之间的“中转站”我们常用的git add .命令本质就是把工作区中所有修改的文件“登记”到暂存区中。暂存区并不会存储Git对象本身而是以树状结构存储对象库中修改对象的索引引用这种“存索引不存数据”的设计让暂存区非常轻量既可以临时存放多个待提交的修改也能灵活调整要提交的内容。3. 分支图中master已确认版本的“正式索引”分支是Git版本的“最终载体”git commit命令的核心作用就是把暂存区中已确认的修改正式“提交”到当前分支如master下。和暂存区类似分支同样是树状结构的索引目录存储的是对象库中修改对象的索引版本库中有一个特殊的指针HEAD(图中橙色)它始终指向当前活跃的分支通过这个指针Git就能顺着分支的索引树找到对象库中所有相关的Git对象最终还原出对应版本的完整文件。简单说就是Git 版本控制的核心是 “数据对象库 索引暂存区 / 分支” 的分层设计数据存内容索引管关联git add 是 “把修改从工作区登记到暂存区更新索引”git commit 是 “把暂存区的索引固化到分支”通过HEAD 指针进行版本追溯的关键通过它能顺着分支→暂存区→对象库的链路还原任意版本的文件。Git 提交的基础操作1. 查看文件状态在执行git add之前建议先通过git status查看文件处于哪个区域这是避免操作失误的关键。# 完整格式展示文件状态gitstatus# 精简格式展示更易读推荐新手使用gitstatus -s状态解读红色文件处于工作区未执行git add绿色文件处于暂存区已执行git add未执行git commit无相关文件所有修改已提交到版本库。2. 暂存文件git addgit add的作用是将工作区的文件变更添加到暂存区Index这是提交前的必要步骤。gitadd[文件名]# 添加当前目录及子目录的所有变更文件新增、修改、删除gitadd.# 添加整个仓库的所有变更文件推荐跨目录操作时使用gitadd-A注意暂存区是工作区和版本库之间的“中转站”只有进入暂存区的变更才能被提交到版本库。git add .和git add -A的区别——前者只处理当前目录及子目录后者处理整个仓库的所有变更。比如在子目录执行git add .不会追踪上级目录的文件修改。3. 提交变更git commitgit commit会将暂存区的所有变更打包生成一个提交对象Commit Object并写入版本库同时更新当前分支的指针。# -m 后跟随提交说明必须清晰描述本次提交的内容gitcommit -m修复登录页表单验证bug# 若忘记加 -m会进入 vim 编辑器输入说明后按 ESC :wq 保存退出# 修改最后一次提交的说明未推送到远端时使用gitcommit --amend -m修正后的提交说明技巧提交说明要“言简意赅”比如“新增用户管理模块”“修复数据加载卡顿问题”避免写“更新文件”“修改代码”这种无意义的描述毕竟是给未来的自己看的嘛。3. 查看提交记录git log提交后你可以通过git log查看所有提交记录默认按“从近到远”的顺序展示# 完整格式展示提交记录包含作者、时间、提交说明gitlog# 精简格式一行展示一条提交记录便于快速浏览gitlog --prettyoneline# 只查看最近 n 条提交记录n 为数字gitlog -n3提交IDcommit 1a038c3f4c1dcfca47cf243ae4a097a813bbe1ad是每次提交时通过 SHA-1 算法计算出的唯一ID这个ID能直接定位到某次提交的所有内容。只要文件内容或提交信息有一点变化提交ID就会完全不同。5. 撤销操作不小心add错文件提交说明写错了这些问题都有对应的解决办法# 撤销暂存区的指定文件回到工作区gitreset HEAD[文件名]# 撤销暂存区的所有文件gitreset HEAD.# 修改最后一次提交的说明未推送到远端gitcommit --amend -m新的提交说明Git 版本库的底层存储结构执行git add和git commit后Git 会在本地版本库.git目录中生成一系列文件和目录核心包括index、HEAD、refs和objects。1. 暂存区的载体index 文件index文件在初始化仓库git init时不存在第一次执行git add后自动生成它存储了暂存区的元数据如文件路径、哈希值、修改时间等本质是“待提交文件的清单”路径.git/index可通过git ls-files --stage查看暂存区内容。2. 分支指针HEADHEAD是一个特殊的指针始终指向当前工作分支的最新提交我们可以把它理解为“当前位置的书签”。在.git目录下就能找到HEAD文件打开后会看到类似ref: refs/heads/master的内容代表当前分支是master。3. 分支的本质refs 目录分支名对应的文件存储了该分支最新提交的 ID路径为.git/refs/heads/[分支名]如.git/refs/heads/master。示例master文件内容为1a038c3f4c1dcfca47cf243ae4a097a813bbe1ad即该分支最新提交的 ID。核心逻辑分支 提交 ID 的“别名”Git 通过分支文件快速定位到最新提交。4. 数据存储核心objects 目录Git 所有的版本数据提交对象、树对象、文件内容都以“对象”形式存储在.git/objects目录下每个对象对应一个唯一的哈希值即提交 ID/树 ID/文件 ID。以提交 ID1a038c3f4c1dcfca47cf243ae4a097a813bbe1ad为例前两位字符1a是文件夹名称剩余字符038c3f4c1dcfca47cf243ae4a097a813bbe1ad是文件夹内的文件名。要查看这个对象的内容需要使用git cat-file命令# -p 参数表示以可读格式输出对象内容gitcat-file -p 1a038c3f4c1dcfca47cf243ae4a097a813bbe1adtree指向一个“树对象”记录本次提交的文件目录结构parent指向父提交形成提交历史的“链式结构”即分支的提交记录链。author/committer记录提交者信息和提交时间。继续查看树对象的内容就能看到本次提交包含的文件及对应的哈希值最终通过哈希值找到文件的实际内容。我们可以看到打印了一行内容着一行内容就是我们修改的内容。Git 提交的完整逻辑链路git add将工作区文件的哈希值写入.git/index暂存区git commit生成“文件对象blob”存储文件内容生成“树对象tree”记录文件目录结构生成“提交对象commit”关联树对象、父提交、作者和提交说明更新当前分支文件如master写入最新提交 ID更新HEAD指针指向当前分支的最新提交最终链路HEAD→ 分支文件 → 提交对象 → 树对象 → 文件对象 → 实际文件内容。Git 提交的完整逻辑链路通过前面的内容我们可以梳理出git add和git commit的完整执行链路git add执行过程计算工作区文件的哈希值将文件内容封装为blob 对象存入.git/objects将 blob 对象的哈希值写入.git/index更新暂存区索引。git commit执行过程读取.git/index生成tree 对象记录目录结构和 blob 哈希存入.git/objects生成commit 对象关联 tree 对象、父提交 ID、作者信息、提交说明存入.git/objects更新当前分支文件如.git/refs/heads/master写入最新 commit ID更新HEAD指针指向当前分支的最新提交。版本追溯链路HEAD→ 分支文件 → commit 对象 → tree 对象 → blob 对象 → 实际文件内容常见误区总结误区1把文件拖到仓库文件夹就认为被 Git 管理了。→ 正解必须执行git add git commit文件才会进入版本库。误区2手动修改.git目录下的文件。→ 正解.git是 Git 核心目录手动修改会导致仓库损坏。误区3提交说明写“更新文件”“修改代码”。→ 正解提交说明要清晰描述修改内容便于后续版本追溯。误区4混淆git add .和git add -A的作用范围。→ 正解前者管当前目录后者管整个仓库根据需求选择。结语Git 的添加与提交操作看似简单背后却藏着“工作区-暂存区-版本库”的分层设计逻辑。理解底层原理不仅能帮我们避免操作失误还能在遇到问题时快速定位原因。别忘了给这个博主点个赞赞喵、关个注注喵(๑˃̵ᴗ˂̵)و 你对这个博主的支持就是他继续肝优质算法内容的最大动力啦喵我们下篇博客不见不散喵