first-contributions 开源贡献实战Git 合并冲突Merge Conflict原理、标记与解决完整指南【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions本指南以 first-contributions 仓库的官方文档 docs/additional-material/git_workflow_scenarios/resolving-merge-conflicts.md 及其土耳其语译本 docs/additional-material/translations/Turkish/resolving-merge-conflicts.tr.md 为主体系统讲解 Git 合并冲突的产生原理、冲突标记的语义、手动解决流程与撤销合并方法。读完本文你将能在 fork 协作开发如向 first-contributions 提交 Contributors 修改后发起 Pull Request的典型场景中独立定位、解读并解决合并冲突。什么是合并冲突Git 何时无法自动合并当你试图将另一个分支合并到当前工作分支时本质上是把另一个上下文中发生的更改与当前工作分支的文件结合在一起。大多数情况下Git 能够基于三方合并算法自动完成合并但当满足以下任一条件时Git 就无法判定哪个版本是正确的同一文件的同一行被两个贡献者分别修改Git 不知道该保留哪一份改动一个贡献者决定删除某文件而另一个贡献者决定修改它删除与修改相互矛盾从仓库主版本文档 docs/additional-material/git_workflow_scenarios/resolving-merge-conflicts.md 可见不同分支上对同一文件同时进行重命名改名为不同名字也属于典型冲突场景。当冲突发生时Git 会暂停合并过程将冲突文件标记出来并要求你手动解决后才能继续。这正是 first-contributions 这类初学者友好项目在协作场景中最常遇到的 Git 障碍——多人同时维护Contributors.md贡献者列表时几乎必然会出现同一行被多人编辑的情况。冲突标记读懂 Git 留下的三道边界遇到合并冲突时Git 会把文件中的问题区域用 HEAD与 [其他分支名]包裹起来并在中间用一条分隔线把两份冲突的改动分开。来自原文档的示例如下 HEAD:birleştirmetesti Bu üçüncü satırım. Eklediğim dördüncü satır bu. 4e2b407f501b68f8588aa645acafffa0224b9b78:birleştirme testi其中每个标记的语义依据文档原文整理标记含义表示合并冲突行的开始。紧跟其后的第一组行来自你试图合并更改时所处的当前分支文件尖括号后的HEAD或HEAD:文件名即当前分支的引用用于比较的断点。将用户当前分支提交的更改上方与来自合并的另一分支的更改下方分隔开便于直观对比差异表示合并冲突行的结束。其后跟随的是另一方分支的名称或提交哈希与文件名第一组标记之后的内容来自你当前的工作分支而之后 Git 会明确写出改动来自哪个分支示例中的4e2b407f501b68f8588aa645acafffa0224b9b78即对方提交的 SHA-1 哈希后接文件名。理解这三个标记是解决冲突的前提冲突区域内的两份内容只有经过你的决策才能变成一份确定的结果。手动解决冲突的完整流程第一步识别冲突文件执行合并git merge、git pull或git rebase后若出现冲突先用git status查看仓库状态git status在输出中找到 Unmerged paths未合并路径一节其下列出的文件即全部存在冲突、等待处理的文件。第二步打开并审阅冲突文件用文本编辑器打开每个冲突文件找到上一节所述的//标记区域。此时你的任务是清理这些行编辑完成后文件应当呈现为你真正想要的样子。解决时需要做出的决策有三种可能来自文档明确说明保留你自己的改动当前分支版本接受对方的改动来自另一分支的版本将两者合理合并取各自有价值的部分组合成最终内容。文档特别建议与写下冲突改动的队友沟通共同决定哪个版本应当成为最终版本——最终结果可能是你们其中一方的版本也可能是两者的混合。切忌单方面删掉对方内容而不做确认这在团队协作中容易引发误解。第三步标记文件为已解决并提交完成编辑后需要删除所有冲突标记行、、然后对该文件执行git add 文件名对每个冲突文件重复上述编辑 → 删除标记 →git add的步骤。所有冲突文件暂存完成后提交合并结果git commit -m Resolved merge conflicts这一步会最终完成整个合并过程。文档还特别强调解决冲突后不要忘记运行测试。冲突解决是手工决策过程很可能引入语义错误——只有测试通过才能确认合并结果是正确的。撤销合并git merge --abort如果你在解决过程中发现改动过于复杂、或者误操作了合并希望放弃本次合并并让工作区恢复到合并前的状态可以使用git merge --abort该命令会取消当前的合并操作将分支重置到合并开始之前的状态。它适用于尚未提交的合并过程一旦合并已通过git commit完成提交就需要改用 撤销提交 或 回退提交 等其他手段。借助工具与插件加速冲突解决除了纯手工编辑仓库英文原版文档还补充了两类辅助手段可视化合并工具mergetool执行git mergetool可启动可视化合并工具辅助解决冲突git mergetool注意使用前需确保系统已安装合并工具如 Meld、KDiff3、Beyond Compare。IDE 插件正如文档所述可以根据你使用的 IDE 下载不同的冲突解决插件让合并冲突更直观、更易处理主流 IDE 与编辑器大多内置或可通过插件市场获得专门的冲突查看界面。在 first-contributions 协作场景中避免冲突的实践first-contributions 仓库的贡献流程见 README.md是典型的 fork 协作Fork 仓库 →git clone→git switch -c 新分支名→ 编辑根目录下的 Contributors.md 添加自己的名字 →git add→git commit→git push -u origin 分支名→ 发起 Pull Request。在多人并行向主仓库提交贡献时Contributors.md等高冲突概率文件的合并冲突几乎不可避免。结合英文原版文档给出的最佳实践可以显著降低冲突发生频率频繁拉取上游更新定期执行git pull origin main让本地分支跟上主仓库的最新状态缩短与上游的分叉距离使用功能分支为每个功能或修复创建独立分支而不是直接在main上工作git checkout -b feature-branch保持 fork 与主仓库同步参考仓库的 保持 fork 同步指南在发起新的 PR 前先同步上游变更理解分支的价值可进一步阅读 为什么使用分支从原理上理解隔离开发对减少冲突的意义。小结合并冲突不是错误而是 Git 在无法自动判定哪个版本正确时给予你的决策机会。掌握冲突标记、、的语义、手动编辑解决流程git add→ 运行测试 →git commit、以及git merge --abort这一撤销手段再配合git mergetool与 IDE 插件你就能在任何开源项目的协作开发中从容应对合并冲突。对本仓库而言可以结合 docs/additional-material/git_workflow_scenarios/resolving-merge-conflicts.md英文原版与各语言译本对照学习其中土耳其语译本 resolving-merge-conflicts.tr.md 与本指南主体内容一致。【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考