Git 核心命令与协作实践：从安装配置到冲突解决全流程

1. 环境准备与基础配置

1.1 安装方式选择：没有标准答案，只有合适不合适

做技术这一行，Git 基本属于“躲不开”的底盘工具。但“装好”和“配好”是两码事——我刚入行那会儿，下载安装包一路点 Next 就算装完了，结果第一次 commit 直接提示 “Please tell me who you are”，整个进度卡住，非常尴尬。

先说安装。Windows 用户我比较推荐去官网下载 Git for Windows，这个包自带 Git Bash，相当于给你一个模拟 Linux 命令行环境，体验比裸 CMD 好太多。macOS 用户如果装了 Homebrew，一条 brew install git 就搞定，干净利落；没装 Homebrew 的直接官网下载 .dmg 安装包也没问题。还有一些 Linux 发行版的场景，比如 CentOS 用 yum install git、Ubuntu 用 apt install git，这个就看团队基础环境怎么定了。

安装类型的选择上有个小细节容易被忽略：执行 git 命令时的环境变量和换行符处理。Windows 安装到最后一步会问 “Adjusting your PATH environment”，强烈建议选 “Git from the command line and also from 3rd-party software”，这样后续在项目终端里调用 git 命令不会出现 “command not found” 的坑。

提示：如果你装完 Git 之后在 IDE 终端里输 git 报错“不是内部或外部命令”，优先检查 PATH 配置而不是重装。右键“此电脑→属性→高级系统设置→环境变量”，确认 C:\Program Files\Git\cmd 这个路径存在。

1.2 配置 user.name 和 user.email：提交记录的第一道门槛

Git 提交记录里每一行 commit 都会带上作者信息，这个信息就是靠 user.name 和 user.email 生成的。很多人最开始会忽略这件事，等到代码提交到团队仓库之后才发现作者名是全角空格或者公司邮箱写错，改起来非常麻烦，因为历史记录里的作者信息原则上不该乱动，动了会影响整个团队的提交历史一致性。

配置的命令很简单：

bash复制git config --global user.name "your_name"
git config --global user.email "your_email@example.com"

加 --global 表示这台机器上所有仓库都用这个身份；不加的话就只对当前仓库生效。我自己的习惯是全局配一个个人邮箱，公司项目的仓库里单独配公司邮箱，用命令 git config user.email "work@company.com" 就行。

还有个容易踩的坑：某些团队用 GitLab 或 Gitea 时，提交邮箱和账号邮箱不一致，代码推送后头像和贡献统计不显示。所以在团队协作场景下，提交邮箱尽量和平台注册邮箱保持一致，省得后面追溯代码贡献时对不上账。

2. 初始化仓库与核心概念理解

2.1 git init 与 clone：从零开始和从别处拉取的差异

新项目要纳入版本管理，第一件事是进入项目根目录执行：

bash复制git init

执行完之后目录下会出现一个隐藏的 .git 文件夹，这个文件夹就是仓库的“大脑”，所有版本记录、分支信息、暂存区数据都存里面。注意一下，这个文件夹千万别删，删了历史全没。

git clone 则是把远程仓库整个拉到本地，命令格式比较直观：

bash复制git clone https://github.com/user/repo.git

克隆下来之后不需要再 git init，因为仓库已经带上了 .git 目录，里面已经记录了完整的远程地址和分支信息。如果你的网络环境一般，可以加 --depth=1 做浅克隆，只拉最新一次提交，速度会快不少，但代价是历史记录不全，后续操作受限，比如基于旧提交的 diff 和回滚都搞不了。平时开发建议全量克隆，除非只做临时参考。

2.2 工作区、暂存区与版本库的“三板斧”逻辑

这三个区域的划分是理解 Git 一切操作的基础。用个生活化类比：工作区是你手里的草稿纸，暂存区是你挑出来准备放进档案袋的文件，版本库是档案室里已经归档的档案。

