Moet Gemfile.lock worden opgenomen in .gitignore?

Ik ben een beetje nieuw voor Bundler en de bestanden die het genereert. Ik heb een kopie van een git-repo van GitHub waar veel mensen aan hebben bijgedragen, dus ik was verrast om te ontdekken dat de bundelaar een bestand heeft gemaakt dat niet in de repo bestond en niet in de .gitignorelijst.

Sinds ik het heb geforkt, weet ik dat het toevoegen aan de repo niets zal verbreken voor de hoofdrepo, maar als ik een pull-verzoek doe, zal dit dan een probleem veroorzaken?

Moet Gemfile.lockworden opgenomen in de repository?


Antwoord 1, autoriteit 100%

Ervan uitgaande dat je geen rubygem schrijft, zou Gemfile.lock in je repository moeten staan. Het wordt gebruikt als een momentopname van al uw vereiste edelstenen en hun afhankelijkheden. Op deze manier hoeft de bundelaar niet alle edelsteenafhankelijkheden opnieuw te berekenen elke keer dat je het implementeert, enz.

Uit de opmerking van cowboycoded hieronder:

Als je aan een edelsteen werkt, check dan NIET je Gemfile.lock in. Als je aan een Rails-app werkt, check dan DOEN je Gemfile.lock in.

Hier is een mooi artikeluitleggen wat het vergrendelingsbestand is.


Antwoord 2, autoriteit 9%

Het echte probleem doet zich voor wanneer u werkt aan een open-source Rails-app die een configureerbare database-adapter nodig heeft. Ik ontwikkel de Rails 3-tak van Fat Free CRM.
Mijn voorkeur gaat uit naar postgres, maar we willen dat de standaarddatabase mysql2 is.

In dit geval moet Gemfile.locknog steeds worden ingecheckt met de standaard set edelstenen, maar ik moet de wijzigingen negeren die ik erin heb aangebracht op mijn computer. Om dit te bereiken, voer ik:

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

en om te keren:

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

Het is ook handig om zoiets als de volgende code op te nemen in je Gemfile. Dit laadt het juiste juweel van de database-adapter, gebaseerd op uw 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]
# -----------------------------------------------------------------------------

Ik kan niet zeggen of dit een gevestigde best practice is of niet, maar het werkt goed voor mij.


Antwoord 3, autoriteit 6%

Mijn collega’s en ik hebben verschillende Gemfile.lock, omdat we verschillende platforms gebruiken, Windows en Mac, en onze server is Linux.

We besluiten Gemfile.lock in repo te verwijderen en Gemfile.lock.server in git repo te maken, net als database.yml. Voordat we het op de server implementeren, kopiëren we Gemfile.lock.server naar Gemfile.lock op de server met behulp van cap deploy hook


Antwoord 4, autoriteit 2%

Akkoord met r-dub, houd het in bronbeheer, maar voor mij is het echte voordeel dit:

samenwerking in identieke omgevingen(zonder rekening te houden met de windohs en linux/mac-dingen). Vóór Gemfile.lock zag de volgende gast die het project installeerde misschien allerlei verwarrende fouten en gaf hij zichzelf de schuld, maar hij was gewoon die gelukkige die de volgende versie van super gem kreeg en bestaande afhankelijkheden doorbrak.

Erger nog, dit gebeurde op de servers en kreeg een niet-geteste versie, tenzij gedisciplineerd en installeer de exacte versie. Gemfile.lock maakt dit expliciet, en het zal je expliciet vertellen dat je versies anders zijn.

Opmerking: vergeet niet om dingen te groeperen, zoals :ontwikkeling en :test


Antwoord 5, autoriteit 2%

De Bundler-documenten behandelen deze vraag ook:

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

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

Zie de sectie genaamd “Uw code controleren in versiebeheer”:

Nadat u uw applicatie een tijdje heeft ontwikkeld, gaat u naar de
applicatie samen met de Gemfile en Gemfile.lock snapshot. Nutsvoorzieningen,
je repository heeft een overzicht van de exacte versies van alle edelstenen
die u de laatste keer hebt gebruikt u zeker weet dat de toepassing
werkte. Houd er rekening mee dat terwijl uw Gemfile slechts drie edelstenen vermeldt
(met verschillende gradaties van versie-strengheid), hangt uw toepassing af
op tientallen edelstenen, als je eenmaal rekening houdt met alle
impliciete vereisten van de edelstenen waarvan u afhankelijk bent.

Dit is belangrijk: de Gemfile.lock maakt je applicatie een single
pakket van zowel uw eigen code als de code van derden die het de laatste keer heeft uitgevoerd
tijd weet je zeker dat alles werkte. Exact opgeven
versies van de code van derden waarvan u afhankelijk bent in uw Gemfile zouden:
bieden niet dezelfde garantie, omdat edelstenen meestal een bereik aangeven
van versies voor hun afhankelijkheden.

De volgende keer dat u de bundelinstallatie op dezelfde computer uitvoert, zal Bundler
zie dat het al alle afhankelijkheden heeft die je nodig hebt, en sla de
installatieproces.

Kijk niet in de .bundle-map, of een van de bestanden erin.
Die bestanden zijn specifiek voor elke specifieke machine en worden gebruikt om:
persistente installatie-opties tussen runs van de bundelinstallatie
commando.

Als je een bundelpakket hebt gebruikt, worden de edelstenen (hoewel niet de git-edelstenen)
vereist door uw bundel worden gedownload naar leverancier/cache. bundelaar
kan draaien zonder verbinding te maken met internet (of de RubyGems-server) als
alle edelstenen die je nodig hebt zijn aanwezig in die map en ingecheckt bij
uw bronbeheer. Dit is een optionele stap, en niet aanbevolen,
vanwege de toename in omvang van uw bronbeheerrepository.


Antwoord 6

Geen Gemfile.lock betekent:

  • nieuwe bijdragers kunnen geen tests uitvoeren omdat rare dingen mislukken, dus ze zullen niet bijdragen of falende PR’s krijgen … slechte eerste ervaring.
  • je kunt niet teruggaan naar een x jaar oud project en een bug repareren zonder het project te updaten/herschrijven als je je lokale Gemfile.lock kwijt bent

– & GT; Controleer altijd in gemfile.lock, maak Travis het als je extra grondig wilt zijn https://grosser.it/2015/08/14/Check-in-your-gemfile-lock/

Other episodes