>[info] git merge 功能：合并分支。 现在，我们把`dev`分支的工作成果合并到`master`分支上： ~~~ $ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+) ~~~ `git merge`命令用于合并指定分支到当前分支。 ### 想合并，就要先把自己的工作能完成。 ~~~ Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master) $ git merge dev error: Your local changes to the following files would be overwritten by merge: test Please commit your changes or stash them before you merge. Aborting ~~~ 如果当前分支有工作未完成（工作区不是干净的：有未添加到暂存区的修改或者暂存区有内容），那么就会报错： ~~~ 　　错误:您的本地更改以下文件将会被合并覆盖: 　　测试 　　请提交您的更改或隐藏他们之前合并。 　　流产 ~~~ 这也能解答我们另一个疑问： >[info] 疑问：“工作目录会切换成解决冲突的模式。”什么意思，如果此时工作区还有工作（有未提交到暂存区的修改和暂存区内容）怎么办？丢失吗？ > 答：不先完成工作，你压根就不能进行合并操作哈。 * * * * * ### 如果两个分支都对同一个文件进行了修改： ~~~ Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master) $ git merge dev Auto-merging test CONFLICT (content): Merge conflict in test Automatic merge failed; fix conflicts and then commit the result. ~~~ 那么就会报错： ~~~ 　　编码测试 　　在测试冲突(内容):合并冲突 　　自动合并失败;解决冲突,然后提交结果。 ~~~ 此时看一下状态： ~~~ Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master|MERGING) $ git status On branch master Your branch is ahead of 'origin/master' by 7 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: test no changes added to commit (use "git add" and/or "git commit -a") ~~~ 打开冲突的文件看看（工作区进入解决冲突模式）： ~~~ Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master|MERGING) $ cat test 1 2 xa sd <<<<<<< HEAD master master2 master3 ======= up test 1 up test 2 >>>>>>> dev ~~~ 我们发现： ~~~ …… <<<<<<< HEAD master master2 master3 ======= up test 1 up test 2 >>>>>>> dev …… ~~~ <<<<<<< HEAD 内容 >>>>>>> dev 包裹的就是冲突的部分，=======用于分割两部分上面HEAD表示当前分支，下面一部分表示dev部分的内容。（细心的你应该发现了命令提示符后面的`(master|MERGING)`了吧） 根据提示我们手动编辑文件解决冲突后在提交（`git add`，`git commit`）就可以完成合并了。 我们先试一下不`git add`，直接`git commit`看有什么效果： ~~~ Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master|MERGING) $ git commit -m 'master merge dev' U test error: Committing is not possible because you have unmerged files. hint: Fix them up in the work tree, and then use 'git add/rm <file>' hint: as appropriate to mark resolution and make a commit. fatal: Exiting because of an unresolved conflict. ~~~ 好吧，被发现了： ~~~ 　　错误:承诺是不可能的因为你有unmerged文件。 　　提示:解决他们在工作树中,然后使用“git添加/ rm <文件>” 　　提示:适当的分辨率和做出承诺。 　　致命:退出,因为一个未解决的冲突。 ~~~ 我们猜想是不是这段冲突代码还有什么作用，能监视到我们并没有做更改操作吗？ok，不管冲突，`git add`再直接提交，试一下猜想： ~~~ Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master|MERGING) $ git add test Administrator@USER-20160512VQ MINGW64 ~/desktop/github-note (master|MERGING) $ git commit -m 'master merge dev' [master cb8e75d] master merge dev ~~~ 哈哈，我并没有进行任何编辑呢，看来git并没有监视我们是否解决冲突了，它只是将冲突给我们看下，让我们自己决定，那么冲突代码并没有其他作用，只是方便我们对照解决冲突部分。（不过它也不能“监视”呢，不然要是我们代码就是有这个用于标记冲突部分的关键字呢是吧） ### 来讨论一个问题：合并时，什么情况会产生冲突？（B为A的分支，将B合并到A） 1. A，B两个分支都同一个文件进行了修改 2. A，B修改了各自的文件，但不是你同一个文件 3. A修改了文件，B没有任何修改 4. B修改了文件，A没有任何修改 5. A新增了新的文件，B没有新增文件 6. B新增了新的文件，A没有新增文件 7. A，B都新增了文件，各自新增的文件名不同 8. A，B都新增了文件，各自新增的文件名有相同的 9. A删除了某文件，B没有删除文件 10. B删除了某文件，A没有删除文件 11. A，B都删除了某文件，各自删除的文件名不同 12. A，B都删除了某文件，各自删除的文件名有相同的 ……？？？ 到底什么时候冲突，什么时候不冲突，每种情况下是怎么解决冲突的。 1. 冲突：对冲突文件进行手动编辑解决（git将文件差异对比放在冲突文件中了），然后在提交，工作目录会切换成解决冲突的模式。 疑问：“工作目录会切换成解决冲突的模式。”什么意思，如果此时工作区还有工作（有未提交到暂存区的修改和暂存区内容）怎么办？丢失吗？ 2. 不知道 3. 不知道 4. 不知道 5. 不知道 6. 不知道 7. 不知道 8. 不知道 9. 不知道 10. 不知道 11. 不知道 12. 不知道 合并竟然把工作区（工作目录，未添加到暂存区的修改，暂存区）也合并过来了。 切换分支，并不会改变工作区哦，看来工作区不是属于分支的哦。（这可能就解释了上面那句荒诞的问题了） 不带参数时什么效果 ---- ~~~ 什么时候会有修改冲突？ A的f上一个版本，等于B的f当前版本，或者B的f上一个版本，等于A的f当前版本，此时没有冲突，新版f直接覆盖旧版。 除此之外，都需要解决冲突 而git能基于行的版本跟踪！ ~~~