Должен ли Gemfile.lock быть включен в .gitignore? - PullRequest
472 голосов
/ 11 ноября 2010

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

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

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

Ответы [ 7 ]

521 голосов
/ 11 ноября 2010

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

Из комментария с ковбойским кодом.

Если вы работаете над драгоценным камнем, то ДО НЕ проверяйте свой Gemfile.lock.

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

49 голосов
/ 19 марта 2011

Настоящая проблема возникает, когда вы работаете с приложением 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]
# -----------------------------------------------------------------------------

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

32 голосов
/ 16 июня 2011

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

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

11 голосов
/ 17 апреля 2013

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

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

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

См. Раздел «Проверка кода в версии».Control ":

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

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

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

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

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

11 голосов
/ 11 ноября 2010

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

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

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

Примечание: не забывайте группировать вещи, как: development и: test

4 голосов
/ 16 августа 2016

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

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

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

3 голосов
/ 24 августа 2013

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

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

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

...