Git冲突分析和处理


本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://oldratlee.com/post/2013-02-17/git-conflict

一同事使用git pull冲突了,并且之前本地有未提交的修改。

问题变得比较复杂,因为涉及4方面:

  • 工作目录的修改
  • 暂存区的修改
  • merge来的修改
  • Merge前的修改

解决方法:

使用git merge --abort中止merge。merge manual中说,这条命令会尽力恢复到Merge之前的状态(可能失败!)。

merge manual中有一条警告:

Warning: Running git merge with uncommitted changes is discouraged: while possible, it leaves you in a state that is hard to back out of in the case of a conflict.

上面的内容就是说:有未提交修改情况下,不要执行merge!遵守这条警告,防患于未然是最好。

遵守这条警告(或说是最佳实践)后,就只有两方面:

  • merge来的修改
  • Merge前的修改

关于这种情况下的冲突解决,《Git权限指南》一书中有比较系统的说明。

这条警告说得更通用些,就是

有未提交修改情况下,不要执行可能会冲突的操作!

哪些操作会导致冲突呢?

冲突的来源

很多命令都可能出现冲突。但冲突的直接来源是mergepatch(应用补丁)。其它的命令是执行这两个操作导致冲突。

  • rebase:重新设置基准,然后应用补丁。
  • pull:会自动merge
  • repo sync:会自动rebase
  • cherry-pick:会应用补丁
  • ……

最佳实践

在执行可能有冲突的操作前,先查看一下 暂存区 和 工作目录,保证其中没有修改。

比如使用git stash就可以把暂存区 和 工作目录的修改保存起来,让暂存区 和 工作目录处于干净的状态。

遗留的的问题

如果上面最佳实践是合理的,那么应该加上Hook,在执行在执行可能有冲突的操作时,检查是否有没提交的修改。如果有,则给出警告终止操作!

参考资料

  • Git下的冲突解决
    这篇博文给出了“冲突来源”的说明,并简单说了冲突的处理。
  • 我的一条讨论Git冲突的微博 http://weibo.com/1836334682/zgQ3y5AzK

所属标签: git, 冲突, merge, rebase, 合并, patch, 补丁,

你可能感兴趣的:(Git冲突分析和处理)