我正在解决一个git冲突。
假设我有一个文件versions.json，它已经存在于repo中：
{
"a": {
"name": "component-a",
"version": 1,
},
"b": {
"name": "component-b",
"version": 1,
},
}字符串
然后，
- 存在具有并行级的CI流水线。一个建筑物“组件-a”，第二个建筑物“组件-b”，两者都在单存储器中。
- 当“component-a”完成时，它更新文件并在“a”中设置
"version": 2 - 当“component-b”完成时，它更新文件并在“b”中设置
"version": 2。 - 各组分将
- 做些改变
- 提交更改
- 做一个
git pull --rebase - 做一个
git push
此操作失败，并出现合并冲突：
Rebasing (1/2)
Auto-merging versions.json
CONFLICT (add/add): Merge conflict in versions.json
error: could not apply 29b568d2... <previous commit message>型
组件永远不会改变同一行，所以没有真实的冲突海事组织。
我试着在提交之前添加一个pull，这在大多数情况下都能工作，但是由于monorepo很大，这需要时间，并且会导致一个组件在另一个组件的pull期间提交的竞争条件。
所以我想把它固定在最后的推或拉直接。
有没有一种方法可以在没有人类交互的情况下以自动化的方式做到这一点？
1条答案
按热度按时间jaxagkaj1#
标题是一个陷阱问题：
如何自动合并同一文件中不冲突的更改？
这是已经发生的事情，而且一旦你解决了实际问题，它就会发生，这只是你的并行管道阶段需要从文件已经存在的共享提交开始。原因是在Git中，冲突只能在“修改vs修改”场景中自动解决。如果一方或双方“添加”或“删除”文件，则不会发生自动冲突解决。
因为你是基于2个提交而不是1个，我们可以从输出中看到：
字符串
既然冲突是：
型
我们知道第一个被重定基的提交必须是文件被添加的提交，第二个提交是文件被修改的提交。第一个提交对于管道的每个阶段都不是相同的ID，这导致了“添加/添加”冲突。
修复方法是同步所有阶段，使它们从已经包含文件的相同提交ID开始，从那时起重新运行管道应该能够像您期望的那样自动解析文件，因为行更改都超过2行。