Git从安装到实战：配置、命令、报错与安全防护全指南-代码聚汇网

Git从安装到实战：配置、命令、报错与安全防护全指南

蓝盐泳池1983·2026-08-31·阅读 22 GEO检测（免费）

Git安装Git配置Git命令

|难度：普通|阅读约 41 分钟

作为一个在代码世界里摸爬滚打了十几年的老鸟，我经手的 Git 相关的问题怕是有上千个了。前两天团队里来了个新同事，第一天装 Git 就卡住了，终端里敲 git 直接报"无法将 git 项识别为 cmdlet、函数、脚本文件或可运行程序的名称"，他一脸懵地问我怎么办。我过去啪嗒啪嗒三分钟搞定，然后发现他连全局的 user.name 和 user.email 都没配。这让我意识到，Git 这个东西，看起来遍地都是教程，但真正能一次性把"安装、配置、日常命令、报错排查、安全防护"讲透的，还真不多。

所以我把这些年攒下的经验整理了一下。这篇就围绕 Git 从零到实战的完整链路来聊，主要解决四类人的问题：一是刚接触 Git 的新手，需要知道怎么装、怎么配、怎么用；二是用了 Git 但经常踩坑的开发者，比如免密失败、合并冲突、莫名其妙被锁住；三是制定团队规范的人，怎么让提交记录变成可读的项目文档；四是对安全性有要求的人，怎么避免 .git 目录泄露这种低级但致命的问题。内容都是实操验证过的东西，你照着做就行。

1. 安装这一步：拦住大多数新手的其实不是安装本身

1.1 Windows 下安装 Git 的正确姿势

Git 在 Windows 上的安装包下载地址是 https://git-scm.com/download/win，这个不用多说。安装过程中有个很关键的选项——调整你的 PATH 环境。默认选项是"Git from the command line and also from 3rd-party software"，这个可以保留，它会把 Git 的可执行文件路径加进系统 PATH，让你能在任意终端窗口里直接调用 git 命令。

但这里有个很多人没注意到的坑：安装向导里默认的"Checkout Windows-style, commit Unix-style line endings"这个选项，它会把行尾符自动转换打开。对于大多数团队来说，这个选项能避免 Windows 和 Linux/macOS 同事之间因为换行符不同导致的 git diff 刷屏问题，但我建议你在选之前先想明白自己团队的技术栈。如果团队里全是 Windows 环境，选"Checkout as-is, commit as-is"更省心；如果跨平台协作，保留默认选项问题也不大。只不过后面对 core.autocrlf 这个配置要有认知，后面我会单独展开讲。

装完之后，终端里执行 git --version，能看到版本号就说明安装成功了。看不到版本号的情况我见太多了，90% 都是 PATH 没生效，要么是安装时选了"Use Git from Git Bash only"，要么是改完环境变量没开新终端。Windows 下环境变量的修改，对已经打开的终端窗口是无效的，必须新开一个窗口。这个细节卡住过无数人。

1.2 Git Bash、CMD、PowerShell 到底该用哪个

很多新手会纠结"git bash是什么"这个问题。简单说，Git Bash 是 Git for Windows 自带的一个模拟 Linux 终端环境的工具，它让你能在 Windows 上使用 ls、cd、vim 这些 Unix 命令。我个人的建议是：日常使用直接用 Windows Terminal + PowerShell 或者 CMD 就够了，不需要非得用 Git Bash。因为现代 PowerShell 已经能做到大部分事情，而且配合 posh-git 或 oh-my-posh 插件，提示符能直接显示当前分支，体验很好。

但有两种情况我建议用 Git Bash：一是你需要执行 ssh-keygen 生成密钥或者 ssh-add 添加密钥的时候，Git Bash 的体验更接近 Linux；二是某些公司内部脚本是基于 Bash 写的，在 CMD 里跑不了。其他时候，怎么顺手怎么来，Git 的命令本身是跨平台一致的。

1.3 macOS 与 Linux 的安装差异

macOS 上推荐用 Homebrew 安装：brew install git。这里有个细节，macOS 系统自带的 Git（通过 xcode-select --install 安装的）版本通常比较老，很多新语法和 bug 修复都没有，所以建议还是用 Homebrew 装新版。Linux 各个发行版不太一样，Debian/Ubuntu 系用 apt install git，RedHat/CentOS 系用 yum install git。

