1、本地Git命令1.1、Git CommitGit Commit 项目快照Snapshot每次 git commit 并不是粗暴地复制整个目录而是对已跟踪文件当前状态的轻量级快照记录。Git 通过对比当前版本与上一次提交的差异diff将变更打包存储因此提交记录非常轻量。1.2、Git BranchGit Branch 可移动的标签指针分支本质上只是一个指向某个提交记录的可移动指针仅此而已。它不复制任何文件不占用额外存储空间。为什么早建分支多用分支优势说明零成本创建分支只是 41 字节的引用文件创建再多也没有存储或内存开销逻辑隔离按功能/bug/实验拆分工作避免单分支臃肿混乱并行开发多人或多任务同时进行互不干扰安全实验新想法随便试搞砸了删掉分支即可不影响主线关键命令# 创建分支但停留在当前分支gitbranch newImage# 切换分支gitcheckout newImage⚠️ 常见误区创建 ≠ 切换gitbranch newImage# 创建了 newImage 分支# 但 HEAD 仍然指向 maingitcommit# ❌ 提交会跑到 main 上newImage 原地不动如何理解 “提交记录”、”分支“和 HEAD提交记录Commit 项目的快照每个提交保存了那一刻所有已跟踪文件的完整状态每个提交除第一个外都有一个 parent 指针指向上一个提交这样一条一条连起来就是项目的历史链分支Branch 可移动的标签指针分支本身不存代码它只是指向某个提交的引用当你在这个分支上提交时这个指针会自动向前移动指向最新的提交其他分支如果不切换过去就原地不动HEAD 你在哪HEAD 是一个特殊指针指向当前所在的分支HEAD 决定了你的下一次提交会让哪个分支跟着走1.3、Git Mergegit merge 整合两条历史线当你想把一个分支的修改合并到另一个分支时git merge 会创建一个新的提交记录这个提交的特殊之处在于它有两个 parent 节点。它相当于在说“我要把这两个分支的所有历史提交以及它们各自的祖先全部包含进来。”⚠️ 关键注意点合并方向很重要git merge bugFix 是把 bugFix 合并到当前分支不是反过来合并提交不可少它是两条分支历史的交汇点没有它其中一条分支的历史会被隐藏1.4、Git Rebasegit rebase “变基”把提交记录连根拔起重新栽种到另一棵树的顶端Rebase 会取出当前分支上的一系列提交复制它们然后在目标分支的最新提交之后逐个重新应用。原提交并不会被删除只是不再被引用新产生的是内容相同但哈希不同的副本。效果让并行开发的两条分支看起来像是按顺序串行开发的一样。Rebase vs Merge 对比维度git mergegit rebase历史形状保留分支结构产生分叉和合并提交线性历史无分叉提交记录保留原提交新增一个合并提交复制提交原提交悬空哈希改变可读性能看清什么时候合并的像一条直线非常干净安全性安全不改变已有提交改写历史需谨慎使用适用场景公共分支合并、保留完整协作痕迹本地分支整理、特性分支上线前清理2、远程Git命令2.1、Git Clonegit clone 把远程仓库完整复制到本地远程仓库本质上就是你本地仓库在另一台计算机上的拷贝通过互联网进行通信。git clone 不只是下载代码而是把远程仓库的完整历史、所有分支、所有提交都复制到本地。克隆后本地得到什么内容说明完整提交历史从第一个提交到最新提交全部在本地所有分支远程分支映射为origin/分支名如origin/main默认检出分支通常自动切换到main或仓库默认分支远程别名远程仓库被命名为origin后续用这个名字引用远程仓库的三大价值备份即使本地硬盘损坏代码还在远程协作团队成员可以共享代码、审查变更托管GitHub/GitLab 等平台基于此提供 CI/CD、Issue、PR 等功能2.2、远程分支远程分支 远程仓库状态的本地镜像远程分支的命名格式为 /例如 origin/main教程简写为 o/main。它反映的是你上次与远程通信时远程仓库对应分支的状态。远程分支的三大特性特性说明只读快照它是远程状态的本地缓存不能直接在上面提交通信才更新只有执行fetch/pull/push时才会刷新切换即分离 HEAD切到远程分支会自动进入 detached HEAD防止误操作2.3、git fetchgit fetch 纯下载操作它只做两件事且只做这两件事下载远程仓库中本地缺失的提交记录更新本地远程分支指针如 origin/maingit fetch 做了什么 vs 没做什么✅ 做了❌ 没做下载远程的新提交到本地修改你的本地main分支更新origin/main等远程分支指针合并代码到当前分支让你能看到远程的最新状态改动你工作目录里的任何文件为什么需要 git fetch远程分支如 origin/main是你上次和远程通信时的快照。当同事推送了新代码你的 origin/main 还是旧的。git fetch 就是去远程看一眼把新东西下载下来更新快照。常见误区“我 git fetch 了为什么代码没变”因为fetch 不是 pull。fetch 只是把远程的数据拿进家门但还没摆到桌上。你的本地分支、工作目录完全不受影响。2.4、git pullgit pull git fetch git merge 的简写它是 Git 中最常用的同步远程代码命令把下载远程更新和合并到本地分支两步合为一步。2.5、git pushgit push 发布你的成果它是 git pull 的反向操作把本地仓库的新提交上传到远程仓库让远程分支跟上你的本地分支。一旦 push 成功团队成员就能从远程拉取你的代码。三件事同步发生上传本地缺失的提交到远程仓库更新远程仓库的对应分支指针如远程的 main更新本地的远程跟踪分支如 origin/main2.6、远程历史分叉与解决方案问题场景你周一 clone 了仓库在本地开发了一周。周五准备 push 时发现同事已经推送了新代码——远程历史和你本地的基准已经分叉了。远程C0 → C1 → C2同事的新提交 本地C0 → C1 → C3你的提交基于旧 C1此时直接 git push 会被拒绝! [rejected] main - main (non-fast-forward)Git 拒绝的原因你的 C3 基于旧的 C1而远程已经前进到 C2。Git 不会猜测是回退远程还是强行合并它强制你先处理这个分歧。两种解决方案核心思路都一样先把远程最新变更拿进来让你的工作基于最新的代码再 push。方案一Rebase线性历史gitfetch origingitrebase origin/main 把远程最新代码拉下来然后把我的本地工作挪到它头顶上gitpush origin main效果你的 C3 被复制到 C2 后面历史变成一条直线。结果C0 → C1 → C2 → C3’优点历史干净、线性便于回溯。缺点改写本地提交的哈希如果已推送到其他远程需注意。方案二Merge保留分叉gitfetch origingitmerge origin/maingitpush origin main效果产生一个合并提交 M把两条历史连在一起。结果C0 → C1 → C2 → M(合并提交)↘ C3 ↗优点保留完整协作痕迹不改动已有提交。缺点历史图会出现分叉和合并节点。简写命令完整流程简写fetchrebasepushgit pull --rebase→git pushfetchmergepushgit pull→git push