web-dev-qa-db-fra.com

Est-ce que Gemfile.lock doit être inclus dans .gitignore?

Je suis en quelque sorte un nouveau venu pour regrouper et les fichiers qu'il génère. J'ai une copie d'un repo git de GitHub auquel beaucoup de gens ont contribué. J'ai donc été surpris de voir que le bundler avait créé un fichier qui n'existait pas dans le repo et ne figurait pas dans la liste .gitignore.

Depuis que je l'ai ajouté, je sais que l'ajouter à la pension n'aura aucun impact sur la mise en pension principale, mais si je fais une demande d'extraction, cela posera-t-il un problème?

Gemfile.lock devrait-il être inclus dans le référentiel?

gitversion-controlbundler
474
triplethreat78

En supposant que vous n'écriviez 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 manière, le groupeur n'a pas à recalculer toutes les dépendances de gemmes à chaque déploiement, etc.

Du commentaire de cowboycoded.

Si vous travaillez sur un joyau, NE PAS enregistrer votre Gemfile.lock.

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

523
rwilliams

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

Dans ce cas, Gemfile.lock doit toujours être vérifié avec le jeu de gemmes par défaut, mais je dois ignorer les modifications que j'ai apportées 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 le gem adaptateur de base de données approprié, basé 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 s'il s'agit d'une meilleure pratique établie ou non, mais cela fonctionne bien pour moi.

49
ndbroadbent

Mes collègues et moi avons un fichier 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 du référentiel et de créer Gemfile.lock.server dans le référentiel git, comme pour database.yml. Ensuite, avant de le déployer sur le serveur, nous copions Gemfile.lock.server vers Gemfile.lock sur le serveur à l'aide de cap deploy hook

32
Joe Yang

Si vous êtes d’accord avec r-dub, gardez 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 éléments windohs et linux/mac). Avant Gemfile.lock, le prochain type à installer le projet risquait de se faire reprocher toutes sortes d’erreurs confuses, mais c’était tout simplement ce chanceux qui obtenait la prochaine version de super gem et supprimait les dépendances existantes.

Pire, 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 ceci explicite, et il vous dira explicitement que vos versions sont différentes.

Remarque: n'oubliez pas de regrouper les éléments, tels que: développement et: test

11
oma

La documentation de Bundler aborde é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

Voir 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-la avec les instantanés 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, si votre Gemfile ne répertorie que trois gemmes (avec des degrés de précision de version différents), votre application dépend de dizaines de gemmes, une fois que vous avez pris en compte toutes les exigences implicites des gemmes dont vous dépendez.

Ceci est important: Gemfile.lock transforme votre application en un package unique composé à la fois de votre propre code et du code tiers utilisé lors de la dernière utilisation. Vous savez avec certitude que tout fonctionne. Spécifier des versions exactes du code tiers dont vous dépendez dans votre Gemfile ne fournirait pas la même garantie, car les gems déclarent généralement une plage de versions pour leurs dépendances.

La prochaine fois que vous lancerez une installation groupée sur le même ordinateur, celui-ci verra qu'il possède déjà toutes les dépendances dont vous avez besoin et ignore le processus d'installation.

Ne vérifiez pas dans le répertoire .bundle, ni dans aucun des fichiers qu'il contient. Ces fichiers sont spécifiques à chaque ordinateur et permettent de conserver les options d'installation entre les exécutions de la commande bundle install.

Si vous avez exécuté un ensemble d'ensembles, les gems (bien que ce ne soient pas les gems) requis par votre ensemble seront téléchargés dans vendor/cache. Bundler peut fonctionner sans connexion à Internet (ni au serveur RubyGems) si tous les gems dont vous avez besoin sont présents dans ce dossier et archivés dans votre contrôle de code source. Il s'agit d'une étape facultative, non recommandée, en raison de l'augmentation de la taille de votre référentiel de contrôle de source.

11
Willie Wheeler

Pas de Gemfile.lock signifie:

  • les nouveaux contributeurs ne peuvent pas exécuter de tests car des choses étranges échouent, ils ne contribueront donc pas ou n'auront pas de relations publiques défaillantes ... mauvaise première expérience.
  • vous ne pouvez pas revenir à un projet vieux 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 en sorte que travis le supprime si vous voulez être plus approfondi https://grosser.it/2015/08/14/check-in-your-gemfile-lock/ =

4
grosser

Un peu tard pour le parti, mais les réponses me prirent toujours du temps et des lectures étrangères pour comprendre ce problème. Je souhaite donc résumer ce que j'ai découvert sur Gemfile.lock.

Lorsque vous créez une application Rails, vous utilisez certaines versions de gems sur votre ordinateur local. Si vous voulez éviter les erreurs en mode de production et dans les autres branches, vous devez utiliser ce fichier Gemfile.lock partout et indiquer à bundler bundle de reconstruire les pierres précieuses chaque fois qu'il change.

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

3
Gediminas