Должен ли Gemfile.lock быть включен в .gitignore?


501

Я вроде новичок в упаковщике и файлах, которые он генерирует. У меня есть копия git-репозитория от GitHub, в которую многие люди вносят свой вклад, поэтому я с удивлением обнаружил, что упаковщик создал файл, которого не было в репо и которого нет в .gitignoreсписке.

Поскольку я его разветвил, я знаю, что добавление его в репо ничего не нарушит для основного репо, но если я сделаю запрос на извлечение, это вызовет проблему?

Должны ли Gemfile.lockбыть включены в хранилище?



2
Если вы нашли свой путь здесь, потому что у вас Linux и Windows боксы в одном репо, см. Ответ Джо Янга. На момент написания этой статьи она занимала третье место. Также см. Stackoverflow.com/questions/14034561/…
Питер Берг

Ответы:


549

Предполагая, что вы не пишете rubygem, Gemfile.lock должен быть в вашем хранилище. Он используется в качестве снимка всех ваших драгоценных камней и их зависимостей. Таким образом, упаковщик не должен пересчитывать все зависимости гемов при каждом развертывании и т. Д.

Из комментария cowboycoded ниже:

Если вы работаете с гемом, НЕ проверяйте ваш Gemfile.lock. Если вы работаете над приложением Rails, тогда проверьте свой Gemfile.lock.

Вот хорошая статья, объясняющая, что такое файл блокировки.


88
Зависит от того, над чем вы работаете. Если вы работаете с гемом, НЕ проверяйте ваш Gemfile.lock. Если вы работаете над приложением Rails, тогда проверьте свой Gemfile.lock. Более подробная информация здесь - yehudakatz.com/2010/12/16/…
johnmcaliley

Спасибо за полезную статью.
ashisrai_

1
Вы должны поместить то, что сказал ковбой в вашем ответе re: gems.
Аарона

Ссылка на статью нуждается в новой ссылке.
Росс

4
Пожалуйста, не делай этого !! Держите свой Gemfile.lock там, где он есть! Как сказано здесь и здесь .
Рикардо Рувер

50

Настоящая проблема возникает, когда вы работаете с приложением Rails с открытым исходным кодом, для которого требуется настраиваемый адаптер базы данных. Я разрабатываю ветку Rails 3 Fat Free CRM. Я предпочитаю postgres, но мы хотим, чтобы база данных по умолчанию была mysql2.

В этом случае Gemfile.lockвсе еще нужно зарегистрироваться с набором драгоценных камней по умолчанию, но мне нужно игнорировать изменения, которые я внес в него на своей машине. Для этого я запускаю:

git update-index --assume-unchanged Gemfile.lock

и повернуть вспять:

git update-index --no-assume-unchanged Gemfile.lock

Также полезно включить что-то вроде следующего кода в ваш Gemfile. Это загрузит соответствующий гем адаптера базы данных, основанный на вашем database.yml.

# Loads the database adapter gem based on config/database.yml (Default: mysql2)
# -----------------------------------------------------------------------------
db_gems = {"mysql2"     => ["mysql2", ">= 0.2.6"],
           "postgresql" => ["pg",     ">= 0.9.0"],
           "sqlite3"    => ["sqlite3"]}
adapter = if File.exists?(db_config = File.join(File.dirname(__FILE__),"config","database.yml"))
  db = YAML.load_file(db_config)
  # Fetch the first configured adapter from config/database.yml
  (db["production"] || db["development"] || db["test"])["adapter"]
else
  "mysql2"
end
gem *db_gems[adapter]
# -----------------------------------------------------------------------------

Я не могу сказать, является ли это признанной лучшей практикой или нет, но она хорошо работает для меня.


2
Очень полезная информация ... не знаю, почему вы получили только 3 балла, а менее полезный ответ - 50 баллов. О, да, посмотри на даты. (Одним из главных недостатков SO является несоразмерное преимущество, которое дает ответ вскоре после того, как вопрос задан.)
iconoclast,

1
@iconoclast: я очень рад, что ты опубликовал то, что сделал. Я думаю, что многие люди, которые приходят на этот пост, включая меня, "ослеплены" заголовком вопроса. Теперь я понимаю, что мой ответ отвечает только на конкретный вариант использования и не обязательно правильный ответ на этот вопрос. Я буду работать над его обновлением в ближайшее время. Тем не менее, ОП не должен был помечать мой ответ как правильный, если он не удовлетворял его / ее потребностям.
rwilliams

34

У меня и моих коллег по работе разный Gemfile.lock, потому что мы используем разные платформы, Windows и Mac, а наш сервер - Linux.

