23

私は特定のプロジェクトで一人のプログラマーでしたが、今では他の誰かが共同作業者として参加しています。写真に写っているのは私だけで、更新はスムーズで、 Gitによって追跡されることをbundler2度考えたことはありません。Gemfile.lock

新しい共同作業者はbundle install、リポジトリのクローンを作成した後に実行Gemfile.lockされ、次のように更新されました。

Gemfile.lock

@@ -141,7 +141,7 @@ GEM
       rack-ssl (~> 1.3.2)
       rake (>= 0.8.7)
       rdoc (~> 3.4)
-      thor (< 2.0, >= 0.14.6)
+      thor (>= 0.14.6, < 2.0)
     raindrops (0.10.0)
     rake (0.9.2.2)
     rdoc (3.12)
@@ -164,7 +164,7 @@ GEM
     sprockets (2.1.3)
       hike (~> 1.2)
       rack (~> 1.0)
-      tilt (!= 1.3.0, ~> 1.1)
+      tilt (~> 1.1, != 1.3.0)
     thor (0.16.0)
     tilt (1.3.3)
     treetop (1.4.10)
@@ -175,7 +175,7 @@ GEM
     tzinfo (0.3.33)
     uglifier (1.3.0)
       execjs (>= 0.3.0)
-      multi_json (>= 1.0.2, ~> 1.0)
+      multi_json (~> 1.0, >= 1.0.2)
     unicorn (4.3.1)
       kgio (~> 2.6)
       rack

この変更は、マスターから離れた名前付きブランチにプッシュされました。この変更にどのように対処する必要がありますか？

大声で考える：GitHubでプルリクエストをマージしますか？最初はプルリクエストなしでアップストリームからプルするだけですか？特定のbundlerコマンドを実行して、他の共同編集者と同期しGemfile.lockますか？他のコラボレーターが別の方法で実行して、gemを更新しないようにする（既存のgemをダウンロードするだけの場合Gemfile.lock）ことができるでしょうか。この状況に関するベストプラクティスは何ですか？

4

1 に答える 1

41

Gemfile.lock should be version controlled. You should be committing any changes to it. When somebody (who you trust) updates it, you should run bundle install to install the gems currently locked in Gemfile.lock.

Just running bundle install will not update an existing Gemfile.lock. To do so, you need to run bundle update.

All that said, there are no actual changes to the versions in your Gemfile.lock. All that changed was the order of arguments for a few lines. You can safely merge those changes in or disregard them; the resulting Gemfile.lock will be (functionally) identical.

于 2013-01-23T01:53:00.227 に答える