一条新文件从创建到入库，完整路径是：工作区改动 → git add 进暂存区 → git commit 进版本库。中间任何一步停住都能随时调整，这就是 Git 给你留的“反悔空间”。

日常提交流程很多人习惯一条 git add . && git commit -m "xxx" 走到底，图省事。但遇到临时调试代码、无用的日志输出、测试用的死代码混在同一个 commit 里时，后续排查问题会非常头疼。所以我建议，提交前先 git status 看清楚改了哪些文件，再按功能拆分成多个 commit，一个 commit 只干一件事。这样 git log 看起来清晰，将来 git bisect 定位问题也能精确到某次提交。

实操心得：我见过不少新人一上来就是 git add -A，把删除的文件、新增的文件、改动的文件全部一股脑塞进一个暂存区。虽然功能上没问题，但代码 review 时 reviewer 面对一个几百个文件变更的 PR，体验极差。经验是分组提交，比如：

bash复制git add src/module/user/       # 核心逻辑改动
git commit -m "feat: add user login"
git add tests/                 # 对应测试用例
git commit -m "test: add user login cases"

3. 核心命令详解：日常开发高频场景拆解

3.1 status、log、diff：提交之前的“三件套”体检

每次准备提交之前，先跑三个命令确认当前状态，这是我从带团队以来一直要求组员养成的习惯。

git status 看得是当前工作区的整体状态，哪些文件改了，哪些存进了暂存区，哪些还是未跟踪状态。输出信息很直观，但还是要看得细：红色是未暂存的改动，绿色是已暂存待提交的改动，未被跟踪的新文件列在 Untracked files 下面。

git log 看的是提交历史。默认 git log 会把完整 hash、作者、日期、提交信息全部列出来，信息量很大，我日常基本只跑 git log --oneline，一行一条简洁得多。想看最近几条就加 -5，比如 git log --oneline -5，足够用。

git diff 比较的是不同文件版本之间的差异。三种用法要分清楚：

• git diff 比较工作区和暂存区的差异
• git diff --cached 比较暂存区和最近一次提交的差异
• git diff HEAD 比较工作区和最近一次提交的差异

实际场景举例：你改了半个多小时代码，自己都不记得动了哪些行，这个时候 git diff 扫一遍，心里立马有数，改到哪里、有没有引入多余空格、有没有误删空行，一目了然。

3.2 add、commit、rm、mv：提交操作的正确姿势与撤销补救

git add 的常用形式无非三条：

bash复制git add <file>       # 指定文件
git add .            # 所有改动（含新增和删除）
git add -u           # 只暂存已有文件的改动，不含新增文件

这里想特别提醒 git add . 的隐患：如果项目根目录里有 .env 这种带密钥的本地配置文件，还没来得及写进 .gitignore，一条 git add . 就把密钥送进了暂存区。后面再 commit 推送上去，就算立刻删掉，历史记录里还留着。正确做法是项目初始化时第一时间配好 .gitignore，把构建产物、IDE 配置、本地环境文件全部排除。

git commit 有几个值得记住的变体：

bash复制git commit -m "feat: add api endpoint"      # 常规提交
git commit -a -m "fix: typo"                # 跳过 git add，直接提交所有已跟踪文件的改动
git commit --amend -m "new message"         # 修改上一次提交的说明

--amend 除了能改提交说明，还能把漏提的文件并入上一次提交。比如你 commit 完发现少改了一个文件，先 git add 漏掉的文件，再 git commit --amend --no-edit，就不会产生一条冗余的 “fix typo” 记录。不过 --amend 只适合还没有推送到远程的本地提交，如果已经 push 出去了就千万不要动，历史重写会搅乱协作者的本地分支。

删除文件对应的命令是 git rm，和直接删文件有区别。git rm <file> 会把文件从工作区和暂存区同时删除，一步到位；如果你只是用资源管理器删了文件，Git 会显示 “deleted” 状态，还得手动 git add <file> 让暂存区同步。移动或重命名文件则用 git mv <old> <new>，Git 会根据内容自动识别这是 rename 而不是删了再加，保留文件修改历史。