提示：Linux 下源码编译安装 Git 不是不行，但一般没必要。除非你要用最新的特性，否则发行版源里的版本已经足够稳定。编译安装需要处理一堆依赖，纯属浪费时间。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 初始化与三件套配置：让 Git 知道你是谁

2.1 全局配置背后的逻辑

安装完 Git 的第一件事，不是急着 clone 代码，而是先配置身份。这个很多人会跳过去，结果第一次 commit 的时候发现提交信息里显示的是"unknown"，或者更尴尬的是提交记录里的邮箱是乱填的，根本关联不上自己的账号。

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这两个命令设置的是所有仓库共用的身份信息。--global 的意思是全局生效，配置文件在 ~/.gitconfig。如果你某个特定项目想用不同的身份，可以在那个仓库目录下省略 --global 重新设置，配置文件在该仓库的 .git/config 里。

这里有一个我在实际工作中踩过的坑：配置的邮箱必须和你在代码托管平台（GitHub/GitLab/Gitee）上绑定的邮箱一致，否则提交记录不会关联到你的账号头像。很多平台提供"noreply"邮箱选项用于保护隐私，但绝大多数团队协作场景，还是用真实邮箱最省事，因为代码评审系统要根据提交记录找人确认问题。

2.2 换行符与中文路径：两个默认行为暗藏的雷

Windows 和 Unix 系统的换行符不一样，Windows 用 \r\n（CRLF），Unix 用 \n（LF）。Git 默认在 checkout 的时候把 LF 转成 CRLF，commit 的时候又把 CRLF 转回 LF，这样仓库里统一存 LF，工作区里 Windows 用户看到的是 CRLF。这套机制本身没问题，坏就坏在有些文件不应该被转换，比如 .bat 批处理文件、某些特定编码的配置。

推荐的做法是仓库根目录放一个 .gitattributes 文件，显式声明哪些文件用什么行尾符：

bash复制* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

text=auto 让 Git 自动判断文本文件并统一转 LF，.sh 脚本强制用 LF（因为 Linux 环境下 CRLF 会导致脚本报错），.bat 文件强制用 CRLF（Windows 批处理对 LF 的兼容性有历史问题），图片等二进制文件声明为 binary 不被转换。这个文件一放，整个团队的行尾符问题就一劳永逸了。

再来说中文路径。很多国内开发者会遇到 git status 时中文文件名显示成八进制转义字符（\346\265\213\350\257\225），这是因为 Git 默认对非 ASCII 字符做转义。解决办法：

bash复制git config --global core.quotepath false

设置完再看，中文文件名就能正常显示了。这个配置虽小，但对国内团队的日常体验影响极大，属于那种"不设不知道，一设离不开"的配置。

2.3 初始化与首次提交的完整动作

在一个新项目目录里，git init 初始化仓库，然后用 git add . 把所有文件加入暂存区，git commit -m "feat: 初始化项目" 完成首次提交。但新手经常在这个流程里犯一个错误——把不该提交的文件提交进去了，比如 node_modules、target、.idea、__pycache__ 这些目录。正确做法是创建仓库的第一时间就写好 .gitignore 文件。

我见过最实用的一份 .gitignore 基础模板：

bash复制# 依赖目录
node_modules/
vendor/

# 构建产物
dist/
build/
target/
*.class

# IDE 配置
.idea/
.vscode/
*.iml

# 系统文件
.DS_Store
Thumbs.db

# 环境变量
.env
.env.local

.gitignore 的匹配规则要注意：模式结尾的 / 表示匹配目录；* 匹配零个或多个字符；? 匹配一个字符；! 表示取反。比如你用了 .env 忽略所有环境变量文件，又想例外保留 .env.example，就必须在下面加一行 !.env.example。顺序很重要，后面的规则会覆盖前面的。

3. 高频命令的语义拆解：比背命令更重要的是理解对象

3.1 clone 一个仓库后，你到底拿到了什么

git clone <远程地址> 这可能是大家用得最频繁的第一个命令。但很多人不知道，clone 不仅仅是把代码下载下来，它还把远程仓库的所有分支引用、标签、提交历史都拉到了本地。git branch -a 能看到本地分支和远程分支（以 remotes/origin/ 开头）的列表。

这里有个非常常见的问题：git clone 之后，你默认在哪个分支？答案是远程仓库的默认分支（通常是 main 或 master），并且这个分支会自动建立与远程分支的追踪关系。这就是为什么你能在 main 分支上直接 git pull 而不需要指定远程分支，因为 Git 已经知道你要拉取的是 origin/main。