Мы решили удалить Gemfile.lock в репозитории и создать Gemfile.lock.server в репозитории git, как и database.yml. Затем, прежде чем развернуть его на сервере, мы копируем Gemfile.lock.server в Gemfile.lock на сервере, используя функцию cap deploy


5
У меня есть приложение, которое я разрабатываю в OSX и затем должен развернуть на сервере Windows. Отслеживание Gemfile.lock с помощью git оказалось плохой идеей, поэтому оно попало в мой файл .gitignore. Многие драгоценные камни требуют разных версий для разных сред. В идеале, вам следует избегать попадания в такую ​​ситуацию, но у меня не было выбора (черт вас, ИТ-отдел!)
Брэд,

11

Соглашаясь с r-dub, держите его под контролем исходного кода, но для меня реальная выгода заключается в следующем:

совместная работа в идентичных средах (без учета windohs и linux / mac). До Gemfile.lock следующий чувак, который установил проект, мог видеть все виды запутанных ошибок, обвиняя себя, но он был просто тем счастливчиком, который получил следующую версию супер-драгоценного камня, нарушив существующие зависимости.

Хуже того, это происходило на серверах, получая непроверенную версию, если не дисциплинировали и не устанавливали точную версию. Gemfile.lock делает это явно, и он явно скажет вам, что ваши версии отличаются.

Примечание: не забудьте группировать вещи, как: разработка и: тест


11

Документы Bundler также решают этот вопрос:

ОРИГИНАЛ: http://gembundler.com/v1.3/rationale.html

РЕДАКТИРОВАТЬ: http://web.archive.org/web/20160309170442/http://bundler.io/v1.3/rationale.html

Смотрите раздел «Проверка кода в контроле версий»:

После некоторой разработки приложения проверьте приложение вместе со снимком Gemfile и Gemfile.lock. Теперь в вашем хранилище есть запись точных версий всех драгоценных камней, которые вы использовали в последний раз, когда вы точно знали, что приложение работало. Имейте в виду, что, хотя ваш Gemfile перечисляет только три драгоценных камня (с разной степенью строгости версии), ваше приложение зависит от десятков драгоценных камней, если принять во внимание все неявные требования драгоценных камней, от которых вы зависите.

Это важно: Gemfile.lock делает ваше приложение единым пакетом как вашего собственного кода, так и стороннего кода, который он запускал в последний раз, когда вы точно знали, что все работает. Указание точных версий стороннего кода, от которого вы зависите, в вашем Gemfile не даст такой же гарантии, потому что гемы обычно объявляют диапазон версий для своих зависимостей.

В следующий раз, когда вы запустите пакетную установку на том же компьютере, пакет увидит, что у него уже есть все необходимые зависимости, и пропустит процесс установки.

Не проверяйте каталог .bundle или какие-либо файлы внутри него. Эти файлы специфичны для каждого конкретного компьютера и используются для сохранения параметров установки между запусками команды bundle install.

Если вы запустили пакет, то гемы (хотя и не git гемы), необходимые для вашего комплекта, будут загружены в вендор / кеш. Bundler может работать без подключения к Интернету (или серверу RubyGems), если все нужные вам гемы присутствуют в этой папке и зарегистрированы в вашем контроле исходного кода. Это необязательный шаг, который не рекомендуется из-за увеличения размера репозитория исходного кода.


4

Нет Gemfile.lock означает:

  • Новые участники не могут запускать тесты, потому что странные вещи терпят неудачу, поэтому они не будут вносить вклад или получать неудачные PR ... плохой первый опыт.
  • Вы не можете вернуться к летнему проекту и исправить ошибку без необходимости обновлять / переписывать проект, если вы потеряли свой локальный Gemfile.lock

-> Всегда проверяйте Gemfile.lock, заставляйте travis удалять его, если вы хотите быть более тщательным https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3

Немного опоздал на вечеринку, но ответы все же заняли у меня время, и иностранные читатели поняли эту проблему. Итак, я хочу обобщить то, что я узнал о Gemfile.lock.

Когда вы создаете приложение Rails, вы используете определенные версии гемов на своем локальном компьютере. Если вы хотите избежать ошибок в производственном режиме и других ветвях, вы должны везде использовать этот один файл Gemfile.lock и указывать сборщику bundleдля перестройки гемов каждый раз, когда он изменяется.

Если Gemfile.lockна вашем компьютере произошли изменения, и Git не позволяет вам git pull, вы должны написать, git reset --hardчтобы избежать изменения этого файла, и писать git pullснова.


Если файл изменяется автоматически, например, в процессе сборки, это явный признак того, что его не следует добавлять в систему контроля версий.
Томас С.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.