3.3 分支操作：创建、切换、合并的底层逻辑

分支是 Git 中绕不开的核心概念。一条分支本质上只是一个指向某个提交对象的可变指针，创建分支的开销几乎为零，这也是为什么 Git 能支撑高频并行开发。

日常命令不复杂：

bash复制git branch                     # 查看本地分支
git branch feature/login       # 创建分支
git checkout feature/login     # 切换分支
git switch feature/login       # 新版写法，和 checkout 功能等价
git switch -c feature/login    # 创建并切换

checkout 和 switch 功能上有重叠，2022 年之后 Git 官方逐步推荐 switch 和 restore 替代部分 checkout 的职责，从语义上把“切换分支”和“恢复文件”给区分开了。不过大部分老项目和老资料还在用 checkout，两种都认识、都能用，不会出错。

合并操作的分水岭在于 merge 和 rebase 的选择。git merge 会保留两条分支的合并痕迹，生成一个 merge commit，优点是历史真实、时间线清晰，缺点是有多出一条 “Merge branch ‘xxx’ into ‘yyy’” 的提交记录，日志看起来略显杂乱。git rebase 则是把当前分支的提交“搬运”到目标分支的最新提交之上，历史是一条直线，干净利落，但代价是改了提交节点顺序，如果分支已经被推送到远程再由别人 clone 使用，rebase 会把别人的历史搞乱。

我给团队的硬性规定是：本地分支随便 rebase，公共分支只准 merge。这个原则基本能覆盖 90% 以上团队的协作需求。

3.4 远程仓库协作：push、pull、fetch 的分工

远程仓库是多人协作的枢纽，理解了 push、pull、fetch 三个命令的区别，就掌握了协作流程的核心。

git fetch 只会把远程仓库的最新提交拉下来，更新远程跟踪分支，比如 origin/main，但不会动你当前工作区的任何东西。git pull 则会先 fetch，再把远程分支合并到当前分支，相当于 fetch + merge 的组合操作。如果你想要的是拉下来看看再说，那就用 fetch，手动决定怎么合并。

推送代码的常规命令：

bash复制git push origin main                     # 推送到指定远程的指定分支
git push origin --delete feature/old     # 删除远程分支
git push --set-upstream origin feature/x # 第一次推送新分支并建立关联

--set-upstream 这个参数挺容易被忽略的。你创建了一个本地分支，第一次 git push 如果不加参数，Git 会报错，因为本地分支不知道要推到远程的哪个分支。加上 -u 参数建立追踪关系之后，后续直接 git push 就能推，省得每次带参数。另一种方式是加 -f 强制推送，但这个操作相当危险，会覆盖远程仓库的历史，除非团队明确约定并且你清楚地知道自己在做什么，否则永远别用 git push -f。

3.5 撤销与回滚：reset、revert、stash 的场景拆解

这一节是 Git 操作里最需要谨慎的部分，很多人在这里吃过亏，我也踩过不少坑，拆开来讲。

git reset 的作用是把当前分支的 HEAD 指针移动到指定提交，同时可以控制暂存区和工作区怎么变。三种模式的差别要记牢：

bash复制git reset --soft HEAD~1   # 只移动 HEAD，暂存区和工作区保留
git reset --mixed HEAD~1  # 移动 HEAD，重置暂存区，工作区保留（默认）
git reset --hard HEAD~1   # 移动 HEAD，暂存区和工作区全部重置

--hard 玩不熟就会导致本地未提交的改动全部丢失，文件回到指定提交时的状态。所以我给新人的建议是：不确定要不要保留本地改动时，先 git stash 暂存，再执行 reset，安全系数高很多。

