15

Я был одиноким программистом по конкретному проекту, но теперь кто-то присоединился к нему в качестве соавтора. С только мной на картинке, bundler обновления были гладкими, и я никогда не думал дважды о Gemfile.lock отслеженном Git.Как бороться с обновлениями пакетов (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 

Это изменение затолкали в имени ответвляются мастера. Как я должен заниматься этим изменением?

Мышление вслух: Я могу объединить запрос Pull на GitHub? Я просто вытаскиваю вверх по течению без запроса Pull сначала? Я запускаю определенную команду диспетчера, чтобы синхронизировать ситуацию с Gemfile.lock другого соавтора? Есть ли что-то, что другой соавтор мог бы сделать по-другому, чтобы они не вызывали каких-либо драгоценных камней для обновления (скорее, просто для загрузки драгоценных камней, указанных в существующих Gemfile.lock)? Каковы наилучшие практики в этой ситуации?

ответ

29

Gemfile.lock следует be версия контролируемый. Вы должны вносить в него какие-либо изменения. Когда кто-то (кому вы доверяете) обновляет его, вы должны запустить bundle install, чтобы установить драгоценные камни, которые в настоящий момент заблокированы в Gemfile.lock.

Только что запущен bundle install не будет обновлять существующий файл Gemfile.lock. Для этого вам необходимо запустить bundle update.

Все, что сказано, никаких фактических изменений в версиях в вашем Gemfile.lock нет. Все, что изменилось, это порядок аргументов для нескольких строк. Вы можете смело объединить эти изменения или игнорировать их; полученный Gemfile.lock будет (функционально) идентичным.

+2

Наличие вашей Gemfile.lock под управлением версии считается лучшей практикой. Это гарантирует, что один и тот же набор зависимостей будет построен везде, где вы устанавливаете приложение, будь то другой разработчик, работающий над исходным кодом, или комплект для вашего производственного сервера. – ianpetzer

+0

убедитесь, что вы используете одну и ту же версию поставщика, чтобы сгенерированный Gemfile.lock выглядел одинаково, а не генерировал вещи по-другому, что было бы ложным сигналом – hammady