Haruskah Gemfile.lock dimasukkan dalam .gitignore?


501

Saya semacam baru ke bundler dan file yang dihasilkannya. Saya memiliki salinan repo git dari GitHub yang sedang dikontribusikan oleh banyak orang, jadi saya terkejut menemukan bahwa bundler membuat file yang tidak ada dalam repo dan tidak ada dalam .gitignoredaftar.

Karena saya telah memotongnya, saya tahu menambahkannya ke repo tidak akan merusak apa pun untuk repo utama, tetapi jika saya melakukan permintaan tarik, apakah itu akan menimbulkan masalah?

Haruskah Gemfile.lockdimasukkan dalam repositori?



2
Jika Anda menemukan jalan di sini karena Anda memiliki Linux dan kotak Windows yang berbagi repo yang sama, lihat jawaban Joe Yang. Pada saat saya menulis ini peringkat ketiga. Lihat juga stackoverflow.com/questions/14034561/...
Peter Berg

Jawaban:


549

Dengan anggapan Anda tidak sedang menulis rubygem, Gemfile.lock harus ada di repositori Anda. Ini digunakan sebagai snapshot dari semua permata yang diperlukan dan dependensinya. Dengan cara ini bundler tidak perlu menghitung ulang semua dependensi permata setiap kali Anda menggunakan, dll.

Dari komentar cowboycoded di bawah ini:

Jika Anda bekerja pada permata, maka JANGAN memeriksa di Gemfile Anda. Jika Anda bekerja pada aplikasi Rails, maka LAKUKAN memeriksa Gemfile.lock Anda.

Inilah artikel yang bagus menjelaskan apa file kunci itu.


88
Tergantung pada apa yang sedang Anda kerjakan. Jika Anda bekerja pada permata, maka JANGAN memeriksa di Gemfile Anda. Jika Anda bekerja pada aplikasi Rails, maka LAKUKAN memeriksa Gemfile.lock Anda. Info lebih lanjut di sini - yehudakatz.com/2010/12/16/…
johnmcaliley

Terima kasih untuk artikel bermanfaat.
ashisrai_

1
Anda harus meletakkan apa yang dikatakan kode koboi dalam jawaban Anda: permata.
aarona

Tautan artikel membutuhkan href baru.
Ross

4
Tolong jangan lakukan itu !! Simpan Gemfile Anda. Buka di mana! Seperti yang dikatakan di sini dan di sini .
Ricardo Ruwer

50

Masalah sebenarnya terjadi ketika Anda bekerja pada aplikasi Rails open-source yang perlu memiliki adaptor database yang dapat dikonfigurasi. Saya sedang mengembangkan cabang Rails 3 dari Fat Free CRM. Preferensi saya adalah postgres, tetapi kami ingin database default menjadi mysql2.

Dalam hal ini, Gemfile.lockmasih perlu diperiksa dengan set permata default, tetapi saya perlu mengabaikan perubahan yang telah saya buat di mesin saya. Untuk mencapai ini, saya menjalankan:

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

dan untuk membalikkan:

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

Ini juga berguna untuk memasukkan sesuatu seperti kode berikut di blog Anda Gemfile. Ini memuat permata adaptor basis data yang sesuai, berdasarkan database.yml Anda.

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

Saya tidak bisa mengatakan apakah ini merupakan praktik terbaik yang mapan atau tidak, tetapi ini berhasil bagi saya.


2
Info yang sangat berguna ... tidak yakin mengapa Anda hanya mendapat 3 poin dan jawaban yang kurang bermanfaat memiliki 50-beberapa poin. Oh, ya, lihat datestamps. (Salah satu kegagalan besar SO adalah manfaat tidak proporsional yang bertambah untuk menjawab segera setelah pertanyaan diajukan.)
iconoclast

1
@iconoclast: Saya sangat senang Anda memposting apa yang Anda lakukan. Saya pikir banyak orang yang datang ke posting ini, termasuk saya sendiri, "dibutakan" oleh judul pertanyaan. Saya menyadari sekarang bahwa jawaban saya hanya menjawab penggunaan kasus tertentu dan belum tentu jawaban yang tepat untuk pertanyaan ini. Saya akan berusaha memperbaruinya dalam waktu dekat. Yang mengatakan, OP seharusnya tidak menandai jawaban saya sebagai benar jika tidak memenuhi kebutuhannya.
rwilliams

34

Rekan kerja saya dan saya memiliki Gemfile.lock yang berbeda, karena kami menggunakan platform yang berbeda, windows dan mac, dan server kami adalah linux.

Kami memutuskan untuk menghapus Gemfile.lock di repo dan membuat Gemfile.lock.server di git repo, seperti database.yml. Kemudian sebelum menyebarkannya di server, kami menyalin Gemfile.lock.server ke Gemfile.lock di server menggunakan cap deploy hook


