Czy Gemfile.lock powinien być zawarty w .gitignore?


501

Jestem trochę nowy w pakiecie i generuje pliki. Mam kopię repozytorium git z GitHub, do którego wielu ludzi przyczynia się, więc zdziwiłem się, widząc, że bundler utworzył plik, który nie istniał w repozytorium i nie był na .gitignoreliście.

Od kiedy go rozwidliłem, wiem, że dodanie go do repozytorium nic nie zepsuje dla repozytorium głównego, ale jeśli wykonam żądanie ściągnięcia, czy spowoduje to problem?

Czy powinien Gemfile.lockzostać uwzględniony w repozytorium?



2
Jeśli znalazłeś swoją drogę tutaj, ponieważ Linux i Windows mają te same repozytorium, zobacz odpowiedź Joe Yang. W chwili pisania tego tekstu zajmuje trzecie miejsce. Zobacz także stackoverflow.com/questions/14034561/...
Peter Berg,

Odpowiedzi:


549

Zakładając, że nie piszesz rubygem, Gemfile.lock powinien znajdować się w twoim repozytorium. Jest używany jako migawka wszystkich wymaganych klejnotów i ich zależności. W ten sposób pakiet nie musi ponownie obliczać wszystkich zależności klejnotów przy każdym wdrożeniu itp.

Z komentarza cowboycoded poniżej:

Jeśli pracujesz nad klejnotem, NIE sprawdzaj w Gemfile.lock. Jeśli pracujesz nad aplikacją Rails, to sprawdź w Gemfile.lock.

Oto fajny artykuł wyjaśniający, czym jest plik blokady.


88
Zależy od tego nad czym pracujesz. Jeśli pracujesz nad klejnotem, NIE sprawdzaj w Gemfile.lock. Jeśli pracujesz nad aplikacją Rails, to sprawdź w Gemfile.lock. Więcej informacji tutaj - yehudakatz.com/2010/12/16/…
johnmcaliley

Dziękujemy za pomocny artykuł.
ashisrai_

1
powinieneś umieścić to, co powiedział kowboj, w swojej odpowiedzi na temat: klejnotów.
aarona

Link do artykułu wymaga nowego href.
Ross

4
Proszę nie rób tego !! Trzymaj Gemfile.lock tam, gdzie jest! Jak powiedziane tu i tutaj .
Ricardo Ruwer

50

Prawdziwy problem występuje, gdy pracujesz nad aplikacją Railsową typu open source, która musi mieć konfigurowalny adapter bazy danych. Rozwijam gałąź Rails 3 Fat Free CRM. Moje preferencje to postgres, ale chcemy, aby domyślną bazą danych była mysql2.

W takim przypadku Gemfile.locknadal muszę być zalogowany za pomocą domyślnego zestawu klejnotów, ale muszę zignorować zmiany, które wprowadziłem na moim komputerze. Aby to osiągnąć, uruchamiam:

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

i odwrócić:

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

Przydatne jest również dołączenie do kodu czegoś takiego jak poniższy kod Gemfile. Spowoduje to załadowanie odpowiedniego klejnotu adaptera bazy danych na podstawie pliku 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]
# -----------------------------------------------------------------------------

Nie mogę powiedzieć, czy jest to sprawdzona najlepsza praktyka, czy nie, ale działa dobrze dla mnie.


2
Bardzo przydatne informacje ... nie jestem pewien, dlaczego masz tylko 3 punkty, a mniej przydatna odpowiedź ma 50 punktów. O tak, spójrz na znaczniki danych. (Jedną z wielkich porażek SO są nieproporcjonalne korzyści, które wynikają z udzielenia odpowiedzi wkrótce po zadaniu pytania.)
iconoclast

1
@iconoclast: Cieszę się, że opublikowałeś to, co zrobiłeś. Myślę, że wielu ludzi, którzy przychodzą na ten post, łącznie ze mną, jest „zaślepionych” tytułem pytania. Teraz zdaję sobie sprawę, że moja odpowiedź odpowiada tylko na konkretny przypadek użycia i niekoniecznie jest to prawidłowa odpowiedź na to pytanie. W najbliższej przyszłości będę pracować nad aktualizacją. To powiedziawszy, PO nie powinien oznaczyć mojej odpowiedzi jako poprawnej, jeśli nie zaspokoi jego / jej potrzeb.
rwilliams

34

Ja i moi koledzy z pracy mamy różne pliki Gemfile.lock, ponieważ używamy różnych platform, okien i komputerów Mac, a naszym serwerem jest system Linux.

Postanawiamy usunąć Gemfile.lock w repozytorium i utworzyć Gemfile.lock.server w repozytorium git, podobnie jak database.yml. Następnie przed wdrożeniem na serwerze kopiujemy Gemfile.lock.server do Gemfile.lock na serwerze za pomocą haka wdrażania cap


