Git是最流行的代码版本控制系统，这一系列文章介绍了一些Git的高阶使用方式，从而帮助我们可以更好的利用Git的能力。本系列一共8篇文章，这是第4篇。原文：MergeConflicts:WhatTheyAreandHowtoDealwithThem[1]
合并冲突……没有人会喜欢，有些人甚至害怕冲突。但是使用Git时，特别是需要与其他开发人员合作时，冲突是不可避免的。大多数情况下，合并冲突并不像想象的那么可怕。在“Git进阶”系列的第四部分中，我们将讨论冲突何时会发生，实际是什么，以及如何解决。
Git进阶系列:
创建完美的提交Git中的分支策略基于PullRequest实现更好的协作合并冲突（本文）RebasevsMerge交互式RebaseGit中的Cherry-pick提交用Reflog恢复丢失的提交何时以及为什么会发生合并冲突从名称就可以看出来:将来自不同来源的更改集成(或“合并”)到当前工作分支时，就可能会发生合并冲突。请记住，集成并不局限于合并分支。冲突也可能发生在rebase或交互式rebase过程中、在cherry-pick(从一个分支选择某个提交应用到另一个分支)过程中、在执行gitpull时，甚至在重新加载暂存区的内容时。
所有这些操作都执行某种类型的集成，这就是合并冲突可能发生的时候。当然，并不意味着这些操作每次都会导致合并冲突，那么到底什么时候会发生冲突呢？
实际上，Git的合并功能是其最大的优势之一:分支合并在大多数时候都能完美工作，Git通常能自己解决问题，知道如何集成变更。
但也有发生了相互矛盾的变化的情况，那时候技术根本无法决定什么是对的，什么是错的，这时就需要人类做出决定。例如，当同一行代码在两个不同分支的两次提交中被更改时，Git无法知道哪一次更改才是对的。另一种不太常见的情况是，一个文件在一个分支中被修改，而在另一个分支中被删除了。Git会问你该做什么，而不是猜测该怎么做。
怎样才能知道何时发生了合并冲突那么，如何才能知道发生了合并冲突？不用担心，如果合并或rebase失败，Git会立即告诉我们，也会对如何解决这个问题提出建议。例如，如果提交的更改与其他人的更改发生了冲突，Git会在终端通知我们，并告诉我们自动合并失败了:
gitmergedevelopCONFLICT(content):Mergeconflictinindex.htmlAutomaticmergefailed;fixconflictsandthen
转载请注明：http://www.0431gb208.com/sjsbszl/881.html
