我的项目基于我从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中解决这些冲突的最佳方法是什么？
我应该通过composer.lock忽略git checkout -- composer.lock中的合并冲突，composer.lock在我启动合并之前将composer update还原为其内容吗？我想我可以为每个依赖项运行composer.json Symfony2 SE要求已经在刚刚合并的新composer.lock更改中更新。
或者我应该接受与composer update合并的所有更改，提交它们，然后通过运行composer.json简单地更新我的所有项目依赖项？无论如何，这将基本上生成一个全新的锁文件，包含Symfony 2.1.3的锁和我自己的依赖项。如果我还得到最新的{{1}}更改，我只是不确定是否需要锁定文件的上游更新。
答案 0 :(得分：2)
我想说最好/理想的情况是如果你有一些稳定的要求（没有装满dev-master ..），那么你可以直接使用composer.lock（或git checkout）并运行更新以确保你得到一切的最新依赖。
如果无法做到这一点，那么您也可以从上游恢复更改，composer update <specific packages>使其更快。然而，这很容易出错并且很乏味，所以我认为最好的办法是确保你的项目中有足够严格的依赖关系，以便你可以毫不畏惧地运行作曲家更新。