composer下載的內容是否需要提交到git

想問一下各位使用Composer的同學，通過Composer下載後的檔案你們會把內容提交到Git上嗎？
在官方的Faq上看到Should I Commit the dependencies in my vendor directory這篇文章，有建議是不提交到Git，那麼應該如何處理切換分支就要重新 composer install這個問題呢？如果將vendor提交到版本庫，那又應該如何處理包裡面帶有的.git檔案夾呢？

*修正 composer update 應該為 composer install

回複內容：

想問一下各位使用Composer的同學，通過Composer下載後的檔案你們會把內容提交到Git上嗎？
在官方的Faq上看到Should I Commit the dependencies in my vendor directory這篇文章，有建議是不提交到Git，那麼應該如何處理切換分支就要重新composer install這個問題呢？如果將vendor提交到版本庫，那又應該如何處理包裡面帶有的.git檔案夾呢？

*修正 composer update 應該為 composer install

事實上無論是分支開發，還是部署到生產環境，無論composer.json中版本號碼的萬用字元規則你怎麼寫，我們最關心的永遠是一個最根本內容：開發當時，我們用的所有依賴庫，具體的版本號碼是哪一個？

而這個內容是composer.lock檔案支援的。composer 本身通過維護 lock 檔案，記錄了依賴庫產生任何改動之後，項目中所有依賴庫的具體版本。請閱讀關於此檔案的文檔。

你應當永遠把composer.lock檔案提交到版本庫，並在切換分支或部署之後，使用composer install安裝 lock 檔案中指定的具體依賴版本。

從這個意義上講，你是否將vendor目錄提交到主要版本庫都是對的。提交與否這是一個互有取捨的選擇：

如果提交：

1. 優勢：“拉取即用”的便利。

2. 劣勢：資訊重複。因為你開發當時的具體版本，lock 檔案已經記錄。也就是說vendor檔案夾表述了同一件事情。

3. 劣勢：引入不一致性的風險。因為雖然 Composer 保證 lock 檔案和vendor目錄一致，但提交到 git 版本庫畢竟是一個人工行為。你難以保證哪一次不會落下二者之一。

如果不提交，優劣勢反過來。不再重複。

我的想法是：我建議你堅持“正確性優於易用性”的思想。我的建議是不提交vendor，僅僅使用 lock 檔案維持開發當時的依賴庫版本。

如果提交的話，請務必遵循以下兩個準則：

（1）務必保證vendor和composer.lock這兩個檔案的提交是同步的。提了一個，必須提另一個。
任何開發，如果任何一次 commit 只交了其中一個，必須追責。
這個的理由是：雖然我們提交vendor保證拉取下來立刻可用，但是 git 是有部分檢出（checkout）功能的 —— 對於一個 Composer 項目，我有權遵照 Composer 項目的慣例，不檢出vendor目錄，而是拉取下來實務代碼之後隨手一個composer install，你不能說我錯。
（如果誰說這個是錯的，我支援你分分鐘上sf和知乎曝光你的無良公司和技術主管）

（2）務必按照Composer對於提交vendor檔案夾的建議，忽略掉子庫的所有.git目錄，只提交vendor中的實務代碼。
相信我，vendor中的實質代碼，和vendor/**/.git下git庫本身的管理用檔案，絕對是冰山的水上部分和水下部分的關係。不忽略，會死人的，不誇張。

另外必須指出的是：分支開發時，就算不通過版本庫同步vendor，而只同步composer.lock，也不會造成時間的浪費。

兩個分支切換時，無非是兩套具體版本換來換去。而 Composer 本身對所有下載的庫都是緩衝的。每次拉分支之後的composer install必然命中全部的緩衝，而不需要重複消耗下載的時間。

這個可以參考GitHub上的Laravel項目，https://github.com/laravel/laravel。

.gitignore檔案：https://github.com/laravel/laravel/blob/master/.gitignore

也是很明顯的不提交vendor檔案夾。

首先如果你重來沒有提交過 vendor 目錄，切換分支也不需要 update，
其次正常情況下 vendor 下面的包是不帶 .git 檔案夾的。

至於需不需要提交 vendor 到git，這得看情況。
如果你是發布一個公開項目到 github，顯然不需要提交，寫好 composer.json 就可以了。
如果是私人項目，這看你是如何發布的。如果是打包，然後解壓到伺服器，可能需要提交，如果有更自動化的流程，比如自動更新，自動update，那你也可以不提交。

看你希望怎麼管理項目，這方面沒有定論，不過一個建議是應該把第三方庫的版本依賴寫確切，不要寫通配，正常情況下也不要用composer update，第三方庫又沒問題為什麼要update？除非你確實遇到第三方庫目前的版本有bug需要升級，或者你的新功能要依賴第三方庫新版本的特性，不然你莫名其妙update幹嘛？

一個準則，在開發任何新特性之前，第三方庫的版本依賴就應該是確定的，這方面不能有含糊的地方，不然你這專案管理就是有問題了。

既然第三方庫的版本確定，那麼推不推vendor就是另外的問題了，如果你懶得部署時再install，那麼大可以直接就推去遠程把第三方庫當成項目的一部分，這也是比較推薦的做法，因為打包捆綁的好處就是分發方便，這方面我是支援不忽略vendor的，當然更大的原因是天朝的網路……實在沒法每次都重複等，媽蛋等啊等再好的擼碼好心情也要等壞啊……

