Faut-il inclure Gemfile.lock dans .gitignore?

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?

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.

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.

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

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

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.

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/

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.