Gemfile.lock을 .gitignore에 포함해야 합니까?

Gemfile.lock을 .gitignore에 포함해야 합니까?

저는 번들러와 그것이 생성하는 파일에 익숙하지 않습니다., . GitHub에했다는 것을 ..gitignore리스트에합니다.

포크를 했으니 레포에 추가해도 메인 레포는 깨지지 않을 것으로 알고 있습니다만, 풀 요청을 하면 문제가 발생할까요?

야 합니다.Gemfile.lock저장소에 포함됩니까?

Trinitron X에서 2022년 업데이트.

2021년으로 빠르게 전환하고 이제 Bundler 문서 [웹 아카이브]에서 Gemfile.lock을 보석 안에 커밋하라고 합니다.¯_(ツ)_/¯ 프로젝트를 시작할 때 개발자들에게 이해가 되고 사용하기 쉽다고 생각합니다.그러나 이제 CI 작업에서는 다른 버전에 대해 테스트하기 위해 모든 Gemfile.lock 파일을 제거해야 합니다.

레거시 응답 ~ 2010

루비젬을 쓰지 않는다고 가정하면 Gemfile.lock은 당신의 저장소에 있을 것입니다.필요한 모든 보석과 그 종속성의 스냅샷으로 사용됩니다.이러한 방식으로 번들러는 배포할 때마다 모든 보석 종속성을 다시 계산할 필요가 없습니다.

아래 카우보이코드의 코멘트에서:

보석 작업을 하는 경우에는 Gemfile.lock을 체크인하지 마십시오.레일즈 앱에서 작업 중이라면 Gemfile.lock을 체크인하십시오.

여기 잠금 파일이 무엇인지 설명하는 멋진 기사가 있습니다.

실제 문제는 구성 가능한 데이터베이스 어댑터가 필요한 오픈 소스 Rails 앱에서 작업할 때 발생합니다.저는 Fat Free CRM의 Rails 3 지점을 개발하고 있습니다.제가 선호하는 것은 postgres이지만, 기본 데이터베이스는 mysql2입니다.

이경에는우,,Gemfile.lock여전히 기본 보석 세트로 체크인해야 하지만 컴퓨터에서 변경한 사항은 무시해야 합니다.위해 저는을 실행합니다.

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

반대 방향:

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

과 같은 코드를 포함하는 것도 합니다.Gemfile데이터베이스입니다.yml에 따라 적절한 데이터베이스 어댑터 gem이 로드됩니다.

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

이것이 확립된 모범 사례인지 아닌지는 말할 수 없지만, 저에게는 잘 맞습니다.

제 동료들과 저는 서로 다른 플랫폼인 윈도우와 맥을 사용하고 서버가 리눅스이기 때문에 다른 Gemfile.lock을 가지고 있습니다.

우리는 repo에서 Gemfile.lock을 제거하고 database.yml처럼 gemfile.lock.server를 gitrepo로 만들기로 결정했습니다.그런 다음 서버에 배포하기 전에 캡 배포 후크를 사용하여 Gemfile.lock.server를 서버의 Gemfile.lock에 복사합니다.

r-dub에 동의합니다. 소스 제어로 유지합니다. 하지만 저에게 진정한 이점은 다음과 같습니다.

동일한 환경에서의 협업(윈도 및 리눅스/mac 등 포함).Gemfile.lock 이전에 프로젝트를 설치한 다음 사람은 자신을 탓하며 모든 종류의 혼란스러운 오류를 볼 수 있었지만, 그는 기존의 종속성을 깨고 슈퍼 보석의 다음 버전을 얻은 행운의 사람이었습니다.

더 나쁜 것은, 서버에서 이런 일이 발생하여, 규율이 적용되지 않는 한 테스트되지 않은 버전을 얻고 정확한 버전을 설치하는 것입니다.Gemfile.lock은 이것을 명시적으로 만들고, 그것은 당신의 버전이 다르다는 것을 명시적으로 알려줄 것입니다.

참고: 항목을 :development 및 :test와 같이 그룹화해야 합니다.

2021년의 간단한 답변: Gemfile.lock은 Rubygems에 대해서도 버전 제어에 있어야 합니다.현재 받아들여진 답은 11살입니다.

여기서 몇 가지 추론(댓글에서 체리를 골라냄):

@josevalim https://github.com/heartcombo/devise/pull/3147#issuecomment-52193788

Gemfile.lock은 기여자와 개발자가 프로젝트를 포크하고 작동이 보장된 버전을 사용하여 실행할 수 있어야 하므로 저장소에 남아 있어야 합니다.

@freakfranka https://github.com/rails/rails/pull/18951#issuecomment-74888396

플러그인에 대해서도 잠금 파일을 무시하는 것은 좋은 생각이 아니라고 생각합니다.

즉, 수십 개의 종속성 중 하나가 업그레이드되어 코드가 손상되었기 때문에 "비트 클론, 번들, 레이크 테스트" 시퀀스가 통과할 것으로 보장되지 않습니다.또한, @chancode가 말했듯이, 이것은 이등분하는 것을 훨씬 더 어렵게 만듭니다.

또한 Rails에는 Gemfile.lockingit이 있습니다.

• https://github.com/rails/rails/commit/0ad6d27643057f2eccfe8351409a75a6d1bbb9d0

번들러 문서에서는 이 문제도 다룹니다.

원본: http://gembundler.com/v1.3/rationale.html

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

"버전 제어로 코드 체크인" 섹션을 참조하십시오.

