Gemfile.lock có nên được đưa vào .gitignore không?

Tôi sắp xếp công cụ mới và các tập tin mà nó tạo ra. Tôi có một bản sao của git repo từ GitHub đang được nhiều người đóng góp nên tôi rất ngạc nhiên khi thấy rằng trình tạo gói đó đã tạo một tệp không tồn tại trong repo và không có trong .gitignoredanh sách.

Vì tôi đã rẽ nhánh nó, tôi biết thêm nó vào repo sẽ không phá vỡ bất cứ điều gì cho repo chính, nhưng nếu tôi thực hiện một yêu cầu kéo, nó có gây ra vấn đề gì không?

Có nên Gemfile.lockđưa vào kho?

Giả sử bạn không viết rubygem, Gemfile.lock sẽ có trong kho lưu trữ của bạn. Nó được sử dụng như một ảnh chụp nhanh tất cả các loại đá quý cần thiết của bạn và các phụ thuộc của chúng. Cách này, trình đóng gói không phải tính toán lại tất cả các phụ thuộc đá quý mỗi khi bạn triển khai, v.v.

Từ bình luận của cowboycoding dưới đây:

Nếu bạn đang làm việc với đá quý, thì KHÔNG nên kiểm tra Gemfile.lock của bạn. Nếu bạn đang làm việc trên ứng dụng Rails, thì hãy kiểm tra Gemfile.lock của bạn.

Đây là một bài viết tốt giải thích các tập tin khóa là gì.

Vấn đề thực sự xảy ra khi bạn đang làm việc trên ứng dụng Rails nguồn mở cần phải có bộ điều hợp cơ sở dữ liệu có thể định cấu hình. Tôi đang phát triển nhánh Rails 3 của Fat Free CRM. Sở thích của tôi là postgres, nhưng chúng tôi muốn cơ sở dữ liệu mặc định là mysql2.

Trong trường hợp này, Gemfile.lockvẫn cần phải kiểm tra với bộ đá quý mặc định, nhưng tôi cần bỏ qua những thay đổi mà tôi đã thực hiện với nó trên máy của mình. Để thực hiện điều này, tôi chạy:

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

và để đảo ngược:

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

Nó cũng hữu ích để bao gồm một cái gì đó như mã sau đây trong của bạn Gemfile. Điều này tải gem bộ điều hợp cơ sở dữ liệu thích hợp, dựa trên cơ sở dữ liệu của bạn.

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

Tôi không thể nói nếu đây là một thực tiễn tốt nhất được thiết lập hay không, nhưng nó hoạt động tốt với tôi.

Đồng nghiệp của tôi và tôi có Gemfile.lock khác nhau, vì chúng tôi sử dụng các nền tảng, windows và mac khác nhau và máy chủ của chúng tôi là linux.

Chúng tôi quyết định xóa Gemfile.lock trong repo và tạo Gemfile.lock.server trong git repo, giống như cơ sở dữ liệu.yml. Sau đó, trước khi triển khai nó trên máy chủ, chúng tôi sao chép Gemfile.lock.server sang Gemfile.lock trên máy chủ bằng cách sử dụng hook triển khai cap

Đồng ý với r-dub, giữ nó trong kiểm soát nguồn, nhưng với tôi, lợi ích thực sự là:

cộng tác trong các môi trường giống hệt nhau (không quan tâm đến Windohs và công cụ linux / mac). Trước Gemfile.lock, anh chàng tiếp theo cài đặt dự án có thể thấy tất cả các loại lỗi khó hiểu, tự trách mình, nhưng anh ta chỉ là anh chàng may mắn nhận được phiên bản siêu đá quý tiếp theo, phá vỡ sự phụ thuộc hiện có.

Tồi tệ hơn, điều này đã xảy ra trên các máy chủ, nhận phiên bản chưa được kiểm tra trừ khi bị kỷ luật và cài đặt phiên bản chính xác. Gemfile.lock làm cho điều này rõ ràng và nó sẽ cho bạn biết rõ ràng rằng các phiên bản của bạn là khác nhau.

Lưu ý: hãy nhớ nhóm nội dung, như: phát triển và: kiểm tra

