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

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

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

Должен ли Gemfile.lock быть включен в репозиторий?

ОТВЕТЫ

Ответ 1

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

Из комментария, полученного от cowboycoded.

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

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

Ответ 2

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

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

Ответ 3

Мои товарищи по работе и у меня разные Gemfile.lock, потому что мы используем разные платформы, windows и mac, а наш сервер - Linux.

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

Ответ 4

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

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

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

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

Ответ 5

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

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

EDIT: http://web.archive.org/web/20160309170442/http://bundler.io/v1.3/rationale.html

Смотрите раздел "Проверка кода в управлении версиями":

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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