Git 是目前最流行的分布式版本控制系统，而命令行界面（CLI）则是许多开发者高效使用 Git 的首选方式，在团队协作或长期的项目开发中，代码冲突是不可避免的问题，尤其是在多人同时修改同一文件的同一部分时，掌握通过命令行解决 Git 冲突的技能，对于开发者来说至关重要，本文将详细介绍 Git 冲突产生的原因、解决冲突的完整流程以及一些实用技巧,帮助开发者从容应对协作中的冲突情况。
Git 冲突的本质是 Git 无法自动合并两个或多个分支的修改，当两个分支对同一文件的同一行进行了不同的修改，或者在其中一个分支中删除了文件而在另一个分支中修改了该文件时，Git 就无法确定应该保留哪个版本，从而触发冲突状态，Git 会暂停合并过程，并提示用户手动解决冲突，冲突的标记会直接出现在发生冲突的文件中，通常以 <<<<<<<、 和 >>>>>>> 分隔，分别代表当前分支、共同祖先和另一个分支的修改内容。
解决 Git 冲突的完整流程通常包括以下几个步骤，当执行 git merge、git rebase 或 git pull 等命令时，如果发生冲突，Git 会在终端输出明确的提示信息，Automatic merge failed; fix conflicts and then commit the result. 开发者需要进入包含冲突的文件目录，使用文本编辑器打开这些文件,文件中会包含类似以下的冲突标记：
<<<<<<< HEAD
This is the content from the current branch.
=======
This is the content from the common ancestor.
>>>>>>> feature-branch开发者需要手动编辑这些文件，删除冲突标记，并根据业务逻辑保留或整合两个分支的修改，如果当前分支的修改和 feature-branch 的修改都需要保留,可以将内容合并为：
This is the content from the current branch.
This is the content from the feature-branch.解决完所有冲突文件后，需要使用 git add 命令将已解决的文件标记为已解决状态。git add conflict-file.txt 表示该冲突文件已被处理，执行 git commit 或 git rebase --continue（如果是 rebase 过程中发生的冲突）来完成合并或变基操作，Git 会创建一个新的提交,记录冲突解决的结果。
为了更高效地管理冲突，开发者可以借助一些 Git 命令和工具。git status 命令可以查看当前仓库的状态，包括哪些文件发生了冲突，输出中会明确列出 both modified: conflict-file.txt 这样的信息。git diff 命令可以查看冲突的具体内容，git diff --conflict=merge 会显示冲突的详细差异，帮助开发者快速定位问题，对于复杂的冲突，可以使用 git mergetool 命令调用图形化合并工具（如 KDiff3、Beyond Compare 等），这些工具提供了可视化的界面,方便开发者对比和合并不同版本的代码。
在团队协作中，预防冲突的发生同样重要，以下是一些减少冲突的最佳实践：频繁地从主分支（如 main 或 master）拉取最新代码并合并到自己的开发分支，保持分支的同步，将大的任务拆分为小的、独立的提交，避免长时间脱离主分支开发，明确分支的职责范围，减少多个开发者同时修改同一文件的概率，在提交代码前，确保本地代码已经通过测试,避免将有问题的代码合并到共享分支。
以下是一个通过命令行解决冲突的示例场景，假设当前在 main 分支上有一个文件 app.js为 let version = '1.0';，开发者小明创建了一个 feature-login 分支，并将 app.js 修改为 let version = '1.1'; 并提交，小红在 main 分支上将 app.js 修改为 let version = '1.0.0'; 并提交，当小明尝试将 feature-login 分支合并回 main 时，就会发生冲突。app.js 的内容会变成：
<<<<<<< HEAD
let version = '1.0.0';
=======
let version = '1.0';
>>>>>>> feature-login小明需要根据需求决定保留哪个版本，或者合并为 let version = '1.1.0';，然后执行 git add app.js 和 git commit -m "resolve version conflict" 完成合并。
在实际开发中，开发者可能会遇到一些与冲突相关的特殊问题，如何处理二进制文件（如图片、视频）的冲突？由于二进制文件无法直接显示差异，Git 通常会直接选择其中一个版本，或者提示用户手动替换文件，开发者需要根据实际情况决定保留哪个版本的二进制文件，然后通过 git add 标记解决，另一个常见问题是 rebase 过程中的冲突，与 merge 不同，rebase 会尝试将分支的提交逐个应用到目标分支上，因此在每个提交都可能发生冲突，解决 rebase 冲突后，需要使用 git rebase --continue 继续后续提交的合并，如果需要跳过某个冲突提交，可以使用 git rebase --skip。
Git 冲突是协作开发中的正常现象，通过命令行解决冲突并不复杂，只需要理解冲突的产生机制，遵循标准的解决流程，并结合合适的工具和最佳实践，就可以高效地处理冲突问题，熟练掌握冲突解决技能，不仅能提高开发效率,还能确保代码库的稳定性和一致性。
相关问答 FAQs
问题 1：如何避免 Git 冲突的发生？
解答：避免 Git 冲突的关键在于良好的协作习惯，频繁地从主分支拉取最新代码并合并到本地分支，保持分支同步，将大型任务拆分为小的提交，避免长时间脱离主分支开发，明确分支职责，减少多人同时修改同一文件的概率，在提交前确保代码通过测试,避免将有问题的代码合并到共享分支。
问题 2：解决冲突后，如何撤销错误的合并操作？
解答：如果在解决冲突后意识到合并操作是错误的，可以使用 git reset --hard HEAD（如果是 merge 操作）或 git rebase --abort（如果是 rebase 操作）来撤销合并。git reset --hard HEAD 会将当前分支重置到合并前的状态，并丢弃所有未提交的修改，而 git rebase --abort 会终止当前的 rebase 操作，并将分支恢复到 rebase 前的状态，需要注意的是，这些操作会丢失未提交的修改,因此建议在执行前确认是否需要保留这些修改。
