Sollte Gemfile.lock in .gitignore enthalten sein?

Lesezeit: 8 Minuten

Sollte Gemfilelock in gitignore enthalten sein
Aaron

Ich bin ziemlich neu bei Bundler und den Dateien, die er generiert. Ich habe eine Kopie eines Git-Repos von GitHub, zu dem viele Leute beigetragen haben, also war ich überrascht, dass Bundler eine Datei erstellt hat, die nicht im Repo existierte und nicht im .gitignore Liste.

Da ich es gegabelt habe, weiß ich, dass das Hinzufügen zum Repo nichts für das Haupt-Repo kaputt macht, aber wenn ich eine Pull-Anfrage mache, wird es ein Problem verursachen?

Sollte Gemfile.lock in das Repository aufgenommen werden?

  • Siehe auch: stackoverflow.com/questions/14034561/…

    – Reißer234

    25. Dezember 2012 um 22:56 Uhr

  • Wenn Sie den Weg hierher gefunden haben, weil Sie Linux- und Windows-Boxen haben, die dasselbe Repo teilen, lesen Sie die Antwort von Joe Yang. Während ich dies schreibe, steht es an dritter Stelle. Siehe auch stackoverflow.com/questions/14034561/…

    – Peter Berg

    10. Oktober 2013 um 19:11 Uhr

1646172490 372 Sollte Gemfilelock in gitignore enthalten sein
williams

Angenommen, Sie schreiben kein Rubygem, sollte sich Gemfile.lock in Ihrem Repository befinden. Es wird als Momentaufnahme aller Ihrer erforderlichen Gems und ihrer Abhängigkeiten verwendet. Auf diese Weise muss Bundler nicht bei jeder Bereitstellung usw. alle Gem-Abhängigkeiten neu berechnen.

Aus dem Kommentar von cowboycoded unten:

Wenn Sie an einem Edelstein arbeiten, checken Sie NICHT Ihre Gemfile.lock ein. Wenn Sie an einer Rails-App arbeiten, checken Sie Ihre Gemfile.lock ein.

Hier ist ein nettes Artikel erklärt, was die Sperrdatei ist.

  • Hängt davon ab, woran Sie arbeiten. Wenn Sie an einem Edelstein arbeiten, checken Sie NICHT Ihre Gemfile.lock ein. Wenn Sie an einer Rails-App arbeiten, checken Sie Ihre Gemfile.lock ein. Mehr Infos hier – yehudakatz.com/2010/12/16/…

    – johnmcaliley

    4. Februar 2011 um 15:22 Uhr

  • Sie sollten das, was Cowboycode gesagt hat, in Ihre Antwort zu Edelsteinen aufnehmen.

    – Aaron

    9. Mai 2011 um 22:28 Uhr

  • Der Artikellink benötigt eine neue Href.

    – Roß

    13. Januar 2012 um 23:14 Uhr

  • Hier ist ein anderes sehr hilfreicher Best Practices-Leitfaden für Bündler

    – TrinitronX

    18. Juli 2012 um 0:45 Uhr

  • Bitte tu das nicht!! Behalten Sie Ihr Gemfile.lock, wo es ist! Wie gesagt Hier und Hier.

    – Ricardo Ruwer

    26. Mai 2017 um 21:01 Uhr

Das eigentliche Problem tritt auf, wenn Sie an einer Open-Source-Rails-App arbeiten, die einen konfigurierbaren Datenbankadapter haben muss. Ich entwickle den Rails 3-Zweig von Fat Free CRM. Meine Präferenz ist postgres, aber wir möchten, dass die Standarddatenbank mysql2 ist.

In diesem Fall, Gemfile.lock muss immer noch mit dem Standardsatz von Edelsteinen eingecheckt werden, aber ich muss Änderungen ignorieren, die ich auf meinem Computer daran vorgenommen habe. Um dies zu erreichen, führe ich aus:

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

und umzukehren:

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

Es ist auch nützlich, etwas wie den folgenden Code in Ihre einzufügen Gemfile. Dadurch wird das entsprechende Datenbankadapter-Gem basierend auf Ihrer database.yml geladen.

