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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документы 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), если все нужные вам гемы присутствуют в этой папке и зарегистрированы в вашем контроле исходного кода. Это необязательный шаг, который не рекомендуется из-за увеличения размера репозитория исходного кода.

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

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

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

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

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

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