GIT 中的 Composer & composer.lock 和合並沖突

Question

這是我們的情況：

我們有 3 個不同的 Laravel 項目，所有 3 個項目都依賴於我們的 Core 項目。 這個 Core 項目是一個單獨的 Laravel 包，托管在我們的私有倉庫中，用作其他項目的依賴項。

以前，每當 Core 項目發生變化時，我們只需在我們的服務器上運行一個 composer update ourvendor/ourcorepackage 來為每個項目引入核心更改。 然而，最近 Composer 似乎遇到了嚴重的內存問題，當我們嘗試使用 512 MB Ram 在我們的 Digital Ocean 登台環境上運行更新時。 見： https : //github.com/composer/composer/issues/1898

我經常遇到的解決方案是人們說您應該始終在生產服務器上運行 composer install。 我可以在安全性方面與此相關，因為如果您更新到可能會破壞您的代碼的某些 3rd 方軟件包的新版本，這可能會很危險。 但是在我們的例子中，我們只更新我們自己的核心包，所以我們知道我們在做什么，但是這個內存問題迫使我們使用 composer install 方法，因為它對內存的要求較低。

所以基本上這是我們當前的工作流程：

1. 當我們的核心包發生變化時，我們需要在每個項目本地運行 composer update ourvendor/ourpackage 這會生成一個 composer.lock 文件

2. 我們在我們的 repo 中提交 composer.lock 文件

3. 在每個項目的服務器上，我們運行 git pull 並運行 composer install。 這只會更新我們的核心包並且運行得更快，並且與 composer update 相比沒有內存問題

然而，這個解決方案提出了兩個問題：

1. 由於我們在同一個項目上與多個開發人員合作，因此在本地拉入更改時，有時最終會出現 composer.lock 文件的合並沖突。
2. 在服務器上運行 git pull 會出現錯誤：您對以下文件的本地更改將被合並覆蓋：composer.lock 請在合並之前提交您的更改或隱藏它們。

那我應該在這里做什么？ 在拉取服務器之前刪除 composer.lock 文件？ 我們應該如何處理 composer.lock 文件的合並沖突？

遺憾的是 composer update 遭受內存問題，因為這種方法似乎更合乎邏輯。 只需更新您想要的包，而無需使用 composer.lock 文件。

請建議如何在我們的案例中使用 GIT 和 Composer 的正確工作流程以及如何解決上述沖突？

非常感謝您的意見

Answer 1

如果開發人員不自己執行此步驟，您如何測試核心更新（或任何其他更新的依賴項）不會破壞使用它的項目中的內容？

這就是為什么通常的工作流程期望composer update在具有足夠 RAM（即可能超過 1GB 設置為 PHP 的內存限制）的開發機器上運行，並且更新應由開發人員手動觸發（如果自動觸發）持續集成構建，內存要求也適用於這台機器）。

沒有辦法解決這個內存需求。 僅安裝 512 MB RAM 的 Web 服務器可能能夠在幾乎沒有任何並發​​用戶的情況下用作臨時服務器，但它不應用於更新 Composer 依賴項。

我個人使用一個非常簡單的系統修復composer.lock的合並沖突：刪除鎖定文件並運行composer update 。 這會將所有依賴項更新到滿足版本要求的最新版本，並創建一個新的工作composer.lock文件，該文件在合並期間提交。

我不害怕潛在地更新所有內容，因為要么按預期工作，要么我的測試會很快發現錯誤。

我確實選擇了我謹慎使用的第 3 方軟件包：

• 他們必須標記他們的版本，最好使用語義版本控制。
• 我不為發布版本使用任何分支（很少有人在開發過程中使用它們是痛苦的）
• 如果他們進行向后不兼容的更改，他們應該發布一個新的主要版本
• 本地開發的包也遵循這些要求

這適用於我們本地 Satis 實例提供的大約 270 個包（可能也是嘗試減少內存占用時要考慮的一個因素 - 只有 Composer 已知的包才能最終留在內存中：比較 packagist.org 上可能可用的一萬個包與270 個本地包）。 270個中的60個包由20個開發者本地開發，隨機發布新版本。 過去 2 年的更新失敗非常罕見，應該像其他錯誤一樣處理：如果檢測到標記版本不兼容，我們會發布一個錯誤修復版本來恢復更改，並使用新的主要版本標記原始更改，如果不兼容的更改是必要的。

所以你要求的工作流程大概是這樣的：

• 任何時候，任何開發人員都應該能夠在他們的本地機器上運行composer update 。
• 他們應該能夠檢測到這是否會破壞他們本地機器上的東西。
• 如果沒有任何問題，他們會將包括composer.lock文件在內的更改提交到 Git
• 臨時服務器僅運行composer install並將使用開發人員在其機器上使用的版本。
• 如果暫存時沒有任何問題，則該版本已准備好用於生產。

在另一台開發人員機器上合並已經提交的版本可能會顯示與composer.lock合並沖突。

• 解決所有其他文件上的沖突。
• 應該刪除composer.lock文件。
• 從這里開始，工作流程如上，即：
• 開發人員應該能夠在他的本地機器上運行composer update 。
• 他們應該能夠檢測到這是否會破壞他本地機器上的東西。
• 如果沒有損壞……等等。

Answer 2

另一種方法（不做composer update ）：

1. 將您的新（和已刪除）行從composer.json復制到單獨的文本文件中。
2. 使用整個遠程composer.json和composer.lock文件。
3. 在合並沖突模式期間，請執行以下操作：
   • composer install
   • 對於您在步驟 1 中記下的每個新包，運行composer require vendor/package:version
   • 對於您在步驟 1 中記下的每個已刪除的包，運行composer remove vendor/package
4. 測試！，提交，完成！

此方法將保持來自遠程分支（可能是master或develop分支）的鎖，並且僅更新您的新包。

Answer 3

有時composer update可能會破壞事情。 我所做的是。

1. 放棄我對composer.lock所有更改
2. 合並composer.json
3. 運行composer install ，這樣得到的包根據安裝composer.lock 。
4. 如果您添加了該軟件包，則使用其中一個軟件包並運行composer require vendor/package package 或composer remove vendor/package如果您刪除它。 如果有多個包，它將從composer.json自動安裝