看起来这是一次非常大的改动，然而问题也不少。。。
刚才在项目中做了一次提交，Xinguanjia.xcodeproj/project.pbxproj文件存在冲突。
修正冲突以后，git插件自动做了Merge remote-tracking branch 'origin/master'提交。
从提交的结果看，冲突的地方在这次自动提交的地方已经按照我选择的来源进行了覆盖。
然而另外一个自动合并的地方出了问题。
左侧是当前工作空间的变更，右侧是处理冲突后的commit内容。
问题1：
按道理说，在处理冲突并合并然后自动提交以后，没有做任何修改的情况下，工作空间应该是干净的。
然而出现了成片的差异，而其区别是，左边的行缩进是空格，右边的行缩进变成了tab(合并之前的两个分支上都是tab)。
也就是说合并完成后，Xcode把这个合并成功的文件的行首缩进在工作空间里从tab改成了空格。
问题2：
572行那个区块，左边的工作空间里改动的部分其实应该是自动合并的。也就是说解决冲突的那次自动合并，Xcode本来已经认为这部分是可以自动合并的，而且应该保留左边的那些内容，但这个合并选择并没有加入到自动合并和解决冲突的那次提交里（右边那部分的commit）。
但更诡异的是，这个变更在工作空间里被保留了下来。
正常情况下，提交会把工作空间里所有stage的内容快照作为commit的状态。这样的话工作区应该是干净的。
而提交以后什么都没做的情况下出现了uncommit的变更内容，只能认为要么是Xcode插件自己做了修改（类似问题1里的内容，但这次不是乱改，而是做了记录）。
然而并不是合并的时候所有自动合并的内容都这样了，只有这一个部分，而这个部分的特征是在两个来源分支上都做了修改，一个分支删掉了2行，另一个分支添加了8行。
也就是说Xcode虽然在IDE的合并窗口那里做出了选择，把能自动合并的不认为是冲突，但实际操作的时候还是保守的把两者中增量的那个分支的部分做了一个类似stash的暂存操作，然后提交了减量的那个分支的内容(虽然自动合并选择的是增量分支)。提交结束后又把暂存的增量部分用类似unstash的操作恢复到工作空间了。如此推测的理由是，如果没有stash，那不管合并选择的是哪个分支，工作空间都会与这个分支的内容一致，而不会出现提交内容和工作空间内容不一致的情况。
这个问题也许是bug，又或者是Xcode的git插件刻意为之。将本来可以自动合并的地方又做了更严谨的判断(要做出这个逻辑的正确判断的话，必须每一个在两个分支里不同的地方，都往前看到分支第一次分叉时候的那个节点的文件内容，相当于是三个来源对比，因为仅仅判断合并前两个分支的内容是无法判断的，因为在这种情况下，这两个文件对比其实是纯增量，会默认选择内容多的分支提交）。
然后Xcode将同时在两个分支上分别出现增量和减量的代码片段标识，提交少的部分，而把多的部分通过stash/unstash的方式保留到工作区，让开发者自己再做一遍决定是否应该提交这些内容。
如果真是这样的话，那Xcode的git插件比FileMerge这种只看两个文件情况对比的工具还真是又先进了不少。。。
