Faut-il inclure Gemfile.lock dans .gitignore?


501

Je suis en quelque sorte nouveau sur bundler et les fichiers qu'il génère. J'ai une copie d'un dépôt git de GitHub auquel beaucoup de gens ont contribué, j'ai donc été surpris de constater que le bundler a créé un fichier qui n'existait pas dans le dépôt et n'était pas dans la .gitignoreliste.

Depuis que je l'ai forké, je sais que l'ajouter au référentiel ne cassera rien pour le référentiel principal, mais si je fais une demande de pull, cela causera-t-il un problème?

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



2
Si vous avez trouvé votre chemin ici parce que vous avez des boîtiers Linux et Windows partageant le même dépôt, voir la réponse de Joe Yang. Au moment où j'écris ceci, il est classé troisième. Voir également stackoverflow.com/questions/14034561/…
Peter Berg

Réponses:


549

En supposant que vous n'écrivez pas un rubygem, Gemfile.lock devrait être dans votre référentiel. Il est utilisé comme un instantané de toutes vos gemmes requises et de leurs dépendances. De cette façon, bundler n'a pas à recalculer toutes les dépendances de gemmes à chaque déploiement, etc.

Du commentaire de cowboycoded ci-dessous:

Si vous travaillez sur une gemme, alors NE PAS archiver votre Gemfile.lock. Si vous travaillez sur une application Rails, alors vérifiez votre Gemfile.lock.

Voici un bel article expliquant ce qu'est le fichier de verrouillage.


88
Cela dépend de ce sur quoi vous travaillez. Si vous travaillez sur une gemme, alors NE PAS archiver votre Gemfile.lock. Si vous travaillez sur une application Rails, alors vérifiez votre Gemfile.lock. Plus d'infos ici - yehudakatz.com/2010/12/16/…
johnmcaliley

Thx pour un article utile.
ashisrai_

1
vous devriez mettre ce que cowboycoded a dit dans votre réponse concernant les gemmes.
aarona

Le lien de l'article a besoin d'un nouveau href.
Ross

4
S'il vous plaît ne faites pas ça !! Gardez votre Gemfile.lock où il se trouve! Comme dit ici et ici .
Ricardo Ruwer

50

Le vrai problème se produit lorsque vous travaillez sur une application Rails open-source qui doit disposer d'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.lockdoit toujours être archivé avec l'ensemble de gemmes par défaut, mais je dois ignorer les modifications que j'ai apportées à celui-ci sur ma machine. Pour ce faire, je lance:

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 gemme d'adaptateur de base de données appropriée, 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.


2
Information très utile ... je ne sais pas pourquoi vous n'avez que 3 points et une réponse moins utile a 50 points. Oh, oui, regardez les horodatages. (L'un des grands échecs de SO est les avantages disproportionnés qui découlent de la réponse peu de temps après que la question soit posée.)
iconoclaste du

1
@iconoclast: Je suis vraiment content que vous ayez posté ce que vous avez fait. Je pense que beaucoup de gens qui viennent à ce poste, moi y compris, sont "aveuglés" par le titre de la question. Je me rends compte maintenant que ma réponse ne répond qu'à un cas d'utilisation spécifique et pas nécessairement la bonne réponse à cette question. Je vais travailler sur sa mise à jour dans un avenir proche. Cela dit, le PO n'aurait pas dû marquer ma réponse comme correcte si elle ne répondait pas à ses besoins.
rwilliams

34

Mes collègues et moi avons différents Gemfile.lock, car nous utilisons différentes plates-formes, fenêtres et mac, et notre serveur est Linux.

Nous décidons de supprimer Gemfile.lock dans le référentiel 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 dans Gemfile.lock sur le serveur à l'aide du crochet de déploiement de capuchon


5
J'ai une application que je développe sous OSX et que je dois ensuite déployer sur un serveur Windows. Le suivi de Gemfile.lock avec git s'est avéré être une mauvaise idée, il est donc allé dans mon fichier .gitignore. Beaucoup de gemmes nécessitent des versions différentes pour les différents environnements. Idéalement, vous devriez éviter d'être dans cette situation, mais je n'avais pas le choix (bon sang le service informatique!)
brad

11

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

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

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

Remarque: n'oubliez pas de regrouper les choses, comme: développement et: test


11

Les documents de Bundler abordent également cette question:

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

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

Consultez la section intitulée «Vérification de votre code dans le contrôle de version»:

Après avoir développé votre application pendant un certain temps, archivez l'application avec l'instantané Gemfile et Gemfile.lock. Maintenant, votre référentiel a un enregistrement des versions exactes de toutes les gemmes que vous avez utilisées la dernière fois que vous savez avec certitude que l'application a fonctionné. Gardez à l'esprit que même si votre Gemfile ne répertorie que trois gemmes (avec différents degrés de rigueur de version), votre application dépend de dizaines de gemmes, une fois que vous avez pris en considération toutes les exigences implicites des gemmes dont vous dépendez.

C'est important: le Gemfile.lock fait de votre application un package unique de votre propre code et du code tiers qu'il a exécuté la dernière fois que vous savez avec certitude que tout a fonctionné. La spécification de versions exactes du code tiers dont vous dépendez dans votre Gemfile ne fournirait pas la même garantie, car les gemmes déclarent généralement une gamme de versions pour leurs dépendances.

La prochaine fois que vous exécuterez l'installation de bundle sur la même machine, bundler verra qu'il a déjà toutes les dépendances dont vous avez besoin et ignorera le processus d'installation.

N'archivez pas le répertoire .bundle, ni aucun des fichiers qu'il contient. Ces fichiers sont spécifiques à chaque machine particulière et sont utilisés pour conserver les options d'installation entre les exécutions de la commande bundle install.

Si vous avez exécuté le pack bundle, les gemmes (mais pas les gemmes git) requises par votre bundle seront téléchargées dans le fournisseur / cache. Bundler peut s'exécuter 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 dans votre contrôle de code source. Il s'agit d'une étape facultative, et non recommandée, en raison de l'augmentation de la taille de votre référentiel de contrôle de code source.


4

Aucun Gemfile.lock signifie:

  • les nouveaux contributeurs ne peuvent pas exécuter de tests parce que des choses étranges échouent, donc ils ne contribueront pas ou n'obtiendront pas de RP défaillants ... mauvaise première expérience.
  • vous ne pouvez pas revenir à un projet vieux d'un an et corriger un bogue sans avoir à mettre à jour / réécrire le projet si vous avez perdu votre Gemfile.lock local

-> Vérifiez toujours dans Gemfile.lock, faites supprimer travis si vous voulez être très complet https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3

Un peu tard pour la fête, mais les réponses m'ont tout de même pris du temps et des lectures étrangères pour comprendre ce problème. Je veux donc résumer ce que j'ai découvert sur Gemfile.lock.

Lorsque vous créez une application Rails, vous utilisez certaines versions de gemmes sur votre machine locale. Si vous voulez éviter les erreurs dans le mode de production et les autres branches, vous devez utiliser ce fichier Gemfile.lock partout et dire à bundler de bundlereconstruire les gemmes à chaque fois qu'il change.

Si Gemfile.locka changé sur votre machine de production et que Git ne vous le permet pas git pull, vous devez écrire git reset --hardpour éviter ce changement de fichier et réécrire git pull.


Si un fichier change automatiquement, par exemple par un processus de génération, c'est un signe clair qu'il ne doit pas être ajouté au contrôle de version.
Thomas S.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.