# 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]
# -----------------------------------------------------------------------------

Ich kann nicht sagen, ob dies eine etablierte Best Practice ist oder nicht, aber es funktioniert gut für mich.

  • Sehr nützliche Informationen … nicht sicher, warum Sie nur 3 Punkte haben und eine weniger nützliche Antwort 50 Punkte hat. Oh, ja, schau dir die Datumsstempel an. (Einer der großen Fehler von SO sind die unverhältnismäßigen Vorteile, die sich aus der Beantwortung ergeben, sobald die Frage gestellt wurde.)

    – Bilderstürmer

    1. Oktober 2011 um 2:35 Uhr

  • @iconoclast: Ich bin wirklich froh, dass du gepostet hast, was du getan hast. Ich denke, dass viele Leute, die zu diesem Beitrag kommen, mich eingeschlossen, durch den Titel der Frage “geblendet” werden. Mir ist jetzt klar, dass meine Antwort nur einen bestimmten Anwendungsfall beantwortet und nicht unbedingt die richtige Antwort auf diese Frage. Ich werde daran arbeiten, es in naher Zukunft zu aktualisieren. Das OP hätte meine Antwort jedoch nicht als richtig markieren sollen, wenn sie seine Bedürfnisse nicht erfüllt hätte.

    – rwilliams

    22. Januar 2012 um 9:18 Uhr


Meine Arbeitskollegen und ich haben unterschiedliche Gemfile.lock, weil wir verschiedene Plattformen verwenden, Windows und Mac, und unser Server Linux ist.

Wir entscheiden uns, Gemfile.lock im Repo zu entfernen und Gemfile.lock.server im Git-Repo zu erstellen, genau wie database.yml. Bevor wir es auf dem Server bereitstellen, kopieren wir Gemfile.lock.server in Gemfile.lock auf dem Server, indem wir den Cap-Deploy-Hook verwenden

  • Ich habe eine App, die ich in OSX entwickle und dann auf einem Windows-Server bereitstellen muss. Das Verfolgen von Gemfile.lock mit Git erwies sich als schlechte Idee, also ging es in meine .gitignore-Datei. Viele Edelsteine ​​erfordern unterschiedliche Versionen für die verschiedenen Umgebungen. Idealerweise sollten Sie es vermeiden, jemals in diese Situation zu geraten, aber ich hatte keine Wahl (verdammt, Sie IT-Abteilung!)

    – Brad

    26. Februar 2012 um 23:05 Uhr

Stimme r-dub zu, behalte es in der Quellcodeverwaltung, aber für mich ist der wahre Vorteil folgender:

Zusammenarbeit in identischen Umgebungen (ohne Rücksicht auf die Windows- und Linux/Mac-Sachen). Vor Gemfile.lock konnte der nächste Typ, der das Projekt installierte, alle möglichen verwirrenden Fehler sehen und sich selbst die Schuld geben, aber er war einfach dieser glückliche Kerl, der die nächste Version von Super Gem bekam und bestehende Abhängigkeiten brach.

Schlimmer noch, dies geschah auf den Servern, die eine ungetestete Version erhielten, es sei denn, sie wurden diszipliniert und installierten die genaue Version. Gemfile.lock macht dies explizit und teilt Ihnen explizit mit, dass Ihre Versionen unterschiedlich sind.

Hinweis: Denken Sie daran, Dinge als :development und :test zu gruppieren

Die Bundler-Dokumentation geht auch auf diese Frage ein:

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

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

Siehe the section called “Einchecken Ihres Codes in die Versionskontrolle”:

Nachdem Sie Ihre Anwendung eine Weile entwickelt haben, checken Sie die Anwendung zusammen mit dem Snapshot Gemfile und Gemfile.lock ein. Jetzt enthält Ihr Repository eine Aufzeichnung der genauen Versionen aller Edelsteine, die Sie das letzte Mal verwendet haben, als Sie sicher waren, dass die Anwendung funktioniert hat. Denken Sie daran, dass Ihr Gemfile zwar nur drei Gems auflistet (mit unterschiedlicher Versionsstrenge), Ihre Anwendung jedoch von Dutzenden von Gems abhängt, wenn Sie alle impliziten Anforderungen der Gems berücksichtigen, von denen Sie abhängen.

