Я был одиноким программистом по конкретному проекту, но теперь кто-то присоединился к нему в качестве соавтора. С только мной на картинке, 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
)? Каковы наилучшие практики в этой ситуации?
Наличие вашей Gemfile.lock под управлением версии считается лучшей практикой. Это гарантирует, что один и тот же набор зависимостей будет построен везде, где вы устанавливаете приложение, будь то другой разработчик, работающий над исходным кодом, или комплект для вашего производственного сервера. – ianpetzer
убедитесь, что вы используете одну и ту же версию поставщика, чтобы сгенерированный Gemfile.lock выглядел одинаково, а не генерировал вещи по-другому, что было бы ложным сигналом – hammady