Gemfile.lock dovrebbe essere incluso in .gitignore?

Sono un po 'nuovo per il bundler e i file che genera. Ho una copia di un repository git di GitHub a cui stanno contribuendo molte persone, quindi sono stato sorpreso di scoprire che il bundler ha creato un file che non esisteva nel repository e non era .gitignorenell'elenco.

Dato che l'ho modificato, so che aggiungerlo al repository non romperà nulla per il repository principale, ma se faccio una richiesta pull, causerà un problema?

Dovrebbe Gemfile.lockessere incluso nel repository?

Supponendo che non stai scrivendo un rubygem, Gemfile.lock dovrebbe essere nel tuo repository. È usato come un'istantanea di tutte le gemme richieste e delle loro dipendenze. In questo modo il bundler non deve ricalcolare tutte le dipendenze gemma ogni volta che si distribuisce, ecc.

Dal commento di cowboycoded di seguito:

Se stai lavorando su una gemma, NON controllare in Gemfile.lock. Se stai lavorando su un'app Rails, quindi fai check in Gemfile.lock.

Ecco un bell'articolo che spiega qual è il file di blocco.

Il vero problema si verifica quando si lavora su un'app Rails open source che deve avere un adattatore di database configurabile. Sto sviluppando il ramo Rails 3 di Fat Free CRM. La mia preferenza è postgres, ma vogliamo che il database predefinito sia mysql2.

In questo caso, è Gemfile.lockancora necessario effettuare il check-in con il set predefinito di gemme, ma devo ignorare le modifiche che ho apportato alla mia macchina. A tale scopo, corro:

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

e per invertire:

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

È anche utile includere qualcosa come il seguente codice nel tuo Gemfile. Questo carica la gemma dell'adattatore di database appropriata, basata su 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]
# -----------------------------------------------------------------------------

Non posso dire se questa è una buona pratica consolidata o meno, ma funziona bene per me.

Io e i miei compagni di lavoro abbiamo Gemfile.lock diverso, perché utilizziamo piattaforme, finestre e mac diverse e il nostro server è Linux.

Decidiamo di rimuovere Gemfile.lock in repo e di creare Gemfile.lock.server in git repo, proprio come database.yml. Quindi, prima di distribuirlo sul server, copiamo Gemfile.lock.server su Gemfile.lock sul server utilizzando il hook di distribuzione cap

D'accordo con r-dub, tienilo nel controllo del codice sorgente, ma per me il vero vantaggio è questo:

collaborazione in ambienti identici (ignorando i contenuti windohs e linux / mac). Prima di Gemfile.lock, il prossimo amico a installare il progetto poteva vedere tutti i tipi di errori confusi, incolpare se stesso, ma era proprio quel ragazzo fortunato a ottenere la prossima versione di super gemma, rompendo le dipendenze esistenti.

Peggio ancora, questo è successo sui server, ottenendo la versione non testata a meno che non sia disciplinato e installare la versione esatta. Gemfile.lock lo rende esplicito e ti dirà esplicitamente che le tue versioni sono diverse.

Nota: ricordati di raggruppare cose come: sviluppo e: test

I documenti del Bundler affrontano anche questa domanda:

ORIGINALE: http://gembundler.com/v1.3/rationale.html

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

Vedi la sezione chiamata "Verifica del codice nel controllo versione":

Dopo aver sviluppato l'applicazione per un po ', controlla l'applicazione insieme allo snapshot Gemfile e Gemfile.lock. Ora, il tuo repository ha un registro delle versioni esatte di tutte le gemme che hai usato l'ultima volta che sai per certo che l'applicazione ha funzionato. Tieni presente che mentre il tuo Gemfile elenca solo tre gemme (con vari gradi di rigore della versione), la tua applicazione dipende da dozzine di gemme, una volta che prendi in considerazione tutti i requisiti impliciti delle gemme da cui dipendi.

Questo è importante: Gemfile.lock trasforma la tua applicazione in un unico pacchetto sia del tuo codice che del codice di terze parti che è stato eseguito l'ultima volta che sai per certo che tutto ha funzionato. Specificare le versioni esatte del codice di terze parti da cui dipendi nel tuo Gemfile non fornirebbe la stessa garanzia, poiché le gemme di solito dichiarano un intervallo di versioni per le loro dipendenze.

La prossima volta che esegui l'installazione del bundle sullo stesso computer, il bundler vedrà che ha già tutte le dipendenze di cui hai bisogno e salterà il processo di installazione.

Non controllare nella directory .bundle o in uno dei file al suo interno. Tali file sono specifici di ciascun computer specifico e vengono utilizzati per mantenere le opzioni di installazione tra le esecuzioni del comando di installazione del bundle.

Se hai eseguito il bundle pack, le gemme (sebbene non le gemme git) richieste dal tuo bundle verranno scaricate nel fornitore / cache. Bundler può funzionare senza connettersi a Internet (o al server RubyGems) se tutte le gemme di cui hai bisogno sono presenti in quella cartella e registrate al tuo controllo del codice sorgente. Questo è un passaggio facoltativo e non raccomandato, a causa dell'aumento delle dimensioni del repository di controllo del codice sorgente.

Nessun Gemfile.lock significa:

• i nuovi contributori non possono eseguire test perché le cose strane falliscono, quindi non contribuiranno o non avranno PR fallite ... prima brutta esperienza.
• non puoi tornare al progetto ax year old e correggere un bug senza dover aggiornare / riscrivere il progetto se hai perso il Gemfile.lock locale

-> Controlla sempre Gemfile.lock, fai in modo che travis lo elimini se vuoi essere ancora più approfondito https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

Un po 'tardi alla festa, ma le risposte mi hanno ancora impiegato del tempo e letture straniere per capire questo problema. Quindi voglio riassumere ciò che ho scoperto sul Gemfile.lock.

Quando si crea un'app Rails, si utilizzano determinate versioni di gemme nel computer locale. Se vuoi evitare errori nella modalità di produzione e in altri rami, devi usare quel file Gemfile.lock ovunque e dire al bundler di bundlericostruire le gemme ogni volta che cambia.

Se Gemfile.lockè cambiato sulla tua macchina di produzione e Git non ti consente git pull, dovresti scrivere git reset --hardper evitare la modifica di quel file e scrivere di git pullnuovo.