使用Git進行代碼升級

Question

我想知道如何在代碼升級的情況下將git用於多種環境（dev-> test-> prod）。我讀了一些關於分支的知識，但不太瞭解如何解決我的問題，因爲我必須有能力同時並且彼此分開地運行所有環境。

會非常感謝某種方法。

Answer 1

這個三層工作流程似乎是相當普遍的主題。以下是我們如何做到的。我們是一家Ruby商店，所以這裏也提到了一些測試。

我們所有人都從單獨的「故事」（來自Pivotal Tracker）分別開展工作。這意味着如果我們都致力於主人分支，那麼我們會一直踩着彼此的腳趾。爲了解決這個問題，我們每個人都會爲該特定的工作創建一個新分支（基於最新的主人）。

當我們完成這部分工作時，我們自己運行測試，如果他們通過測試，他們會合並回主分支分支，測試再次運行以確保沒有引入中斷。如果有的話，我們嘗試使用git bisect找出它是什麼，並且在99％的情況下工作。

大部分時間（因爲我們真的很棒*），測試通過。當所有的測試都通過主分支後，我們將部署到我們的登臺服務器。所以我猜這意味着大師是分段分支。當該功能（或更有可能的功能）已獲得批准後，我們​​會將這些更改合併到生產分支中，然後將該分支推送到生產站點。

通過這種設置，單個開發人員都可以擁有應用程序的可運行副本，QA團隊可以在有時間的情況下獲得正在運行的副本（這是「最有趣」的一部分）我的工作，收集人就像放牧貓），真實世界有一個完美的網站。

理論上，無論如何。人們犯錯誤。

Answer 2

DVCS介紹another dimension to versioning：
「公開」（推/拉），用於排他地由通過分支，或通過標籤

代碼推廣。

對於具有多重貢獻的環境，像瑞恩這樣的本地獨立分支機構描述最佳作品。

但是通過DVCS，您可以簡單地將代碼庫推送到專用存儲庫，並將該克隆視爲「測試」升級環境。
通常情況下，您將first rebase您目前的工作放在遠程升級的代碼之上，以解決本地的任何衝突。然後你會推動（在遠程端快速合併）。

所以它是另一個可用於代碼升級的工具（雖然仍然使用分支或標籤：通常，「生產」最好由分支標識）。

Answer 3

在我的情況下，git push是用於從dev發佈文件到測試服務器。然後，我們每天（或每週）構建（使用phing）將應用程序導出到生產服務器（那裏沒有git回購）或發佈包含源代碼的tarball以供下載。

工作流程取決於您的項目特定變量。

切換服務器不僅可以區分代碼版本，還可以區分數據庫，環境，配置和用戶。

一次更改所有選項的自然方式也是更改回購，因此在開發/測試/生產回購之間進行推送。

但是你可以編寫你自己的負責所有這些交換機的git鉤子。有許多鉤選項可供選擇。 Branch只是一個提交，所以你可以擁有post-commit鉤子，只導出特定的標籤，或者導出特定分支的內容。