Question Gemfile.lock doit-il être inclus dans .gitignore?


Je suis en quelque sorte nouveau pour le bundler et les fichiers qu'il génère. J'ai une copie d'un dépôt Git de GitHub auquel de nombreuses personnes ont contribué, donc j'ai été surpris de découvrir que bundler a créé un fichier qui n'existait pas dans le repo et qui n'était pas dans le .gitignore liste.

Depuis que je l'ai fourchu, je sais que l'ajouter à la pension ne cassera rien pour le dépôt principal, mais si je fais une demande de traction, cela causera-t-il un problème?

Devrait Gemfile.lock être inclus dans le référentiel?


449
2017-11-11 05:03


origine


Réponses:


En supposant que vous n'écrivez pas un rubygem, Gemfile.lock devrait être dans votre dépôt. Il est utilisé comme un instantané de toutes vos gemmes requises et de leurs dépendances. De cette façon, Bundler n'a pas besoin de recalculer toutes les dépendances de gemmes à chaque fois que vous déployez, etc.

D'après le commentaire de cowboycoded.

Si vous travaillez sur un bijou, alors DO   PAS vérifier dans votre Gemfile.lock.

Voici une belle article expliquer ce qu'est le fichier de verrouillage.


495
2017-11-11 05:13



Le vrai problème se produit lorsque vous travaillez sur une application Rails open-source qui nécessite un adaptateur de base de données configurable. Je développe la branche Rails 3 de Fat Free CRM. Ma préférence est postgres, mais nous voulons que la base de données par défaut soit mysql2.

Dans ce cas, Gemfile.lock doit encore être enregistré avec le jeu de gemmes par défaut, mais je dois ignorer les modifications que je lui ai apportées sur ma machine. Pour ce faire, je cours:

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

et inverser:

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

Il est également utile d'inclure quelque chose comme le code suivant dans votre Gemfile. Cela charge la gem de l'adaptateur de base de données approprié, basée sur votre 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]
# -----------------------------------------------------------------------------

Je ne peux pas dire si c'est une bonne pratique établie ou non, mais cela fonctionne bien pour moi.


47
2018-03-19 04:39



Mes collègues et moi-même avons Gemfile.lock différent, car nous utilisons différentes plates-formes, Windows et Mac, et notre serveur est Linux.

Nous décidons de supprimer Gemfile.lock dans repo et de créer Gemfile.lock.server dans git repo, tout comme database.yml. Ensuite, avant de le déployer sur le serveur, nous copions Gemfile.lock.server sur Gemfile.lock sur le serveur à l'aide du hook de déploiement cap


32
2018-06-16 02:31



En accord avec r-dub, gardez-le dans le contrôle de la source, mais pour moi, le véritable avantage est le suivant:

collaboration dans des environnements identiques (sans tenir compte des windohs et des trucs de linux / mac). Avant Gemfile.lock, le prochain mec à installer le projet pouvait voir toutes sortes d'erreurs confuses, se blâmer, mais il était juste ce gars chanceux obtenir la prochaine version de super gem, en brisant les dépendances existantes.

Pire encore, cela s'est produit sur les serveurs, obtenant une version non testée à moins d'être disciplinée et d'installer la version exacte. Gemfile.lock rend cela explicite, et il vous dira explicitement que vos versions sont différentes.

Note: n'oubliez pas de grouper des choses, comme: développement et: test


11
2017-11-11 16:34



Les docteurs Bundler répondent également à cette question:

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

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

Voir la section intitulée "Vérification de votre code dans Version Control":

Après avoir développé votre application pendant un certain temps, archivez la   application avec l'instantané Gemfile et Gemfile.lock. À présent,   votre référentiel a un enregistrement des versions exactes de toutes les gemmes   que vous avez utilisé la dernière fois que vous savez à coup sûr que l'application   travaillé. Gardez à l'esprit que votre Gemfile ne contient que trois gemmes   (avec des degrés variables de rigueur de version), votre application dépend   sur des dizaines de gemmes, une fois que vous prenez en considération tous les   exigences implicites des gemmes dont vous dépendez.

Ceci est important: le Gemfile.lock rend votre application unique   paquet de votre propre code et le code tiers, il a couru le dernier   le temps que vous sachiez que tout a fonctionné. Spécifier exact   les versions du code tiers dont vous dépendez dans votre Gemfile seraient   pas fournir la même garantie, car les pierres précieuses déclarent généralement une gamme   de versions pour leurs dépendances.

La prochaine fois que vous exécuterez une installation groupée sur la même machine, Bundler   voir qu'il a déjà toutes les dépendances dont vous avez besoin, et passez   processus d'installation.

Ne vérifiez pas dans le répertoire .bundle, ou l'un des fichiers à l'intérieur.   Ces fichiers sont spécifiques à chaque machine particulière et sont utilisés pour   conserver les options d'installation entre les exécutions de l'installation   commander.

Si vous avez couru bundle pack, les gemmes (mais pas les git gems)   requis par votre forfait sera téléchargé dans le fournisseur / cache. Bundler   peut fonctionner sans se connecter à Internet (ou au serveur RubyGems) si   toutes les gemmes dont vous avez besoin sont présentes dans ce dossier et archivées pour   votre contrôle de source. Ceci est une étape facultative et non recommandée.   en raison de l'augmentation de la taille de votre référentiel de contrôle source.


10
2018-04-17 16:47



Un peu tard à la fête, mais les réponses me prenaient encore du temps et des lectures étrangères pour comprendre ce problème. Donc, je veux résumer ce que j'ai découvert sur le Gemfile.lock.

Lorsque vous créez une application Rails, vous utilisez certaines versions de gemmes sur votre ordinateur local. Si vous voulez éviter les erreurs dans le mode de production et les autres branches, vous devez utiliser ce fichier Gemfile.lock partout et demander à bundle pour reconstruire des gemmes chaque fois qu'il change.

Si Gemfile.lock a changé sur votre machine de production et Git ne vous laisse pas git pull, vous devriez écrire git reset --hard pour éviter ce changement de fichier et écrire git pull encore.


3
2017-08-24 04:55



No Gemfile.lock signifie:

  • les nouveaux contributeurs ne peuvent pas exécuter de tests car les choses bizarres échouent, donc ils ne contribueront pas ou n'obtiendront pas les PRs ... mauvaise première expérience.
  • vous ne pouvez pas revenir à un projet de x ans et corriger un bogue sans avoir à mettre à jour / réécrire le projet si vous avez perdu votre fichier Gemfile.lock local

-> Toujours vérifier dans Gemfile.lock, faites le supprimer par travis si vous voulez être plus complet https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3
2017-08-15 23:05