如果用 git clone -b 分支名 <远程地址>，可以克隆指定分支，这在分支特别多的大型仓库里能省不少下载时间。但要注意，克隆指定分支并不表示只下载了这个分支的内容，只是默认工作区切换到了这个分支，其他分支的引用和对象仍然在 .git 里，只是工作区不显示而已。

3.2 工作区、暂存区、本地仓库：Git 的三层存储逻辑

Git 最核心的概念是三层存储结构：工作区（你看到的文件）、暂存区（git add 之后进入的区域）、本地仓库（git commit 之后进入的区域）。不理解这三层，很多命令都会用错。

git add 把文件从工作区放到暂存区，这一步其实是对文件内容做了一次快照。git commit 把暂存区的内容固化成一次提交。有个高频困惑：我 git add 之后又改了文件，再 git commit，为什么提交的不包含我后面的修改？就是因为第二次修改后的内容还在工作区，没有重新 git add 到暂存区。每次 commit 提交的都是暂存区的快照，不是工作区的当前状态。

git diff 展示工作区与暂存区的差异；git diff --cached 展示暂存区与本地仓库的差异。我强烈建议每个开发者养成 commit 前先跑 git diff --cached 的习惯，确认自己提交的内容没有多余文件、没有调试代码。

如果你想把暂存区的文件撤回来：git reset HEAD <文件> 把文件从暂存区放回工作区，但文件内容不变。如果你想把工作区某个文件的修改全部丢弃：git checkout -- <文件> 会用暂存区内容覆盖工作区。这两个命令我接手同事电脑时经常用，因为很多人加错文件，不知道怎么安全地撤回。

3.3 一次完整提交的推荐节奏

我自己的提交流程是这样的：

bash复制git status                  # 先看改动全貌
git diff                    # 再看具体改了哪些内容
git add 文件1 文件2          # 只加相关文件，不用 git add .
git diff --cached           # 确认暂存区内容
git commit -m "feat: 明确提交信息"

这套流程的关键是不要无脑 git add .。git add . 会把工作区所有改动（包括临时文件、调试代码）全部加入暂存区，很容易把不相干的内容混进一次提交里。正确姿势是把相关的改动用 git add 文件 精确加入，分多次提交。这也符合大家常说的"提交要做到原子性"——一次提交只做一件事，这样回溯时才找得准。

3.4 commit --amend 与 reset：改写历史的边界

git commit --amend 可以把最后一次提交的提交信息改掉，或者把新的改动并入最后一次提交。它的原理不是修改原提交，而是用一个新的提交对象替换掉原来的提交对象。所以这个命令执行后，原来的提交对象就"消失"了，变成孤儿提交。

这个命令有两个使用场景：一是提交信息写错了，需要改；二是刚提交完发现漏了一个文件，不想为此多一次提交，补充进去。但绝对不要对已经推送到远程的提交执行 amend，因为那会改写公共历史，导致其他人的本地仓库和远程仓库不一致，pull 的时候出现各种冲突。同样的逻辑适用于 git reset。git reset 有三个模式：--soft 只回退 HEAD，暂存区和工作区都保留；--mixed（默认）回退 HEAD 和暂存区，工作区保留；--hard 全部回退，工作区也会被覆盖成目标版本。reset --hard 是危险命令，用之前必须确认工作区没有需要保留的改动。

4. 提交信息规范：把 git log 变成团队的项目文档

4.1 为什么提交信息值得花时间

很多人觉得提交信息随便写写就行，反正代码能跑。但你在项目里待半年回头看，git log --oneline 就是一部项目演进史。如果提交信息全是"update"、"修改"、"fix bug"这种，那这份历史就等于没有。排查问题的时候，你只能通过二分法在代码里翻，效率极低。

相反，规范化的提交信息能让你在 git log 里快速定位到某次功能变更或某次缺陷修复，配合 git blame 找到具体责任人。这不是什么形式主义，是实打实的工程效率。

4.2 一套可以直接落地的提交格式

业界用得最广的是 Conventional Commits 规范，格式如下：

bash复制<type>(<scope>): <subject>

type 是提交类型，scope 是影响范围（可省略），subject 是简短的描述。常用的 type 有：

type	含义	示例
feat	新功能	`feat(user): 新增用户注册接口`
fix	修复 Bug	`fix(login): 修复登录超时跳转异常`
docs	文档变更	`docs(readme): 更新部署说明`
style	格式调整	`style(button): 调整按钮内边距`
refactor	重构	`refactor(auth): 抽离 token 校验逻辑`
test	测试相关	`test(api): 补充接口超时用例`
chore	构建/工具链	`chore(ci): 更新自动化流水线配置`
perf	性能优化	`perf(list): 优化大数据量渲染卡顿`

