在团队协作开发中，Git 是必不可少的版本控制工具。然而，很多开发者在日常工作中只会机械地使用 add、commit、push 三连，一旦遇到分支合并冲突、代码回退等场景，就容易手忙脚乱。
本文将系统梳理 Git 的常用命令，并针对最让人头疼的“版本冲突”问题，提供一套标准化的实战解决方案。
一、 Git 常用命令速查
为了方便记忆，我们将常用命令分为四大类。
- 基础操作（日常搬砖必备）
· git init：在当前目录初始化一个新的 Git 仓库。
· git clone ：克隆远程仓库到本地。
· git status：最常用的命令。查看当前工作区和暂存区的状态（哪些文件被修改、哪些已暂存、是否有冲突）。
· git add / git add .：将工作区的修改添加到暂存区。
· git commit -m “msg”：将暂存区的内容提交到本地仓库。
· git push：将本地分支推送到远程仓库。
· git pull：拉取远程代码并合并到本地（相当于 git fetch + git merge）。
- 分支管理（团队协作核心）
· git branch：查看本地分支（-a 查看所有分支）。
· git branch ：创建新分支。
· git checkout / git switch ：切换分支。
· git checkout -b ：创建并切换到新分支。
· git merge ：将指定分支合并到当前分支。
· git branch -d ：删除本地分支。
- 查看历史与差异
· git log：查看提交历史（–oneline 让记录更简洁）。
· git diff：查看工作区与暂存区的差异。
· git reflog：救命命令。查看所有 HEAD 的移动记录，即使误删了分支或 reset 错了，也能靠它找回。
- 撤销与回退（高危操作，需谨慎）
· git reset --hard <commit_id>：彻底回退。丢弃目标提交之后的所有修改（本地未推送时使用）。
· git revert <commit_id>：安全撤销。创建一个新提交来抵消指定提交的内容，保留历史记录（已推送到公共分支时使用）。
· git stash：将当前未提交的修改暂存起来，让工作区变干净，方便切换分支。
· git stash pop：恢复最近一次暂存的修改。
二、 理解 Git 冲突：为什么会产生冲突？
冲突（Conflict）产生的根本原因：两个人（或两个分支）修改了同一个文件的同一行代码，Git 无法自动决定该保留哪一份。
冲突发生的时间点：
冲突不会在你 git push 的时候发生。如果你落后于远程分支，Git 会直接拒绝你的推送，并提示你先去拉取。
冲突只会在你执行 git pull、git merge 或 git rebase 的时候爆发。
谁来解决冲突？
谁触发了合并（执行 pull/merge），谁就需要在自己的本地解决冲突。其他同事在自己的电脑上是看不到这个冲突的。
三、 版本冲突的标准解决方案（实战）
假设你正在 feature 分支开发，执行 git pull origin main 后，控制台提示 CONFLICT (content): Merge conflict in index.js。请按照以下步骤处理：
第一步：定位冲突文件
执行 git status，你会看到提示 both modified: index.js，这就是冲突文件。
第二步：在编辑器中打开并解决冲突
用你的本地编辑器（如 VS Code、WebStorm）打开 index.js。你会看到类似下面的冲突标记：
<<<<<<< HEAD
// 这是你当前分支（本地）的代码
console.log("我的修改");
=======
// 这是传入分支（别人的代码）
console.log("同事的修改");
>>>>>>> main
如何解决？
你需要与同事沟通，决定最终保留哪段代码，或者将两者融合。然后手动删除 <<<<<<<、=======、>>>>>>> 这三行标记，把文件修改成最终正确的样子。
💡 IDE 小技巧：现代 IDE 会在冲突代码上方提供快捷按钮：
· Accept Current Change（保留你的）
· Accept Incoming Change（保留别人的）
· Accept Both Changes（两者都保留）
点击对应按钮，IDE 会自动帮你删掉标记。
第三步：标记冲突已解决
代码修改完成并保存后，执行：
git add index.js
第四步：完成合并并推送
git commit -m "fix: 解决 index.js 合并冲突"
git push
第五步：放弃合并（可选）
如果冲突太复杂，你想回到合并前的状态，执行：
git merge --abort
四、 进阶：Rebase 时的冲突处理
如果你使用的是 git rebase 而不是 merge，冲突的处理方式略有不同。
Rebase 会一个提交一个提交地重放。如果遇到冲突，它会停下来。
- 解决完当前冲突后，执行 git add .。
- 不要执行 git commit，而是执行 git rebase --continue，继续重放下一个提交。
- 如果想放弃 rebase，执行 git rebase --abort。
五、 如何优雅地减少冲突？（团队最佳实践）
- 勤拉取：每天开工前、提交代码前，先 git pull。避免本地代码落后太多。
- 小步提交：不要攒一个星期的代码一次性提交，提交粒度越小，冲突的范围就越小。
- 分工明确：尽量避免多人同时修改同一个文件的同一模块。
- 公共分支禁用 rebase：永远不要对已经推送到远程的公共分支（如 main、develop）使用 git rebase，更不要使用 git push -f（强推）。这会重写历史，导致其他同事的代码彻底崩溃。
总结
Git 冲突并不可怕，可怕的是不懂原理盲目操作。记住核心口诀：
· 本地未推送，回退用 reset；
· 公共已推送，撤销用 revert；
· 拉取代码遇冲突，手动解决再 add、commit；
· 公共分支不 rebase，强推 (push -f) 绝对是禁忌。
希望这篇指南能帮你理清 Git 的核心逻辑，在团队协作中更加游刃有余！
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2601_95034420/article/details/167117536
