这是场景:
用户 A 和 B 具有相同的源代码。用户 A 进行更改 => 添加 => 提交 => 推送。远程存储库中的源代码已更改。
用户 B 无需拉动即可开始更改。(或者可能在用户 B 拉取存储库后应用远程存储库中的更改)然后他也想推送。就在这个时候,冲突发生了。我搜索了很多,找不到任何解决方案,只能手动编辑冲突。
问题:手动编辑冲突是一种有效的方法吗?特别是在一个大项目中?方法是什么?
这是场景:
用户 A 和 B 具有相同的源代码。用户 A 进行更改 => 添加 => 提交 => 推送。远程存储库中的源代码已更改。
用户 B 无需拉动即可开始更改。(或者可能在用户 B 拉取存储库后应用远程存储库中的更改)然后他也想推送。就在这个时候,冲突发生了。我搜索了很多,找不到任何解决方案,只能手动编辑冲突。
问题:手动编辑冲突是一种有效的方法吗?特别是在一个大项目中?方法是什么?
手动管理合并冲突可能是一项繁琐的任务。
尝试git mergetool
它会打开默认的合并工具,尽管您必须先安装合并工具。有几种合并工具可以帮助您解决冲突,例如meld
, opendiff
, kdiff3
, tkdiff
, xxdiff
, tortoisemerge
, gvimdiff
, diffuse
, ecmerge
, p4merge
, araxis
, vimdiff
, emerge
.
安装后执行它,它会打开已安装的合并工具,它会为您提供一个引导您完成每个冲突的gui,您可以选择如何合并。
如果您使用IntelliJ之类的 IDE,它们会提供内置工具来修复合并冲突。
手动解决冲突是要走的路。冲突意味着开发人员 B 依赖于某些已更改的代码。这意味着他必须使他的代码适应开发人员 A 所做的更改。也就是说 - 解决这个冲突。
有时这种冲突可以自动解决。有时可以通过简单地选择“我们的在他们的之后”之类的选项来解决。然而,即使在 git 的意义上没有冲突,代码仍有可能需要更正。
例如:有一个函数some_func
接受一些参数。开发人员 A 将其重命名为some_new_name
,而开发人员 B 将调用添加到some_func
某个完全独立的代码区域。合并将不会发生任何冲突,但代码将无法正常工作。
实际上,发生冲突可能比没有冲突要好——您会收到早期警告,即您编写的代码必须更改。