subject 用祈使语气，不超过 50 个字符，中文团队可以用中文描述，但保持简洁。有些团队还会要求正文里写清"为什么做这个改动、关联了什么需求单号"，这个用 git commit -m "feat(xxx): 主题" -m "正文说明" 来实现。

4.3 规范落地的工具辅助

光靠人自觉执行提交规范，效果有限，最好用工具兜底。commitizen 可以交互式引导提交；husky 配合 commitlint 可以在 commit 前拦截不规范的信息。

以 Node.js 项目为例，安装 commitlint 并配置规则：

bash复制npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
npx husky add .husky/commit-msg "npx commitlint --edit $1"

这样每次 git commit 时，如果提交信息不符合 type 规范，会被直接拦下来。虽然是 Node 生态的工具，但思路可以迁移到任何语言的项目，很多 CI/CD 流水线上也有关键字校验的插件。

5. 常见报错排查：从"不行"到"行"的完整链路

5.1 "git 不被识别"类报错的排查思路

"git : 无法将'git'项识别为 cmdlet、函数、脚本文件或可运行程序的名称。"这个报错信息在国内搜索量极大。它的本质是：系统找不到 git 的可执行文件。可能的原因有三个：Git 根本没装、Git 装了但没加进 PATH、终端是改 PATH 之前打开的。

排查链路：

先确认 Git 装没装：在开始菜单搜"Git"，看有没有 Git Bash 或者 Git GUI。如果没有，重新安装。
如果装了，找到安装目录（默认 C:\Program Files\Git\cmd），这个目录下有 git.exe。
打开系统环境变量设置（Win + R 输入 sysdm.cpl，切到"高级"→"环境变量"），在"用户变量"或"系统变量"中找到 Path，编辑，新增 C:\Program Files\Git\cmd。
关掉所有已打开的终端窗口，重新开一个，再执行 git --version。

这条链路能解决 95% 的同类问题。剩下 5% 是安装路径非常规，比如装到了 D 盘自定义目录，只要找到 cmd 子目录加到 PATH 里即可。还有个隐藏问题：如果系统里同时装了多个版本的 Git（比如某个软件捆绑安装了 Git），PATH 里靠前的那个版本可能有问题，这时候要检查 PATH 中 Git 相关条目的顺序。

login failed. check api token or gitlab version. log in via git if the version ... 这类报错常见于 GitLab 相关工具（比如 VS Code 的 GitLab 插件），本质是认证信息失效。在命令行场景中，更常见的报错是 remote: HTTP Basic: Access denied 或者 fatal: Authentication failed。

排查认证问题，我建议按这个顺序来：

检查远程地址：git remote -v，确认是 HTTPS 还是 SSH。
如果是 HTTPS 方式，Git 会使用凭据管理器（Windows 上是 Credential Manager）保存的账号密码/token。如果密码改过或 token 过期，旧的凭据还留着，就会一直认证失败。先打开控制面板的"凭据管理器"，找到对应 git 站点的凭据，删除，再重新 pull 一次，就会弹窗让你输新凭据。
如果你本来就该用个人访问令牌（Personal Access Token），确认 token 是否过期、权限范围是否足够。

彻底解决 HTTPS 免密问题，Git 支持凭据存储：

bash复制git config --global credential.helper store

store 模式会把凭据明文存在 ~/.git-credentials 文件里。安全性一般，适合个人电脑。如果在意安全，用 manager 模式（Windows 默认），它会用 Windows 凭据管理器加密存储。我自己的习惯是：HTTPS 用于零散小项目，SSH 用于正式项目。

5.3 SSH 免密的完整配置链路

SSH 方式没有输密码的困扰，前提是你配置好了公私钥。链路如下：

bash复制# 1. 生成密钥，建议用 ed25519
ssh-keygen -t ed25519 -C "你的邮箱"

# 2. 查看公钥内容
cat ~/.ssh/id_ed25519.pub

把公钥内容复制到 GitHub/GitLab 的 SSH Keys 设置页面。之后把远程地址改成 SSH 格式：

bash复制git remote set-url origin git@github.com:你的用户名/仓库名.git

第一次连接出现 Are you sure you want to continue connecting (yes/no)? 时输入 yes，然后测试 ssh -T git@github.com。如果返回问候语，说明免密已经通了。

