Чи повинен Gemfile.lock включатись у .gitignore?

Я щось нове для постачальника та файлів, які він створює. У мене є копія git repo від GitHub, до якої сприяють багато людей, тому я з подивом виявив, що цей постачальник створив файл, який не існував у репо і не був у .gitignoreсписку.

Оскільки я роздрібнив його, я знаю, що додавання його до репо не призведе до порушення нічого для основного репо, але якщо я виконаю запит на виклик, це спричинить проблему?

Чи Gemfile.lockслід включити до сховища?

Якщо припустити, що ви не пишете рубігем, Gemfile.lock має бути у вашому сховищі. Він використовується як знімок усіх потрібних дорогоцінних каменів та їх залежностей. Таким чином, постачальнику не доведеться перераховувати всі залежності від дорогоцінного каміння кожного разу при розгортанні тощо.

З коментаря cowboycoded нижче:

Якщо ви працюєте над дорогоцінним каменем, то НЕ перевіряйте у своєму Gemfile.lock. Якщо ви працюєте над додатком Rails, то перевірте це в своєму Gemfile.lock.

Ось приємна стаття, що пояснює, що таке файл блокування.

Справжня проблема виникає, коли ви працюєте над додатком Rails з відкритим кодом, який повинен мати налаштований адаптер бази даних. Я розробляю гілку RM Free FM. Мої переваги - це 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 repo, подібно до database.yml. Потім перед тим, як розгорнути його на сервері, ми копіюємо Gemfile.lock.server на Gemfile.lock на сервері за допомогою гачки розгортання шапки

Погоджуючись з r-dub, тримайте його в контролі джерел, але для мене справжня користь полягає в цьому:

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

Гірше, що це сталося на серверах, отримуючи неперевірену версію, якщо не бути дисциплінованим та встановити точну версію. Gemfile.lock робить це явним, і він чітко скаже вам, що ваші версії різні.

Примітка: не забудьте згрупувати речі, такі як: development та: test

Документи Bundler також вирішують це питання:

ORIGINAL: 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, не дасть однакової гарантії, оскільки дорогоцінні камені зазвичай декларують діапазон версій для їх залежностей.

Наступного разу, коли ви запустите пакет, встановлений на одній машині, bundler побачить, що він вже має всі необхідні вам залежності, і пропустить процес установки.

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

Якщо ви запустили пакет пакетів, дорогоцінні камені (хоча це не git gems), необхідні для вашого пакета, будуть завантажені у постачальника / кеш. Bundler може працювати без підключення до Інтернету (або сервера RubyGems), якщо всі потрібні дорогоцінні камені знаходяться у цій папці та зареєстровані у вашому джерелі управління. Це необов'язковий крок і не рекомендується через збільшення розміру вашого сховища управління джерелом.

Немає Gemfile.lock означає:

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

-> Завжди перевіряйте в Gemfile.lock, змушуйте його видалити, якщо ви хочете бути надзвичайно ретельним 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знову.