현재 환경을 갱신합니다.

$ bundle update [GEM] [--full-index] [--group=GROUP] [--jobs=NUMBER] [--local]
                      [--quiet] [--source=SOURCE]

Gemfile.lock 안에 기술된 이전에 설치된 gem을 제외하고, 지정한 gem을 갱신합니다. (지정하지 않았다면 전부 갱신합니다.) 일반적으로, 기기 간에 정확히 같은 gem을 설치하려면 bundle install을 사용해야 합니다.

bundle update는 명시적으로 gem 버전의 갱신이 필요할 때만 사용합시다.

현재 환경을 갱신합니다.

$ bundle update

지정한 소스로부터 gem(과 관련된 모든 gem)을 갱신합니다.

$ bundle update --source=SOURCE

매개변수 없이 bundle update를 실행했다면, 번들러는 모든 이전에 설치된 gem을 무시하고 소스 안의 모든 gem의 가능한 최신 버전을 기반으로 모든 의존성을 다시 해결하려 합니다.

다음과 같은 Gemfile이 있다고 해봅시다.

source 'https://rubygems.org'
gem 'rails', '3.0.0.rc'
gem 'nokogiri'

처음 bundle install을 실행할 때, 번들러는 필요한 모든 의존성을 해결한 다음 설치할 것입니다.

Fetching source index for https://rubygems.org/
Installing rake (0.8.7)
Installing abstract (1.0.0)
Installing activesupport (3.0.0.rc)
Installing builder (2.1.2)
Installing i18n (0.4.1)
Installing activemodel (3.0.0.rc)
Installing erubis (2.6.6)
Installing rack (1.2.1)
Installing rack-mount (0.6.9)
Installing rack-test (0.5.4)
Installing tzinfo (0.3.22)
Installing actionpack (3.0.0.rc)
Installing mime-types (1.16)
Installing polyglot (0.3.1)
Installing treetop (1.4.8)
Installing mail (2.2.5)
Installing actionmailer (3.0.0.rc)
Installing arel (0.4.0)
Installing activerecord (3.0.0.rc)
Installing activeresource (3.0.0.rc)
Installing bundler (1.0.0.rc.3)
Installing nokogiri (1.4.3.1) with native extensions
Installing thor (0.14.0)
Installing railties (3.0.0.rc)
Installing rails (3.0.0.rc)

Your bundle is complete! Use `bundle show [gemname]` to see where a
bundled gem is installed.

보시다시피, Gemfile 안에 두 개의 gem만 있다고 해도, 실제 애플리케이션을 실행하려면 25개의 다른 gem이 필요합니다. 번들러는 설치된 gem의 정확한 버전을 Gemfile.lock 안에 기억해둡니다. 다음에 bundle install을 실행할 때에는, 번들러는 마지막으로 설치 됐던 모든 gem의 의존성 해결과 설치를 생략합니다.

Gemfile.lock을 버전 관리 시스템에 추가하고 다른 기기에서 클론한 후에 bundle install을 실행하면 _여전히_ 마지막에 설치했던 gem을 설치합니다. erubis, mail의 새 버전이 나왔는지 걱정할 필요가 없어요.

하지만 때때로 Gemfile의 정보와 일치하는 최신 버전으로 갱신해야 할 때가 있습니다.

이럴 때엔 bundle update를 실행하시면 Gemfile.lock을 무시하고 모든 의존성을 다시 해결합니다. 이 과정은 마지막으로 bundle update를 실행한 이후 gem의 저자들이 새로 릴리스한 gem을 기반으로 새로운 gem을 요청하므로 25개의 gem 모두 현저히 달라질 수 있으므로 주의하세요.

가끔 Gemfile 안의 나머지 gem은 Gemfile.lock 안의 버전으로 고정하고 하나의 gem만 갱신해야 할 때가 있습니다.

예를 들어 위의 시나리오에서 nokogiri의 릴리스 버전이 1.4.4이고 레일스와 모든 의존성의 _갱신 없이_ nokogiri만 릴리스 해야 할 경우, 다음과 같이 하면 됩니다.

bundle update nokogiri

번들러는 nokogiri와 그 의존성만 갱신하고, 레일스나 그 의존성은 그냥 둘 것입니다.

가끔 Gemfile 안에 여러 gem이 같은 하위(second-level) 의존성을 만족할 수 있습니다. 예를 들어 thin과 rack-perftools-profiler가 있다고 해보죠.

source 'https://rubygems.org'

gem 'thin'
gem 'rack-perftools-profiler'

thin gem은 rack >= 1.0에 의존합니다. 한편 rack-perftools-profiler는 rack ~> 1.0에 의존 합니다. 번들을 설치하면 다음 결과를 얻게 됩니다.

Fetching source index for https://rubygems.org/
Installing daemons (1.1.0)
Installing eventmachine (0.12.10) with native extensions
Installing open4 (1.0.1)
Installing perftools.rb (0.4.7) with native extensions
Installing rack (1.2.1)
Installing rack-perftools_profiler (0.0.2)
Installing thin (1.2.7) with native extensions
Using bundler (1.0.0.rc.3)

이 경우 두 gem이 각각의 의존성을 가지고 있지만, 공통으로 rack을 공유하고 있습니다. bundle update thin을 실행하면 번들은 thin에 의존하는 daemons, eventmachine, rack을 갱신하지만 rack-perftools_profiler에 의존하는 open4, perftools.rb는 갱신하지 않습니다. bundle update thin은 rack-perftools_profiler_에도_ 의존성이 있음에도 불구하고 rack을 갱신함에 주의하세요.

요약하면 bundle update를 이용해 gem을 갱신할 때는 번들러는 다른 gem에 의존하는 gem도 포함해 그 gem의 모든 의존성도 같이 갱신합니다.

이 시나리오에서 Gemfile에서 thin의 버전을 수동으로 갱신하고 bundle install을 실행하면 daemons와 eventmachine을 갱신하지만 rack은 갱신하지 않습니다.