这里有个坑：Windows 用户如果之前用的是 Git Bash 生成密钥，后续在 PowerShell 里连不上，可能是 ssh-agent 服务没启动。可以用 Get-Service ssh-agent 查看状态，如果需要手动启动就用管理员身份运行 Start-Service ssh-agent 并设为自动。

提示：ed25519 是目前推荐的非对称加密算法，比传统的 RSA 2048 更安全、密钥更短、生成更快。老的系统如果兼容性有问题，再用 ssh-keygen -t rsa -b 4096 生成 RSA 密钥。

5.4 合并冲突与"拒绝提交"类问题

git pull 时遇到 Please commit your changes or stash them before you can merge，这个报错的意思是：你本地有未提交的改动，而 pull 试图合并远程更新时可能与这些改动冲突。Git 出于安全考虑拒绝合并。

两个选择：要么先把改动提交了，要么先把改动藏起来。git stash 会把工作区改动暂存起来，让工作区回到干净状态，pull 完成后再 git stash pop 恢复。stash 系列命令是处理"临时切分支、临时拉代码"场景的利器：

bash复制git stash                # 保存当前改动
git pull                 # 拉取远程更新
git stash pop            # 恢复改动

如果 pop 时出现冲突，Git 会告诉你哪些文件冲突。此时打开冲突文件，会看到：

bash复制<<<<<<< Updated upstream
远程的代码
=======
你的本地修改
>>>>>>> Stashed changes

这些标记之间的内容就是冲突区域，你需要手动决定保留哪个版本，然后删除标记，重新 git add 和 git commit。处理冲突是每个开发者都绕不开的技能，我的建议是慎用"直接采纳某个版本"的快捷按钮，因为冲突往往意味着两边的修改都有价值，盲选容易丢失逻辑。

6. 效率工具与安全红线：小乌龟、VSCode 与源码泄露

6.1 TortoiseGit（小乌龟）的适用人群与使用体验

很多不习惯命令行的开发者喜欢用 TortoiseGit，就是大家常说的"小乌龟"。它的特点是把 Git 操作集成到 Windows 右键菜单里，克隆、提交、更新、切换分支都能通过图形界面完成。

小乌龟对纯新手确实友好，但你如果打算长期吃这碗饭，我劝你还是先把命令行用熟再回图形界面。为什么？因为图形界面隐藏了 Git 的内部逻辑，遇到报错你根本不知道发生了什么。比如图形界面里"Switch"和"Merge"选项很多新手分不清，出了问题只能干瞪眼。命令行虽然一开始有点陡峭，但每个命令的语义清晰，排查问题有方向。

如果你确实要装小乌龟，注意安装完要重启一次资源管理器，否则右键菜单可能不刷新。另外小乌龟的设置里有一个"Git 可执行文件路径"的选项，必须指向你安装 Git 的目录，否则它会报错找不到 Git。

6.2 VSCode 与 Cursor 里的 Git 集成体验

VSCode 内置了 Git 支持，源代码管理面板可以看到改动文件列表、输入提交信息、点击提交和推送。这对绝大多数场景已经够用。我额外推荐装一个 GitLens 扩展，它能在代码行尾显示这行代码是谁、在哪个提交里写的，对于理解历史代码极其有用。

这里有个大家常遇到的问题——Cousor 或 VSCode 里"哪里查看绑定 git"。其实不需要特别的绑定，VSCode 类编辑器首次打开一个 Git 仓库时，会自动识别并使用系统的 git 可执行文件。如果你的编辑器报错"Git 未安装"或找不到 git，检查两处：一是系统 PATH 里有没有 Git，二是编辑器设置里 git.path 是否被误改。一般情况下把 git.path 留空，让编辑器自动探测最省事。

VSCode 中还有一个容易踩的坑：换行符设置。编辑器右下角（或者设置里的 files.eol）如果设置成 \n（LF），在 Windows 下会把文件行尾改成 LF，如果仓库没有 .gitattributes 约束，提交时会有"整个文件都变了"的假象。解决办法就是前面说的，在仓库里配好 .gitattributes。

6.3 .git 目录泄露到底是怎么回事

这个我在安全巡检时遇到不止一次了。.git 目录是 Git 仓库的核心，里面存着完整的历史记录、所有分支、所有提交。如果你把项目部署到 Web 服务器时，把 .git 目录也一并传上去了，而 Web 服务器又允许直接访问 http://你的域名/.git/config 或者 .git/HEAD，那么任何一个人都能通过这个入口把整个仓库的源码和提交历史下载下来。这就是传说中的"Git 目录泄露"。

