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

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?

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.

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.

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

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

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.

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/

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.