git revert 则是不动历史，用一次新的反向提交把之前的改动“抵消”掉。适用场景是已经推送到远程的错误提交，比如你误提交了一条 buggy 代码并且已经 push，直接用 git revert <commit> 生成一条新的提交把代码改回去，这样远程历史不会被重写，协作者 pull 的时候也比较顺利。

git stash 是临时保存工作区改动的最佳工具。场景很典型：你在 feature 分支写了一堆代码还没 commit，突然需要切到 hotfix 分支处理线上 bug。直接 checkout 会报错或带着改动一起切过去，非常容易出问题。正确姿势是：

bash复制git stash            # 保存当前改动
git checkout hotfix  # 切过去干活
# 处理完
git checkout feature
git stash pop        # 恢复改动

stash 还能带消息保存多条，git stash list 查看，git stash apply stash@{1} 恢复指定的一条。这条命令链我在日常工作中几乎每周都会用到好几次，算得上高频救场工具。

4. 团队协作场景：冲突解决与代码审查

4.1 合并冲突的产生与处理流程：别慌，冲突只是提示不是报错

很多新人一看到 “CONFLICT” 就浑身冒汗，其实冲突只是 Git 在说“我没法替你决定哪份代码是对的”。两个分支改了同一个文件的同一块区域，Git 合并时生成不了唯一结果，就会把它标记为冲突，交给你来人工仲裁。

冲突文件里会留下标记：

code复制<<<<<<< HEAD
当前分支的代码
=======
另一条分支的代码
>>>>>>> feature/xxx

解决流程说起来也挺固定：打开文件，把 <<<<<<<、=======、>>>>>>> 三行标记删掉，保留你想要的内容，再 git add 该文件，最后 git commit 生成合并结果。关键是不要盲目全选某一方代码，要看两边的改动是什么意思，理清别让正确代码被误删。

一种反面典型是遇到几十个冲突文件时，不逐个确认直接在 IDE 的冲突界面点 “Accept Both”。这在某些场景下能解决格式问题，但经常把两边无关的代码全部保留下来，产生大量冗余甚至错误的合并结果。我的习惯是先在 IDE 的 merge 视图里把每个冲突点过一遍，理清改动意图后统一处理。

4.2 代码审查：关联提交信息与排查工具

团队协作里除了写代码，code review 也逃不掉。Git 能帮你做的有三个方面：

一是关联提交和任务。提交信息里写上需求单号或 Bug 单号，比如 feat: #1123 add pagination，后续在 issue 系统里直接通过单号跳转提交记录，追踪问题来源会省力很多。

二是查看某次提交做了哪些改动。命令是 git show <commit>，展示该提交的变更内容和提交说明。review 的时候想快速看这次提交涉及哪些文件，用 git show --stat <commit> 更直观。

三是定位代码是哪次提交引入的。经典的 git blame <file>，逐行标注每一行代码最后是谁、哪次提交改动的。排查“这可执行文件里怎么会有这么离谱的逻辑”的时候，这个命令比翻日志快得多。

代码 review 时还有两个实用的操作：git log -p <file> 查看某个文件的完整提交历史，git diff main...feature/xxx 查看分支相对于主分支的所有差异。这两个命令能让 review 的视野既聚焦又全面。

5. 常见问题与排查技巧实录

5.1 身份信息未配置导致的提交失败

现象很典型：执行 commit 的时候报一堆红字，大概是 “Author identity unknown” 或 “Please tell me who you are”。原因就是本地没配置 user.name 和 user.email。

解决思路上文已经说过，按全局或仓库级补配置即可。不过在这里提醒一个细节：如果你已经设置了全局配置，但在某个仓库内跑 git config user.name 显示空，可能是之前有人在项目里加了 .git/config 里的空配置项覆盖了全局值。检查命令：

bash复制git config --list

如果看到当前仓库配置里 user.name 是空的，直接重新按仓库配置一遍就行。

5.2 分支与提交丢失：找回“误删”的文件与提交