Das ist wichtig: Die Gemfile.lock macht Ihre Anwendung zu einem einzigen Paket aus Ihrem eigenen Code und dem Code eines Drittanbieters, den sie zuletzt ausgeführt hat, als Sie sicher waren, dass alles funktioniert hat. Die Angabe genauer Versionen des Codes von Drittanbietern, von dem Sie in Ihrer Gemfile abhängig sind, würde nicht die gleiche Garantie bieten, da Gems normalerweise eine Reihe von Versionen für ihre Abhängigkeiten deklarieren.

Wenn Sie das nächste Mal die Bundle-Installation auf demselben Computer ausführen, erkennt Bundler, dass bereits alle erforderlichen Abhängigkeiten vorhanden sind, und überspringt den Installationsvorgang.

Checken Sie nicht das .bundle-Verzeichnis oder die darin enthaltenen Dateien ein. Diese Dateien sind für jeden einzelnen Computer spezifisch und werden verwendet, um Installationsoptionen zwischen Ausführungen des Bundle-Installationsbefehls beizubehalten.

Wenn Sie Bundle Pack ausgeführt haben, werden die Edelsteine ​​(jedoch nicht die Git-Edelsteine), die für Ihr Bundle erforderlich sind, in den Anbieter/Cache heruntergeladen. Bundler kann ohne Verbindung zum Internet (oder zum RubyGems-Server) ausgeführt werden, wenn alle benötigten Edelsteine ​​​​in diesem Ordner vorhanden und in Ihre Quellcodeverwaltung eingecheckt sind. Dies ist ein optionaler Schritt und wird aufgrund der zunehmenden Größe Ihres Versionsverwaltungs-Repositorys nicht empfohlen.

Sollte Gemfilelock in gitignore enthalten sein
Petrus-Repo

Einfache Antwort im Jahr 2021:
Gemfile.lock sollte auch für Rubygems in der Versionskontrolle sein. Die akzeptierte Antwort ist jetzt 11 Jahre alt.

Einige Argumente hier (herausgesucht aus Kommentaren):

@josevalim https://github.com/heartcombo/devise/pull/3147#issuecomment-52193788

Die Gemfile.lock sollte im Repository bleiben, da Mitwirkende und Entwickler in der Lage sein sollten, das Projekt zu forken und es mit Versionen auszuführen, die garantiert funktionieren.

@raffaelfranca https://github.com/rails/rails/pull/18951#issuecomment-74888396

Ich halte es nicht für eine gute Idee, die Sperrdatei auch für Plugins zu ignorieren.

Dies bedeutet, dass eine „git clone; bundle; rake test“-Sequenz keine Garantie dafür ist, dass sie bestanden wird, da eine Ihrer Dutzenden von Abhängigkeiten aktualisiert wurde und Ihren Code beschädigt hat. Wie @chancancode sagte, ist es auch viel schwieriger zu halbieren.

Auch Rails hat Gemfile.lock in git:

1646172492 723 Sollte Gemfilelock in gitignore enthalten sein
gröber

Kein Gemfile.lock bedeutet:

  • Neue Mitwirkende können keine Tests durchführen, weil seltsame Dinge fehlschlagen, also werden sie nichts beitragen oder erfolglose PRs bekommen … schlechte erste Erfahrung.
  • Sie können nicht zu einem ein Jahr alten Projekt zurückkehren und einen Fehler beheben, ohne das Projekt aktualisieren/neu schreiben zu müssen, wenn Sie Ihre lokale Gemfile.lock verloren haben

-> Überprüfen Sie immer Gemfile.lock, lassen Sie Travis es löschen, wenn Sie besonders gründlich sein wollen https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

905360cookie-checkSollte Gemfile.lock in .gitignore enthalten sein?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy