「content-hash」是composer.lock的強制性部分嗎？

Question

像大多數人寫作（和閱讀）有關whether to keep composer.lock in version-control的問題，我們保留在那裏。

但是，每次在不同的代碼分支中獨立更新文件時，這會導致我們遇到麻煩。即使這些更改不相關，也會影響文件各部分之間的距離，"content-hash"行每次都會導致衝突。更糟糕的是，無論「方」是否正確，誰合併都必須手動重新生成文件...

也許，該行並非真的有必要？在問之前，（作曲家的當前版本）是否會在沒有它的情況下工作，會失去什麼功能？散列似乎防範文件本身的變化 - 但源控制系統已經這樣做...

我可以簡單地刪除該行嗎？如果今天無法完成，它是否會成爲作曲家的理想特徵？

Answer 1

目的的內容哈希

的你可以在Composer\Package\Locker::getContentHash()看到，內容哈希考慮的composer.json以下字段：

$relevantKeys = array(
    'name', 
    'version', 
    'require', 
    'require-dev', 
    'conflict', 
    'replace', 
    'provide', 
    'minimum-stability', 
    'prefer-stable', 
    'repositories', 
    'extra', 
); 

的內容哈希改變的唯一原因是更改composer.json中相應屬性的其中一個值。

Composer使用內容散列來確定composer.json中的相關字段是否與composer.lock同步。您可以運行

$ composer validate 

找出它們是否同步。

如果composer.json和composer.lock不同步，會顯示一個類似的消息

是不是最新的，在composer.json的最新變化，建議鎖定文件運行composer update。

僅供參考，請參閱https://getcomposer.org/doc/03-cli.md#validate：

您應該始終運行validate命令你提交你的composer.json文件之前，你標記之前釋放。它會檢查你的composer.json是否有效。

在composer.lock

解決衝突。如果你有麻煩解決composer.lock衝突，這也許可以幫助：

1步：接受上游改變

通常情況下，你可能會試圖變基一分支在上游的變化之上。如果已經發生衝突，用你的IDE或運行

$ git checkout --theirs composer.lock 

接受到composer.lock上游的變化。由於這是一個生成的文件，你真的不想解決它中的衝突。

步驟2：重新更改應用到composer.json和composer.lock

正如前面指出的那樣，有在composer.json相關鍵的範圍。其中一些可以通過相應的命令進行修改，而另一些則不能。

例如，如果的變化之一是新添加或去除包，運行

$ composer require foo/bar:^1.2.3 

或

$ composer remove foo/bar 

應用更改。

如果變化不能通過運行的命令被應用，手動修改composer.json，然後運行

$ composer update --lock 

這將更新內容的散列。

僅供參考，請參閱https://getcomposer.org/doc/03-cli.md#update：

--lock：僅更新鎖文件哈希取消警告有關鎖定文件是過時的。