git reset --hard 之后发现想留的代码没了，很多人第一反应是天塌了。实际上 Git 有安全网，提交对象在垃圾回收之前都还能找回来。git reflog 会记录 HEAD 指针的每一次移动，包括 reset、checkout 等操作，相当于一个操作日志。

找回步骤：

bash复制git reflog
# 找到 reset 之前的 SHA
git reset --hard <sha>

如果你只是误删了一个还没提交的文件，git checkout -- <file> 能恢复（只要工作区历史里还有）。不过要是文件从未 git add 过，那 Git 无从追踪，只能靠本地磁盘的回收工具软件来挽救。这条总结成一句经验：能 commit 就尽快 commit，哪怕提交信息只有一句 “wip”，也给将来留了退路。

5.3 大文件与敏感信息：两个团队协作中的隐忧

仓库体积膨胀是个隐形问题。有些团队把生成的静态资源、数据库 dump、node_modules 直接提交进仓库，clone 的时候慢到怀疑人生。解决方案是大文件不用 Git 管，改用 Git LFS（Large File Storage），把大文件的指针存进仓库，真实内容放在 LFS 服务器上。

敏感信息比大文件更危险。.env、API key、数据库密码这类文件的不要提交到仓库。一旦发现已经提交并推送了，最先做的是去平台后台清理历史，而不仅仅是删文件再提交一次，因为历史里还留着原始内容。git filter-branch 或 git-filter-repo 可以重写历史，但操作复杂且影响所有协作者，所以最好的策略永远是提前在 .gitignore 里堵住。

5.4 A successful Git branching model 的轻量实践

最后聊一部分工作流问题，既然团队协作，分支策略就得讲究点。很多人问是不是必须照搬 Git Flow 那套 develop、feature、release、hotfix 全量流程。我的观点是：根据团队规模和发布频率来定，不要照搬。

三人以内的小团队，一个 main 分支打天下完全够用。每个人从 main 切 feature 分支开发，完成之后合并回来。哪怕直接从 main 分支上开发，配合频繁提交和清晰的提交信息，风险也可控。

中等规模团队可以上 GitHub Flow：main 永远是稳定可发布状态，所有开发在 feature 分支进行，通过 Pull Request 合并，合并前必须有 review。这套策略简单且灵活性高，适用于绝大多数互联网产品团队。

传统企业或需要严格版本管理的场景才考虑 Git Flow，因为它区分了开发、预发布、生产三种长期分支，流程更长，管控更严，代价是协作成本明显增大。

注意：无论选哪种分支策略，都得在项目 README 里写清楚协作规范。否则每个成员按自己的习惯来，仓库早晚变成一锅粥。

写在最后的一些实操习惯

Git 这东西，命令都能搜到，但真正拉开体验差距的是那些使用习惯。我在实际开发中慢慢攒了几条自己的规矩，分享出来供参考。

第一条，提交前必看 diff。不管多小的改动，git diff 扫一眼再 commit，能挡住一半以上的低级错误。

第二条，分支名和提交信息尽量语义化。分支叫 fix/login-error，提交信息写 fix: prevent login error when password contains special chars，三个月后回看历史完全不会一头雾水。

第三条，定期清理无用分支。本地 git branch -d feature/xxx，远程 git push origin --delete feature/xxx，保持仓库清爽。

还有一条小技巧：commit 信息的第一行尽量控制在 50 个字符以内，用英文写一句总结，要加说明再空一行写详细描述。这个格式来自大量开源项目的约定，利于团队协作时快速浏览。

Git 工具本身没有多玄乎，无非就是搞清楚工作区、暂存区、版本库、远程仓库这几个对象之间的关系，再加上熟练常用命令。真正值钱的是面对复杂场景时的判断力：什么时候该 reset，什么时候该 revert，什么时候该 stash。这些判断力不是看书看出来的，是在真实的代码冲突和历史事故里磨出来的。希望你少踩坑，多用好它。