不知道你有没有过这种经历写了一下午代码终端里敲了一句git commit -m fix: 调整样式结果报错fatal: not a git repository (or any of the parent directories): .git当场愣住翻来覆去看目录也没想明白仓库为什么不见了。又或者第一次入职mentor让你把某个分支合到主分支你面对一团乱麻的冲突直接git checkout . git reset --hard一顿操作猛如虎回头一看别人的代码全没了。再或者运气好点只是报个ssh: Could not resolve hostname让你看着屏幕怀疑人生。这些场景我全都经历过。Git 这东西说难不难说简单也绝对不简单——它是一个只要你理解了底层逻辑就不会再怕的版本管理工具但如果只是东抄一句命令、西记一条口诀那永远只会停留在“会输入、不会解决”的阶段。这篇笔记不是命令手册而是我从“会用”到“能解决常见问题”这一路踩坑的完整记录包括安装配置、SSH 免密、日常提交、分支合并、LFS 大文件、worktree 多目录开发以及 VSCode、IDEA 里的常见问题排查。适合刚接触 Git 的新手也适合某些命令一知半解、遇到报错只能搜的初级开发者。1. 环境准备与 Git 安装这一步做不好后面全是坑1.1 Windows 环境安装到底该怎么选先说结论Windows 安装 Git 有两个容易搞混的东西——Git for Windows和Git Bash前者是完整软件后者只是其中自带的那个 Linux shell 模拟器。很多人搜“git bash 安装”其实装的是 Git for Windows装完你在开始菜单里看到 Git Bash、Git GUI、Git CMD 三个入口这很正常。我在 Windows 上装 Git 首选官网下载地址就是 git-scm.com 那种不是各种镜像站随便下一个包。为什么因为官网包有几个好处官方安装包自带最新稳定版某些国内镜像站上的版本陈旧可能缺补丁。安装向导里可以勾选“Add to PATH”这个太重要了——没勾选的话你在 CMD 或 PowerShell 里敲git --version会得到搜索引擎上高频出现的那句报错git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。安装过程中的选项我个人的建议是安装路径建议不要把 Git 装到带空格的路径比如C:\Git比C:\Program Files\Git更省事虽然 Program Files 下也能正常用但某些自定义脚本拼接路径时就容易踩坑。默认编辑器选择如果你只是日常使用无脑选 Vim 也行但想让git commit打开编辑器时别让你一头雾水建议装完后在配置里改成 VSCode 或 Notepad。后续我们会配。PATH 环境选 “Git from the command line and also from 3rd-party software” 即可这是最稳妥的一档。换行符转换line ending conversions这个选项很容易被忽略但坑后患无穷。Windows 上建议选 “Checkout as-is, commit as-is”不要在自动转换上纠结。如果你选了自动转换团队里有人 Mac 有人 Windows可能一堆Warning: LF will be replaced by CRLF的提示严重时甚至会让整个文件被认为发生了变更明明什么都没改diff 却一片红。装完之后打开 CMD 或 PowerShell 验证git --version输出类似git version 2.23.0.windows.1我看搜索引擎里有人停留在 2.23.0这已经是很老的版本了就算成功。1.2 Mac 和 Ubuntu 的安装姿势Mac 上最省事的办法是走 Homebrew# 先确认有没有 homebrew没有的话建议装一个包管理真心好用 brew install git如果不想额外装 Homebrew也可以直接去官网下载 Mac 对应安装包git-scm.com 提供 .dmg 安装程序装完一样能用。需要注意的是Mac 自带的默认git可能是系统版本在/usr/bin/git路径和版本都可能和你预期不同。我建议用which git检查一下路径确保你用的是自己装的版本。如果系统提示“需要安装命令行开发者工具”可以装一下然后再brew install git覆盖。Ubuntu 或其他 Debian 系 Linux 发行版sudo apt update sudo apt install git -y装完同样验证一下版本。另外Ubuntu 上容易忽略的一件事很多发行版默认没有配置用户邮箱和用户名第一次 commit 就会报Please tell me who you are这个是配置阶段要解决的问题我们下面马上讲。1.3 安装后的第一件事配置身份信息不管什么系统装完 Git 第一件事永远是设置全局用户名和邮箱。这不是走流程而是因为 Git 的每次提交都会把这两个信息记录到历史里不配的话提交会失败或者使用默认的、错误的信息导致代码评审时不知道是谁写的。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个细节值得多说一句--global是全局配置--local是仓库级配置。如果你同时参与公司项目和个人项目公司仓库里的提交邮箱可能需要用企业邮箱这时候在对应仓库里用git config user.email覆盖全局即可。我见过有人全局配了公司邮箱然后在 GitHub 开源项目上提交结果所有公开提交邮箱都暴露了而且 contribution 绿格子统计对不上。这不是安全问题但很烦建议有条件就分开配。2. 配置与认证从 HTTPS 到 SSH 密钥把“弹账号密码”彻底解决掉2.1 账号密码存哪里的问题很多人第一次用 Git 拉代码用的是 HTTPS 地址比如https://github.com/xxx/repo.git。这样做的最大问题就是每次 push 都要输账号密码。虽然现在系统间可能记住了 Windows 凭据管理器里的密码但如果碰到服务器端修改密码或者在不同机器上切换还是会频繁提示认证失败。Git 官方提供了一个凭据存储工具credential helperWindows 上可以通过git config --global credential.helper manager来启用 Windows Credential Manager。Mac 上比较常见的是osxkeychain如果是走 Homebrew 装 Git 一般已经内置。Ubuntu 上可以按需选择store或者cachecache临时缓存默认 15 分钟后失效适合短时间频繁操作。store明文存储在~/.git-credentials不推荐长期使用但可以救急。不过说实话我个人不太依赖 HTTPS 凭据更推荐 SSH 方式。原因很简单SSH 密钥免密、稳定、密钥本身就是一种身份标识工作中更通用。2.2 SSH 密钥配置全流程以 Gitee 为例搜索引擎里关于“git 配置 gitee 密钥”“ssh 认证失败”的搜索量一直很大。配置 SSH 核心其实就三步第一步生成密钥。ssh-keygen -t rsa -b 4096 -C 你的邮箱或备注执行后会提示你输入保存路径和 passphrase。路径直接回车用默认~/.ssh/id_rsa即可。passphrase 如果设了后续每次使用密钥都会要求输入但可以配合ssh-agent记住也可以干脆不设安全性会稍低但在可信开发机上问题不大。第二步把公钥加到远程仓库平台。查看公钥内容cat ~/.ssh/id_rsa.pub把输出的一整串内容复制下来登录 Gitee或 GitHub进入「设置 → SSH公钥」粘贴保存。名称随意能分辨是哪台机器即可。第三步测试连接。ssh -T gitgitee.com如果配置正确Gitee 会返回类似Hi xxx! Youve successfully authenticated, but GITEE.COM does not provide shell access.的提示。很多人在这一步卡住最常见的原因是公钥没复制完整开头少了ssh-rsa或末尾少了邮箱或者用了不是默认路径的私钥Git 找不到。解决办法是显式指定密钥路径在~/.ssh/config里加一截Host gitee.com HostName gitee.com PreferredAuthentications publickey IdentityFile ~/.ssh/id_rsa顺便说一个搜索频率极高的问题ssh: Could not resolve hostname github.com: Name or service not known。这个报错和 SSH 认证无关纯粹是 DNS 解析问题常见于网络代理或 hosts 文件被改过。排查思路是ping github.com或nslookup github.com看解析是否正常而不是去重配密钥。2.3 配置 SSH 后如何验证与切换当同一个仓库既配了 HTTPS 又配了 SSH你需要检查远端地址git remote -v如果输出的是https://开头你想换成 SSH可以git remote set-url origin gitgitee.com:用户名/仓库名.git这个操作我在工作里经常帮同事做因为有些人 clone 的时候偷懒没改结果每次 push 都要输密码。换完之后可以试git push --dry-run验证一下。2.4 清除已保存的账号密码如果你在某个仓库用 HTTPS 输入过密码而密码已经改了想重新输入需要清除缓存。Windows 上比较通用的方式是打开「控制面板 → 凭据管理器 → Windows 凭据」找到git:https://xxx的条目删掉。或者通过命令git credential reject输入protocolhttps hostgithub.com然后回车两下即可删除对应记录。这条命令比手动删界面要快得多强烈建议记住。3. 日常核心命令实战不只是简单的 add、commit、push3.1 初始化仓库与 clone最容易忽视的两个细节在空目录里初始化git init这个命令本身很简单但我见过太多人是这么操作的在某个已经包含大量文件的目录里直接git init然后一股脑把所有文件加进去包括那一堆 node_modules、target、.idea。这就是为什么我会在所有新项目里第一时间创建.gitignore文件。.gitignore的写法不复杂但有几条原则非常关键用相对根目录的路径规则比如/build/表示只忽略根目录下的 build 文件夹。用通配符时注意*.log会匹配所有层级的日志文件。不忽略.gitignore本身。聊完 init再说 clone。如果你只想拉取某个分支的代码可以git clone -b dev gitgitee.com:user/repo.git如果仓库特别大你想浅克隆只拉最近一次提交可以加--depth1但要注意浅克隆的仓库后续 push 可能受限制且无法查看历史只适合临时用。3.2 查看状态与 diff动手之前先看清楚“先看再改”是我一直给团队强调的习惯。日常操作前先跑git status然后再看具体变更内容git diff这里有一个非常实用的技巧只查看某个文件的改动不要每次都看全部。git diff 文件名如果你已经git add了想查看暂存区的改动跟上一版的差异git diff --cached很多人报错或者误操作就是因为没分清工作区、暂存区和版本库的概念。我用一个生活类比解释给新人听工作区 你桌子上放的文件草稿。暂存区 你已经把某几页装进了文件袋准备提交。版本库 档案柜里的历史存档。你对文件修改后没有git add它只是草稿状态的变化git add之后它进入了文件袋git commit之后才真正归档。没有git add的文件commit 是永远不会包含它的。3.3 commit 的正确姿势写好信息学会如何修改提交信息git commit有几种写法# 常规写法 git commit -m feat: 新增登录接口 # 将已暂存的变更提交并跳过暂存注意这只提交已跟踪文件的修改 git commit -am fix: 修复空指针异常关于 commit message 的规范我比较推荐 Conventional Commits 那套简单约定feat:、fix:、docs:、style:、refactor:、test:等。不是说必须多花哨而是团队协作时能通过信息前缀快速筛选哪次提交是功能、哪次是修 bug对定位 issue 和回滚都很有帮助。git commit --amend怎么用这是搜索热词。它的作用是修改最近一次提交。最常见的场景刚才 commit 后发现拼写错了。忘记 include 某个文件想补进去但又不想增加一个新的“fix typo”提交。操作方式git add . # 补充需要的文件 git commit --amend -m 新的提交信息或者只改信息不改内容git commit --amend -m 新的提交信息这里必须警示--amend是改写历史如果最近一次提交已经 push 到远端千万不要随意 amend 后再强推。因为 amend 会生成一个新的 commit hash远端原有的历史被改写团队成员如果已经基于旧 commit 拉取了分支再 push 就会被拒绝只能git pull --rebase收场。如果你确实需要澄清提交信息更安全的做法是再提交一个chore: 修正提交信息虽然这不够优雅但至少不会在公共分支上引发历史分裂问题。个人开发或尚未推送的分支随便用 amend 没问题。3.4 撤销与回滚区分 reset、revert、checkout搜索热词里出现高频的错误“git : 无法识别”之外操作上的高频问题其实是误撤代码。三个命令的区别我一次性讲明白git reset回退版本等于把指针往回拨适用于尚未推送的提交。git revert生成一个新的反向提交适用于已经推送到远端、需要撤销但保留历史的提交。git checkout -- file从某个版本恢复单个文件只影响工作区。举例# 撤销工作区某个文件的修改 git checkout -- 文件名 # 撤销暂存区的文件但保留工作区修改 git reset HEAD 文件名 # 回退最近3次提交保留工作区改动 git reset --soft HEAD~3 # 回退最近3次提交完全丢弃改动 git reset --hard HEAD~3--hard是非常危险的操作我有一次在分支上连续改了三天结果执行git reset --hard origin/master想同步远端却忘了本地分支还有未提交的代码一瞬间三天劳动全没。后来才知道可以用git reflog找回。这份笔记后面会专门讲 reflog 这个救命命令。4. 分支管理与合并从“会切分支”到“会处理冲突”4.1 分支的本质与基本操作Git 的分支不过是一个指向 commit 的指针创建分支的成本极低这也是 Git 比 SVN 高效的重要原因之一。常用操作# 创建分支并切换 git checkout -b feature/login # 或者新版推荐写法 git switch -c feature/login # 查看所有分支 git branch -a # 切换分支 git checkout master # 或者 git switch master # 删除分支需要换出该分支 git branch -d feature/login这里我要强调一个非常常见且容易踩的坑切换分支时工作区必须是干净的或者至少冲突状态要处理好。如果你的工作区有未提交的修改git switch可能直接拒绝执行。特别是当你改了某个文件而目标分支上也改了这个文件Git 会拒绝切换并提示Your local changes to the following files would be overwritten by checkout。这时可以先暂存你的改动git stash git switch master git stash popgit stash是临时把工作区的修改存起来让工作区变成干净状态。这个命令在需要临时切换分支救火时非常管用相信每个开发者都用过。4.2 分支合并merge 和 rebase 怎么选最常规的合并git switch master git merge feature/login如果有冲突Git 会提示CONFLICT (content): Merge conflict in xxx。此时你要做的是打开冲突文件找到类似这样的标记 HEAD 这是当前分支的内容 这是被合并分支的内容 feature/login手动保留需要的内容删除标记然后git add 冲突文件 git commitmerge 和 rebase 的选择是我团队群里每次都会争论的话题。我的建议是公共分支master、develop、release只允许 merge不要 rebase。个人功能分支可以在合回公共分支前git rebase master让功能分支的提交历史排成一条直线。为什么要这样merge 保留了两条分支交汇的拓扑结构提交历史里能看到“从哪里来、到哪里去”适合追溯rebase 把分叉的提交“抹平”成一条线适合让功能分支看起来清爽干净。但如果团队多人协作rebase 会把别人的提交时间线打乱出现“你的提交总是在我的前面”这种奇怪情况所以公共分支千万别 rebase。4.3 合并冲突的真实场景实操合并冲突不可能完全避免处理冲突的方法才是重点。我分享一套我实际用下来最稳定的流程先看冲突文件清单git status所有出现both modified的文件都是要处理的。用 VSCode 打开冲突文件红色区域直观显示左右两侧差异逐行选择。全部处理完后逐个git add。最后git commit完成本次合并或者用git merge --continue效果一样。有一个细节值得注意冲突解决后的 commit 信息Git 会默认帮你写好了Merge branch xxx之类的模板直接保存即可。不用画蛇添足地改信息保持默认合并信息反而对历史追溯有帮助。另外遇到大范围冲突时建议别硬拼。可以先git merge --abort退回合并前状态重新梳理两个分支的差异或者叫上相关同事一起看。硬拼出来的代码往往是最烂的代码。4.4 将两个分支合并一条命令解决搜索热词里有“将 git 两个分支合并”很多人是想把一个分支的所有内容合并到另一个分支最简单的方式就是# 在目标分支上执行 git merge 另一分支名如果不需要保留被合并分支的历史比如这个分支只是个临时分支可以用--squashgit merge --squash feature/temp git commit -m feat: 合并临时分支的所有改动这样目标分支上只会多一个提交而不是把临时分支上十几个琐碎提交全带进来。这在合并实验性分支、一次性分支时特别好用。5. 进阶命令LFS 大文件存储与 worktree 多目录开发5.1 Git LFS仓库里塞大文件不再拖慢 cloneGit 本身就是文本级版本管理遇到大文件二进制资源、模型权重、视频、安装包等仓库会迅速膨胀。一个 100MB 的二进制文件你每次修改都会在历史里存一份仓库体积以“修改次数 × 100MB”上涨很快所有同事 clone 都会卡死。Git LFSLarge File Storage就是把大文件的内容放到另一个存储空间Git 仓库里只存一个文本指针。这样 clone 的时候默认只拉指针等到要真正使用文件时再按需拉取。常用命令# 安装 LFSWindows 安装 Git 时也可以勾选 Git LFS git lfs install # 跟踪某类大文件 git lfs track *.zip git lfs track *.mp4 # 确认跟踪规则被写入了 .gitattributes cat .gitattributes # 正常 add 和 commit git add . git commit -m add large asset注意.gitattributes文件必须一起提交到仓库否则其他同事的 Git 不会识别 LFS 规则。另外如果仓库已经不小了临时想用 LFS 处理历史中的大文件操作会复杂不少建议从项目一开始就用。搜索里还有一个高频问题git lfs clone 卡住。这常见于 LFS 拉取大文件时候网络不稳定或者服务器带宽有限。解决办法是# 先跳过 LFS 拉取只克隆整个仓库的普通文件 git clone --no-checkout gitgitee.com:user/repo.git # 进入仓库后按需拉取 LFS 文件 git lfs pull或者直接设置 LFS 并发数降低超时风险git config lfs.concurrenttransfers 1这个单独线程数没必要调太高反而容易因网络并发而失败。实测设置成 1 最稳。5.2 Git worktree同时开多个分支目录git worktree是被很多人忽略的利器。它的作用是同一个仓库可以在不同目录下同时签出不同分支互不干扰。典型场景是我正在 feature 分支上改东西突然产品说线上有个紧急 bug 要立刻修。如果只有一个工作目录就要 stash 或者 commit等修完再切回来。有了 worktree我可以直接在另一个目录里开辟一个 hotfix 分支原地干活完全不影响 feature 分支的开发现场。# 在某个目录下添加一个 worktree并切到 hotfix 分支 git worktree add ../hotfix-fix -b hotfix/urgent操作结束后把 worktree 删掉git worktree remove ../hotfix-fix # 或者如果你在里面已经提交了想保留记录 git worktree remove --force ../hotfix-fix还有一个好处多个 worktree 共用同一个仓库对象库不额外占用历史存储空间。我可以同时开三四个 worktree分别开发不同功能磁盘开销只多一个工作区文件。这比复制多个仓库目录省太多地方。但我也遇到过坑worktree 里的分支不是当前分支时无法删除主仓库的分支。比如你在 worktree 里签出了feature/a主仓库里想删feature/a就会提示cannot delete branch feature/a checked out at ...因为 Git 认为该分支还在某个 worktree 中使用。先切走或删除对应 worktree 就好。5.3 git reflog数据丢失的最后一道保险如果你做过git reset --hard或者git checkout -b覆盖了分支指针不要急着崩溃。git reflog会记录你本地每一次 HEAD 变动哪怕分支被删、被 reset你都能找到之前的 commit hash。git reflog输出里会有一串 commit 列表每条前面有 hash。找到你要恢复的那条然后git branch 恢复后的分支名 那个hash或者直接git reset --hard 那个hash。我个人的体会是reflog 最常用的场景反而是“误删分支”。团队协作时偶尔会有人清理本地分支git branch -d删掉后才发现那个分支上还有没合并的改动但好消息是 reflog 里通常还留着头指针。只要这个仓库是你本地的里面的记录就有机会恢复。这个命令平时想不起来用但关键时刻能救命。6. 常见问题与疑难杂症排查把高频报错一次讲透6.1 “无法将 git 识别为 cmdlet”与“not a git repository”这两个是搜索量最高的报错很多新人把它们当成同一种问题其实完全不是。“无法将 git 识别为 cmdlet、函数、脚本文件或可运行程序的名称”是环境变量问题Windows 下经常发生。原因就是 Git 的 bin 目录不在PATH里。解决办法重新执行 Git 安装包选择“Modify”勾选 “Add to PATH”。或者手动把C:\Program Files\Git\bin和C:\Program Files\Git\cmd加到系统环境变量 PATH 里。加完后务必新开一个终端窗口因为已打开的窗口不会重新加载环境变量。fatal: not a git repository (or any of the parent directories): .git则是说当前目录不是仓库也无法向父目录找到仓库。常见场景你在一个空目录里敲 Git 命令但没git init。你在子目录里但该子目录不是仓库的一部分。某个.git目录丢了比如移动文件夹的时候误删。排查方法就是往上找仓库根目录看是否存在.git文件夹然后用cd切到仓库根目录再执行。这里我还想提一个小细节Windows 的资源管理器如果手动删除了 .git 目录软件上是“找不到仓库”但好在代码文件都还在重新 git init 再关联远端是可以救回来的。6.2 ssh 认证失败从公钥到 config 逐一排查ssh: Permission denied (publickey)是 SSH 认证失败最常见的形式。排查顺序我整理成了表格序号检查项具体命令失败表现1本地私钥是否存在ls -la ~/.ssh/没有 id_rsa 文件2公钥是否已配置到平台登录平台设置页查看无匹配公钥3远端地址是否使用了 SSHgit remote -v是 HTTPS 开头的4本机是否识别对应 hostssh -T gitgitee.com提示 Host key verification failed5私钥是否用的是其他路径~/.ssh/config指定 IdentityFile默认找不到密钥有些机器为了安全会自定义密钥文件名比如id_ed25519_custom这时候 Git 不会自动加载你需要在~/.ssh/config写明。否则就报Permission denied (publickey)。6.3 VSCode 和 IDEA 中配置 Git 账号密码这部分很多人不会的命令行操作其实通过界面就能解决。以 VSCode 为例打开 VSCode 设置搜索git.path确认指向已安装的 git.exe。打开终端Ctrl用git config --global user.name和user.email 配置。在首次 push 时VSCode 会弹出登录窗口走 HTTPS有的版本是右上角弹窗有的版本是让终端输入账号。如果你用 SSH 方式VSCode 不需要额外配置账号密码因为认证由 SSH 密钥完成。IntelliJ IDEA包括 JetBrains 全家桶里最简单的方式是Settings → Version Control → Git设置 Path to Git executable。Settings → Version Control → GitHub/Gitee添加账号可以直接用 Token 登录。这里我想多说一句JetBrains 系列用 Token 登录比账号密码更可靠。因为近两年平台都倾向于强制或推荐 token 验证密码方式经常被提示“认证失败”。6.4 目录泄露或大仓库如何拉取特定代码搜索热词里有“git 目录泄露如何下载”这个场景通常出现在安全测试或者代码审计场景里你在某网站发现了一个暴露的.git目录想把它拉下来分析源码。如果你不想把整个历史全部拉一遍可以这样# 通过 Git HTTP 协议直接枚举目录而不是走 git clone # 先用 git ls-remote 看看远端有没有暴露 git ls-remote http://目标地址/.git/如果确实能访问拉取还原时需要工具的协助常见思路是枚举objects/info/packs和refs文件逐步还原 commit、tree 和 blob。这个过程本质上是 Git 对象存储的逆向感兴趣的话可以自己研究下.git的目录结构。不过在真实业务环境里如果你自己是仓库持有者发现.git暴露了最合理的修复方式就是移除 web 服务的静态资源映射不要把.git目录暴露给外部访问。6.5 Git 与 SVN 核心区别帮还在纠结的人做个决定很多新人在学习 Git 前都有 SVN 经验老是问“Git 到底和 SVN 有什么区别”。我用一句话总结SVN 是中心化的只有服务器上有一份完整的版本库Git 是分布式的本地就是完整仓库。这个差异带来三个直接结果Git 的几乎所有命令commit、log、diff、branch都在本地执行断网也能提交SVN 不行。Git 的分支创建成本极低鼓励多做分支实验SVN 的分支其实是目录拷贝操作成本高。Git 的协作靠 push/pull 来交互SVN 靠 commit/update两者哲学完全不同。如果你正在一个只能选一个的工作环境我的建议是挺 Git。它的学习曲线确实比 SVN 陡一点但一旦习惯分支工作流基本回不去。7. 个人经验总结少踩坑的几条实操心得写到最后分享几条我在实际工作里沉淀下来的经验不一定高科技但真的能减少日常摩擦第一commit 要小、要频繁。不要攒了一天代码再一次性 commit。小的提交更容易 review、更容易回滚、也更容易用git bisect定位出问题是在哪一步引入的。每次提交只做一件事信息写清楚这是职业习惯不是可有可无的仪式感。第二push 之前先 pull --rebase。我个人尤其喜欢这个习惯。如果远端有新的提交git pull --rebase会把我的本地提交重放到远端最新提交之上历史干净没有多余的 merge commit。注意这个习惯只适用于尚未共享的分支或你自己的功能分支。如果已经有多人基于这个分支在协作用 merge 更稳。第三重要操作前做 backup。虽然不是每个操作都需要但只要是git reset --hard、git rebase、git clean -f这类可能有破坏性的操作我会先在旁边建一个备份分支git branch backup/时间点这样万一操作过程不顺切回备份分支就完事。代码这东西在出错那一刻最贵花几秒钟建分支是全世界最划算的投资。第四一个仓库只存代码别塞构建产物和本地配置。.idea/、*.iml、node_modules/、dist/、build/、target/、.env.local这种东西尽早写进.gitignore。否则每次分支切换、同事 clone、合并代码都会因为这些杂七杂八的文件产生无意义的冲突浪费时间也制造噪音。第五学会阅读报错信息。Git 的报错其实写得非常清楚很多人在搜索框里复制粘贴报错之前连报错都只看个大概。以fatal: not a git repository为例它已经明说了“当前目录不是仓库”问题是你看这句话了吗先自己读一遍报错、先git status看一眼往往几秒钟就能解决比在搜索引擎里翻帖子快得多。这篇笔记没有覆盖 Git 的全部知识点但覆盖了我实际工作中每天都会用到以及搜索引擎里大家问得最多的问题。从安装到配置、从日常提交到分支合并、从 LFS 大文件到 worktree 多目录再到那堆让人崩溃的报错我把能踩的坑和能省的弯路都整理出来了。Git 这工具用熟了之后真的会变成你身体的一部分——你对它的理解越深它给你的安全感就越足。希望这份笔记也能成为你的那个“安全感”。