我的项目基于我从
original Symfony SE repository克隆的Symfony标准版.当然Symfony分发了自己的composer.json和composer.lock文件,注意到它的依赖关系.

我使用master分支进行项目开发,自从启动项目后,我将自己项目的依赖项添加到composer.json并用composer.lock锁定它们.

但现在是时候更新我的项目以使用Symfony SE 2.1.3.

我将Symfony标准版repo添加为git remote：

git remote add symfonyse git://github.com/symfony/symfony-standard.git

我可以合并symfonyse存储库2.1分支的最新更改,以获得最新的2.1开发：

git pull symfonyse 2.1

拉到那里当然是合并冲突,因为我已经修改了composer.json和我自己的依赖项,并且composer.lock以前被锁定到我的旧依赖项.

但是现在冲突的composer.lock正在尝试将最新的Symfony2 SE锁定依赖项合并到我自己项目的锁定依赖项中(包括我的deps和Symfony 2.1.0的deps).手动合并这将是非常乏味的！

在composer.lock中解决这些冲突的最佳方法是什么？

我应该通过执行git checkout – composer.lock来忽略composer.lock中的合并冲突,它会在我启动合并之前将composer.lock恢复为其内容吗？我想我可以为每个依赖项运行composer update Symfony2 SE要求已经在刚刚合并的新composer.json更改中更新了.

或者我应该接受与composer.lock合并的所有更改,提交它们,然后通过运行composer update简单地更新我的所有项目依赖项？无论如何,这将基本上生成一个全新的锁文件,包含Symfony 2.1.3的锁和我自己的依赖项.如果我还得到最新的composer.json更改,我只是不确定是否需要锁定文件的上游更新.

最佳答案 我会说最好的/理想的情况是如果你有一些稳定的要求(没有充满dev-master ..),那么你可以只使用composer.lock(或git checkout)并运行update来确保你获得最新的依赖一切.

如果那是不可能的,那么您也可以从上游恢复更改,并且作曲家更新 让他们加快速度.然而,这很容易出错,而且很乏味,所以我认为最好的办法是确保你的项目中有足够严格的依赖关系,你可以毫无顾虑地运行编辑器更新.