잠시 동안 애플리케이션을 개발한 후 Gemfile 및 Gemfile.lock 스냅샷과 함께 애플리케이션을 체크인합니다.이제 저장소에는 응용 프로그램이 제대로 작동했는지 마지막으로 확인했을 때 사용한 모든 보석의 정확한 버전에 대한 기록이 있습니다.Gem 파일에는 세 개의 보석만 나열되어 있지만(버전의 엄격성 정도가 다양함), 사용자가 의존하는 보석의 모든 암묵적인 요구 사항을 고려하면 응용 프로그램은 수십 개의 보석에 의존합니다.

이것은 중요합니다. Gemfile.lock은 응용 프로그램을 사용자 자신의 코드와 마지막으로 모든 것이 제대로 작동했는지 확인할 때 실행된 타사 코드의 단일 패키지로 만듭니다.Gem 파일에서 의존하는 타사 코드의 정확한 버전을 지정하는 것은 일반적으로 Gem 파일의 종속성에 대한 버전 범위를 선언하기 때문에 동일한 보증을 제공하지 않습니다.

다음에 동일한 시스템에서 번들 설치를 실행할 때 번들러는 필요한 모든 종속성이 이미 있음을 확인하고 설치 프로세스를 건너뜁니다.

.bundle 디렉터리 또는 디렉터리에 있는 파일을 체크인하지 마십시오.이러한 파일은 각 시스템에 고유하며 bundle install 명령 실행 간에 설치 옵션을 유지하는 데 사용됩니다.

번들 팩을 실행한 경우 번들에 필요한 보석(깃 보석은 아니지만)이 벤더/캐시에 다운로드됩니다.필요한 모든 보석이 해당 폴더에 있고 소스 제어에 체크인된 경우 인터넷(또는 RubyGems 서버)에 연결하지 않고 번들러를 실행할 수 있습니다.이 단계는 선택적인 단계이며 소스 제어 저장소의 크기가 증가하기 때문에 권장되지 않습니다.

No Gemfile.lock은 다음을 의미합니다.

• 새로운 기여자들은 이상한 것들이 실패하기 때문에 테스트를 실행할 수 없습니다. 그래서 그들은 기여하거나 실패하는 PR을 받지 못할 것입니다. 첫 경험이 좋지 않습니다.
• 로컬 Gemfile.lock을 분실한 경우 프로젝트를 업데이트/재작성하지 않고는 x년 전 프로젝트로 돌아가서 버그를 수정할 수 없습니다.

-> 항상 Gemfile.lock을 확인하고, 만약 당신이 더 철저하고 싶다면 트래비스가 그것을 삭제하도록 하세요. https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

파티에 조금 늦었지만, 이 문제를 이해하기 위해서는 여전히 시간과 외국어 읽기가 필요했습니다.그래서 저는 Gemfile.lock에 대해 제가 알아낸 것을 요약하고 싶습니다.

레일즈 앱을 만들 때는 로컬 컴퓨터에서 특정 버전의 보석을 사용하고 있습니다.프로덕션 모드와 다른 분기에서 오류를 방지하려면 하나의 Gemfile.lock 파일을 모든 곳에 사용하고 번들러에게 다음을 지시해야 합니다.bundle매번 바뀔 때마다 보석을 재건하는 것에 대해야.

한다면Gemfile.lock당신의 생산 기계가 바뀌었고 Git은 당신을 허락하지 않습니다.git pull당신은 글을 써야 합니다.git reset --hard파일 변경 및 쓰기를 방지하기 위해git pull다시.

여기에 있는 다른 답변은 다음과 같습니다.예, 루비 앱(루비 보석이 아님)에 포함되어야 합니다.Gemfile.lock레포에이를 수행해야 하는 이유에 대해 자세히 알아보려면 다음을 참조하십시오.

각 환경(개발, 테스트, 스테이징, prod...)이 각각 수행하는 작업을 잘못 알고 있었습니다.bundle install그들만의 Gemfile.lock을 만들기 위해.Gemfile.lock에 :test, :prod 등과 같은 그룹화 데이터가 포함되어 있지 않다는 사실을 기반으로 가정했습니다.이 가정은 제가 고통스러운 지역 문제에서 발견했듯이 잘못된 것이었습니다.

더 자세히 조사해보니, 왜 제 젠킨스 체격이 특정 보석을 가져오는 것을 보여주었는지 혼란스러웠습니다.ffakerFWIW)는 성공적으로 실행되었지만 앱이 로드되고 페이커가 필요할 때 파일을 찾을 수 없다고 표시되었습니다. WTF?

조금 더 조사하고 실험한 결과 두 파일이 어떤 역할을 하는지 알 수 있었습니다.

먼저 Gemfile.lock을 사용하여 이 특정 환경에서 사용되지 않는 모든 보석을 가져옵니다.그런 다음 Gemfile을 사용하여 가져온 보석 중 이 환경에서 실제로 사용할 보석을 선택합니다.

따라서 Gemfile.lock을 기반으로 한 첫 번째 단계에서 Gemfile을 가져왔지만 Gemfile의 그룹을 기반으로 한 my:test 환경에는 포함되지 않았습니다.

(내 경우) 해결책은 이사하는 것이었습니다.gem 'ffaker':development group에서 main group으로 모든 env가 사용할 수 있도록 합니다. (또는 :development, :test, 해당하는 경우에만 추가)

언급URL : https://stackoverflow.com/questions/4151495/should-gemfile-lock-be-included-in-gitignore