5
Mam aplikację, którą opracowuję w OSX, a następnie muszę ją wdrożyć na serwerze Windows. Śledzenie Gemfile.lock za pomocą git okazało się złym pomysłem, więc trafiło do mojego pliku .gitignore. Wiele klejnotów wymaga różnych wersji dla różnych środowisk. Idealnie powinieneś unikać kiedykolwiek bycia w takiej sytuacji, ale nie miałem wyboru (cholera, dział IT!)
Brad

11

Zgadzając się z r-dubem, zachowaj kontrolę nad źródłami, ale dla mnie prawdziwa korzyść jest taka:

współpraca w identycznych środowiskach (bez względu na windohs i Linux / Mac). Przed Gemfile.lock następny koleś instalujący projekt mógł zobaczyć wszelkiego rodzaju mylące błędy, obwinianie siebie, ale był po prostu tym szczęściarzem, który dostał kolejną wersję super klejnotu, łamiąc istniejące zależności.

Co gorsza, stało się to na serwerach, otrzymywanie wersji nieprzetestowanej, chyba że zdyscyplinowano ją i zainstalowano dokładną wersję. Gemfile.lock wyraźnie to określa i wyraźnie powie ci, że twoje wersje są różne.

Uwaga: pamiętaj o grupowaniu rzeczy, takich jak: programowanie i: test


11

Dokumenty Bundlera odnoszą się również do tego pytania:

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

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

Zobacz sekcję „Sprawdzanie kodu w kontroli wersji”:

Po chwilowym opracowaniu aplikacji sprawdź ją wraz z migawką Gemfile i Gemfile.lock. Teraz Twoje repozytorium ma zapis dokładnych wersji wszystkich klejnotów, których użyłeś ostatnim razem, na pewno wiesz, że aplikacja działała. Pamiętaj, że chociaż Twój Gemfile zawiera tylko trzy klejnoty (o różnym stopniu dokładności wersji), twoja aplikacja zależy od kilkudziesięciu klejnotów, po uwzględnieniu wszystkich ukrytych wymagań klejnotów, od których zależysz.

Jest to ważne: Gemfile.lock sprawia, że ​​aplikacja jest pojedynczym pakietem zarówno własnego kodu, jak i kodu innej firmy, który uruchomił przy ostatnim uruchomieniu, na pewno wiesz, że wszystko działało. Określenie dokładnych wersji kodu innej firmy, na którym zależysz w swoim pliku Gemfile, nie dałoby tej samej gwarancji, ponieważ klejnoty zwykle deklarują zakres wersji dla ich zależności.

Następnym razem, gdy uruchomisz instalację pakietu na tym samym komputerze, program pakujący zobaczy, że ma już wszystkie potrzebne zależności, i pominie proces instalacji.

Nie należy sprawdzać katalogu .bundle ani żadnego z zawartych w nim plików. Pliki te są specyficzne dla poszczególnych komputerów i służą do utrwalenia opcji instalacji między uruchomieniami komendy instalacji pakietu.

Jeśli masz uruchomiony pakiet pakietów, klejnoty (choć nie klejnoty git) wymagane przez Twój pakiet zostaną pobrane do dostawcy / pamięci podręcznej. Bundler może działać bez połączenia z Internetem (lub serwerem RubyGems), jeśli wszystkie potrzebne klejnoty znajdują się w tym folderze i są zalogowane do kontroli źródła. Jest to krok opcjonalny i niezalecany, ze względu na zwiększenie rozmiaru repozytorium kontroli źródła.


4

Brak Gemfile.lock oznacza:

  • nowi współautorzy nie mogą przeprowadzać testów, ponieważ dziwne rzeczy zawodzą, więc nie przyczynią się ani nie zawiodą PR ... złe pierwsze doświadczenie.
  • nie możesz wrócić do projektu z siekierą i naprawić błąd bez konieczności aktualizacji / przepisywania projektu, jeśli straciłeś lokalny plik Gemfile.lock

-> Zawsze sprawdzaj w Gemfile.lock, usuń go, jeśli chcesz być dokładniejszy https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3

Trochę za późno na imprezę, ale odpowiedzi zajęły mi trochę czasu i zagraniczne lektury, aby zrozumieć ten problem. Chcę więc podsumować to, co dowiedziałem się o Gemfile.lock.

Podczas budowania aplikacji Railsowej używasz określonych wersji klejnotów na lokalnej maszynie. Jeśli chcesz uniknąć błędów w trybie produkcyjnym i innych gałęziach, musisz użyć tego jednego pliku Gemfile.lock wszędzie i poinstruować sprzedawcę, aby bundleodbudował klejnoty za każdym razem, gdy się zmieni.

Jeśli Gemfile.lockzmieniło się na twoim komputerze produkcyjnym, a Git na to nie pozwala git pull, powinieneś pisać, git reset --hardaby uniknąć zmiany pliku i pisać git pullponownie.


Jeśli plik zmienia się automatycznie, np. Przez proces kompilacji, jest to wyraźny znak, że nie należy go dodawać do kontroli wersji.
Thomas S.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.