我的代碼庫的不同分支和版本具有不同的依賴關係，例如， master分支可能在Ruby 1.9上並且使用Rails 4，但是一些發行版分支可能在Ruby 1.8上並且使用Rails 3.我想這是一個常見的問題，但我並沒有真正瞭解它。基於分支的具有不同依賴關係的流量調配
有沒有一種乾淨的方式來檢測/重新提供基於當前分支（或者Gemfile）的Vagrant虛擬機？
目前，我已經設置了「捆綁安裝」和其他東西在供應商，這種sorta工作，但它仍然混亂了我曾經在每個分支的依賴關係的VM環境。
爲什麼不將Vagrantfile和供應腳本添加到存儲庫？因爲他們是分支的一部分，他們可以看起來像你想要的。
如果經常在分支之間切換，這可能不再適用，因爲每次更改分支時都需要重新提供虛擬機。在這種情況下，我會建議在Vagrantfile中設置多個vms併爲所有vms並行添加配置腳本。那麼你可以做類似
vagrant up ruby1.8
vagrant up ruby1.9
...等等。
在hek2mgl答案的精神，但我會用不同的VM存儲庫，而不是多個虛擬機從同一Vagrantfile
比如我有時做到以下幾點：
我有一個shell腳本workhere.sh其中設置相應的虛擬機使用
#!/usr/bin/env bash
export VAGRANT_CWD="/Volumes/VMDrive/..."/;
如果您提交的腳本到你的混帳回購協議，所有你需要你籤之後的分支是做source workhere.sh做，它會指向你到正確的VM，所以你可以有多個虛擬機並行
如果您第一次切換，您需要啓動虛擬機，然後在ssh之後，但是如果您多次切換，虛擬機將啓動並指出您需要指向哪個虛擬機，vagrant ssh會連接到正確的虛擬機。
如果您讓虛擬機啓動並運行，您需要對IP（如果使用固定IP）和端口轉發保持謹慎，因爲您可能有衝突。
你的第一個建議是我目前正在做的。我希望能有更優雅的東西？如果至少有一種方法可以避免重新下載紅寶石和寶石，它可能不會那麼糟糕。 – Karl
第二種解決方案應該適合你。如果需要，我建議將流浪/供應開發留在單獨的分支併合併到其他開發分支。但是，我看到的基本問題是，您正在使用分支機構在一個回購中開發不同的軟件（它們不同，不是嗎？）。我會做出3個回購。這將大大簡化工作流程。 – hek2mgl
這只是一個項目，具有多個發佈分支。有額外的寶石並沒有太大的傷害，所以每個ruby *的虛擬機幾乎都可以工作，除了我不得不擔心點釋放（例如ruby 2.2.2），因爲它被鎖定在Gemfile中。雖然即使這樣也許它只有5個，所以這可能是好的。 – Karl