5
Saya memiliki aplikasi yang saya kembangkan di OSX dan kemudian harus digunakan di server Windows. Melacak Gemfile.lock dengan git terbukti merupakan ide yang buruk sehingga ia masuk dalam file .gitignore saya. Banyak permata memerlukan versi yang berbeda untuk lingkungan yang berbeda. Idealnya Anda harus menghindari pernah berada dalam situasi ini, tetapi saya tidak punya pilihan (sialan departemen IT Anda!)
brad

11

Setuju dengan r-dub, simpan di kontrol sumber, tetapi bagi saya, manfaat sebenarnya adalah ini:

kolaborasi dalam lingkungan yang identik (mengabaikan windoh dan hal-hal linux / mac). Sebelum Gemfile.lock, dude berikutnya untuk menginstal proyek mungkin melihat semua jenis kesalahan yang membingungkan, menyalahkan dirinya sendiri, tapi dia hanya orang yang beruntung mendapatkan versi permata super berikutnya, memecahkan dependensi yang ada.

Lebih buruk lagi, ini terjadi di server, mendapatkan versi yang belum diuji kecuali didisiplinkan dan menginstal versi yang tepat. Gemfile.lock membuat ini eksplisit, dan itu akan secara eksplisit memberi tahu Anda bahwa versi Anda berbeda.

Catatan: ingat untuk mengelompokkan hal-hal, seperti: pengembangan dan: tes


11

Dokumen Bundler menjawab pertanyaan ini juga:

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

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

Lihat bagian yang disebut "Memeriksa Kode Anda ke dalam Kontrol Versi":

Setelah mengembangkan aplikasi Anda untuk sementara waktu, periksa aplikasi bersama dengan snapshot Gemfile dan Gemfile.lock. Sekarang, repositori Anda memiliki catatan versi yang tepat dari semua permata yang Anda gunakan terakhir kali Anda tahu pasti bahwa aplikasi itu berfungsi. Ingatlah bahwa walaupun Gemfile Anda mencantumkan hanya tiga permata (dengan berbagai tingkat keketatan versi), aplikasi Anda bergantung pada lusinan permata, setelah Anda mempertimbangkan semua persyaratan implisit dari permata yang Anda andalkan.

Ini penting: Gemfile.lock membuat aplikasi Anda satu paket dari kode Anda sendiri dan kode pihak ketiga yang dijalankan saat terakhir Anda tahu pasti semuanya bekerja. Menentukan versi pasti dari kode pihak ketiga yang Anda andalkan di Gemfile Anda tidak akan memberikan jaminan yang sama, karena permata biasanya mendeklarasikan serangkaian versi untuk dependensi mereka.

Lain kali Anda menjalankan bundel menginstal pada mesin yang sama, bundler akan melihat bahwa itu sudah memiliki semua dependensi yang Anda butuhkan, dan melewati proses instalasi.

Jangan periksa di direktori .bundle, atau file apa pun di dalamnya. File-file itu khusus untuk setiap mesin tertentu, dan digunakan untuk bertahan opsi instalasi antara menjalankan perintah instalasi bundel.

Jika Anda telah menjalankan paket bundel, permata (meskipun bukan permata git) yang diperlukan oleh bundel Anda akan diunduh ke vendor / cache. Bundler dapat berjalan tanpa terhubung ke internet (atau server RubyGems) jika semua permata yang Anda butuhkan ada di folder itu dan masuk ke kontrol sumber Anda. Ini adalah langkah opsional, dan tidak disarankan, karena peningkatan ukuran repositori kontrol sumber Anda.


4

Tidak ada Gemfile.lock berarti:

  • kontributor baru tidak dapat menjalankan tes karena hal-hal aneh gagal, sehingga mereka tidak akan berkontribusi atau gagal PR ... pengalaman pertama yang buruk.
  • Anda tidak dapat kembali ke proyek tahun kapak dan memperbaiki bug tanpa harus memperbarui / menulis ulang proyek jika Anda kehilangan Gemfile.lock lokal Anda

-> Selalu periksa di Gemfile.lock, buat travis hapus jika Anda ingin ekstra teliti https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3

Sedikit terlambat ke pesta, tetapi jawaban masih butuh waktu dan orang asing membaca untuk memahami masalah ini. Jadi saya ingin meringkas apa yang saya ketahui tentang Gemfile.lock.

Saat Anda membangun Aplikasi Rails, Anda menggunakan versi permata tertentu di mesin lokal Anda. Jika Anda ingin menghindari kesalahan dalam mode produksi dan cabang lainnya, Anda harus menggunakan satu file Gemfile.lock itu di mana-mana dan memberi tahu bundler bundleuntuk membangun kembali permata setiap kali ada perubahan.

Jika Gemfile.locktelah berubah pada mesin produksi Anda dan Git tidak membiarkan Anda git pull, Anda harus menulis git reset --harduntuk menghindari perubahan file dan menulis git pulllagi.


Jika file berubah secara otomatis, misalnya dengan proses build, itu adalah tanda yang jelas bahwa itu tidak boleh ditambahkan ke kontrol versi.
Thomas S.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.