Il vero problema si verifica quando si sta lavorando su un'applicazione open-source Rails che ha bisogno di 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, il numero di serie Gemfile.lock deve ancora essere archiviato con il set predefinito di gem, ma è necessario ignorare le modifiche apportate alla mia macchina. Per fare questo, ho eseguito:
git update-index --assume-unchanged Gemfile.lock
e per invertire:
git update-index --no-assume-unchanged Gemfile.lock
E 'anche utile includere qualcosa come il seguente codice nel tuo Gemfile. Questo carica la gemma dell'adattatore del database appropriato, in base al tuo 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 pratica consolidata o no, ma funziona bene per me.
correlati: http://stackoverflow.com/questions/14034561/should-gemfile-lock-be-committed-to-source-control-on-windows – ripper234
Se hai trovato la tua qui perché hai Linux e Windows che condividono lo stesso repository, vedi la risposta di Joe Yang. Al momento della mia scrittura questo è classificato al terzo posto. Vedi anche http://stackoverflow.com/questions/14034561/should-gemfile-lock-be-committed-to-source-control-on-windows –