TL;DR
新たなマシンにバージョンを固定してプロジェクトを入れるにはcomposer.lockを共有して composer install をするのがよいです。
本文
composer install は composer.lock を composer.json よりも優先して扱います。 composer.lock を参照した composer intall を行った場合、vendor以下全て（composer.jsonで指定していない依存の依存パッケージなども）を composer.lock に記述してあるパッケージ群に置き換えます。
要するに、動くことが担保されているバージョンセットのパッケージが欲しいのであれば動くことが担保されているバージョンセットのcomposer.lockを元にcomposer installするべき、ということです。composer.jsonは人間の頭で把握できるパッケージ管理の根元として大変便利ですが、実際にパッケージ間のネストした依存を管理しているのはcomposer.lockであり、composer.lockの共有をしなければ異なるマシン間で完璧なバージョン共有をすることはとても手間です。
時々conflictが厄介だからかcomposer.lockがgitに上がっていない時がありますこれは本番環境で動くと確信できるバージョンのパッケージ群をインストールし難いということでもあり、デプロイが面倒になります（composer.lockない場合、パッケージのコードもFTPでアップロードするやり方が安全安心な気がします）。gitでcomposer.lockが大量に書き換わったのであれば、書き換え後のバージョン構成で想定した通りの動作を行えるかテストするべきであり、危険なことが起きていると認識する必要があります。
本家Composerのドキュメントにも次の様にあります。
Commit your
composer.lockfile to version control#Committing this file to VC is important because it will cause anyone who sets up the project to use the exact same versions of the dependencies that you are using. Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then. (See note below about using the
updatecommand.)バージョン管理にあなたの
composer.lockをコミットしてください#composer.lock をVCにコミットすることは重要です。これはプロジェクトをセットアップするすべての人が、あなたが使用している依存関係とまったく同じバージョンを使用できると期待するからです。そうすることによって、CIサーバー、プロダクションマシン、チーム内の他の開発者、全ての環境が同じ依存関係で実行されます。これにより、一部の環境にのみ発現する潜在的バグが軽減されます。 composer.lock をコミットしたならば単独で開発した場合でも、プロジェクトを再インストールする6か後、依存関係がそれ以降多くの新しいバージョンをリリースした場合でも、インストールされた依存関係が正常に機能すると確信できます。
ここまでcomposer.lockはプロジェクトを扱うマシン全てで共有すべきでありgit管理に含むべきという言説で記事を書いてきましたが、逆に composer.lock をgitで管理すべきでない場合もあります。それはvendor以下に配置される前提であるフレームワーク、パッケージ、といった広い範囲のバージョンのパッケージを対象に動作すべきパッケージプログラムのプロジェクトの場合です。こういった際にcomposer.lockが含まれていると本来対応できる範囲のバージョンより狭いバージョンに依存している扱いになってしまいます。
余談ですがたまに.gitignoreにcomposer.lockが含まれているボイラープレート（composer create-project ${プロジェクト名} できたりするモノ）があります。ボイラープレートはボイラープレートのコードを改造してアプリケーションを作る目的のコードです。当然.gitignoreの誤りに気付かない場合、composer.lockはgitに管理されません。そうなると、個人間で異なる環境が出来上がり異なるバグが生まれやすい、デプロイのバージョン管理が不安になる、と危険な要素が増えます。正直シャレにならない罠です。