Các tài liệu Bundler cũng giải quyết câu hỏi này:

NGUỒN GỐC: http://gembundler.com/v1.3/rationale.html

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

Xem phần "Kiểm tra mã của bạn vào kiểm soát phiên bản":

Sau khi phát triển ứng dụng của bạn một lúc, hãy kiểm tra ứng dụng cùng với ảnh chụp nhanh Gemfile và Gemfile.lock. Bây giờ, kho lưu trữ của bạn có bản ghi các phiên bản chính xác của tất cả các loại đá quý mà bạn đã sử dụng lần cuối cùng mà bạn biết chắc chắn rằng ứng dụng đã hoạt động. Hãy nhớ rằng trong khi Gemfile của bạn chỉ liệt kê ba loại đá quý (với mức độ nghiêm ngặt của phiên bản khác nhau), ứng dụng của bạn phụ thuộc vào hàng tá đá quý, một khi bạn xem xét tất cả các yêu cầu ngầm của đá quý mà bạn phụ thuộc.

Điều này rất quan trọng: Gemfile.lock làm cho ứng dụng của bạn trở thành một gói duy nhất gồm cả mã của riêng bạn và mã của bên thứ ba mà nó đã chạy lần cuối cùng bạn biết chắc chắn rằng mọi thứ đều hoạt động. Việc chỉ định các phiên bản chính xác của mã bên thứ ba mà bạn phụ thuộc trong Gemfile của bạn sẽ không cung cấp cùng một sự đảm bảo, vì đá quý thường khai báo một loạt các phiên bản cho các phụ thuộc của chúng.

Lần tới khi bạn chạy gói cài đặt trên cùng một máy, trình biên dịch sẽ thấy rằng nó đã có tất cả các phụ thuộc bạn cần và bỏ qua quá trình cài đặt.

Không kiểm tra trong thư mục .bundle hoặc bất kỳ tệp nào trong đó. Các tệp này dành riêng cho từng máy cụ thể và được sử dụng để duy trì các tùy chọn cài đặt giữa các lần chạy lệnh cài đặt gói.

Nếu bạn đã chạy gói gói, đá quý (mặc dù không phải đá quý git) mà gói của bạn yêu cầu sẽ được tải xuống nhà cung cấp / bộ đệm. Bundler có thể chạy mà không cần kết nối với internet (hoặc máy chủ RubyGems) nếu tất cả các loại đá quý bạn cần có trong thư mục đó và được đăng nhập vào kiểm soát nguồn của bạn. Đây là một bước tùy chọn và không được khuyến nghị do sự gia tăng kích thước của kho lưu trữ kiểm soát nguồn của bạn.

Không có Gemfile.lock có nghĩa là:

• những người đóng góp mới không thể chạy thử nghiệm vì những điều kỳ lạ thất bại, vì vậy họ sẽ không đóng góp hoặc bị PR thất bại ... trải nghiệm đầu tiên tồi tệ.
• bạn không thể quay lại dự án cũ rìu và sửa lỗi mà không phải cập nhật / viết lại dự án nếu bạn mất Gemfile.lock cục bộ

-> Luôn kiểm tra Gemfile.lock, hãy xóa travis nếu bạn muốn thêm kỹ lưỡng https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

Đến bữa tiệc muộn một chút, nhưng câu trả lời vẫn khiến tôi mất thời gian và đọc nước ngoài để hiểu vấn đề này. Vì vậy, tôi muốn tóm tắt những gì tôi đã tìm hiểu về Gemfile.lock.

Khi bạn đang xây dựng Ứng dụng Rails, bạn đang sử dụng một số phiên bản đá quý nhất định trong máy cục bộ của mình. Nếu bạn muốn tránh lỗi trong chế độ sản xuất và các nhánh khác, bạn phải sử dụng một tệp Gemfile.lock đó ở mọi nơi và báo cho trình đóng gói để bundlexây dựng lại đá quý mỗi khi nó thay đổi.

Nếu Gemfile.lockđã thay đổi trên máy sản xuất của bạn và Git không cho phép bạn git pull, bạn nên viết git reset --hardđể tránh thay đổi tệp đó và viết git pulllại.