4

我的项目基于我从原始 Symfony SE 存储库克隆的 Symfony 标准版。Symfony 当然会分发它自己的文件composer.json和记录composer.lock其依赖关系的文件。

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

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

我将 Symfony 标准版存储库添加为 git 远程:

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 锁定依赖项合并到我自己项目的锁定依赖项中(包括我的部门和 Symfony 2.1.0 的部门)。手动合并这将非常繁琐!

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

我是否应该composer.lock通过在启动合并之前git checkout -- composer.lock恢复composer.lock其内容来忽略合并冲突?我想我可以为 Symfony2 SE 需要的每个依赖项运行,这些依赖项在我刚刚合并composer update的新更改中已更新。composer.json

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

4

1 回答 1

2

我想说最好/理想的情况是,如果您有一些稳定的需求(没有充满 dev-master ..),那么您只需 rm composer.lock(或 git checkout)并运行更新以确保您获得最新的依赖项一切。

如果这是不可能的,那么您也可以从上游恢复更改,composer update <specific packages>并使它们加快速度。然而,这容易出错且乏味,所以我认为最好的办法是确保您的项目中有足够严格的依赖项,以便您可以毫无顾忌地运行 composer update。

于 2012-11-17T11:20:44.307 回答