Git 目录泄露之所以危险，是因为它泄露的不只是当前代码，还包括历史版本。比如你某个历史提交里不小心写进了数据库密码、API 密钥，即使后面删掉了，只要历史记录还在，攻击者就能通过 .git 目录恢复到那个版本，把密钥捞出来。

防护手段分三层：

发布代码时绝不包含 .git 目录。很多 CI/CD 流水线工具在构建时会自动排除 .git（比如 Docker 构建上下文、rsync 部署脚本），但手动上传到服务器时必须检查。
Web 服务器配置禁止访问 .git 路径。Nginx 下加一条：

bash复制location ~ /\.git {
    deny all;
}

Apache 下用 .htaccess 或 httpd.conf 加上：

bash复制RedirectMatch 404 /\.git

敏感信息绝不进仓库。数据库密码、密钥、token 一律放在环境变量或 .env 文件里，并且 .gitignore 里忽略掉。如果发现已经提交了敏感信息，改掉密码/密钥本身，不要只做"删除并提交"——因为历史里还是能翻到。

6.4 .gitignore 设置的一点进阶技巧

.gitignore 不只是"忽略某些文件"那么简单。如果你忽略一个目录，但想保留其中的某些文件，比如，忽略 config/ 但保留 config/example.json，写法是：

bash复制config/*
!config/example.json

注意 ! 取反只有在包含它的目录没有被完全忽略时才有效。也就是说，如果你写的是 config/（忽略整个目录），那么 !config/example.json 是不生效的。正确姿势是忽略目录里的内容而不是目录本身。

还有一个容易出问题的是已经提交过的文件。如果某个文件在 .gitignore 里被忽略了，但它已经被 git add 过并提交了，那么后续对它的修改仍然会被 Git 追踪。这时候需要从仓库中删除（保留工作区文件）：

bash复制git rm --cached 文件名

执行完后提交，文件才真正停止被追踪。这个操作很常见，比如项目早期把 .env 文件提交上去了，后来才发现要忽略它。

7. 实际操作中积累的几个小习惯

最后分享几个这些年养成的、切实能提升效率的小习惯。

第一，给 git 命令配置别名。 比如 git config --global alias.co checkout、git config --global alias.br branch、git config --global alias.st status、git config --global alias.lg "log --oneline --graph --all --decorate"。lg 这个别名我每天用无数次，图形化的提交历史在一屏内就能看清整个项目的演进。

第二，学会用 git reflog 救命。 如果不小心 reset --hard 掉了某个提交，或者 rebase 搞砸了，不要慌。git reflog 会列出所有 HEAD 的移动记录，哪怕提交对象已经脱离了分支引用，只要还在对象库中，就能通过 git reset --hard <哈希> 找回来。这是我在实习期差点丢了三天工作量之后学到的教训。

第三，pull 之前先看远程有什么更新。 git fetch 只拉取远程更新到本地仓库，不会改变工作区。git fetch 之后用 git log --oneline origin/main..main 看本地领先远程多少提交，用 git diff origin/main 看差异。确认无误后再 git merge 或 git pull。很多冲突其实一开始就能预判，提前看一眼能少很多麻烦。

第四，提交信息别偷懒，但也别过度。 我见过团队要求提交信息必须带需求单号、必须写 200 字详情的，结果是大家被逼急了乱编。真正高效的规则是：类型明确、主题清晰、正文写关键决策即可。规范是为人服务的，不是用来制造负担的。

第五，出了问题先看 git status 和 git log --oneline -5。 我在给团队做内训的时候反复强调：Git 的所有报错都不是随机事件，它一定告诉你哪里不对了。很多人一遇到报错就蒙，其实 git status 会告诉你当前状态，git log 会告诉你最近发生了什么。基于这两个输出，80% 的问题都能自己定位到。

Git 这个东西，初看是个版本管理工具，用久了你会发现它其实是一套完整的协作方法论。安装配置只是第一关，真正拉开效率差距的是你对三层存储结构的理解、对命令语义的把握、以及面对报错时的排查思路。上面这些内容，从安装到免密、从规范到安全、从命令行到图形工具，都是我这些年一步步踩出来、验证过的东西。你按着顺序过一遍，日常开发中 Git 相关的痛点基本都能覆盖。后面如果再遇到什么奇葩问题，欢迎随时来讨论，Git 的坑我踩得多了，经验还是够用的。