2012-07-22 80 views
0

我們目前爲不同的項目提供了多個Git回購協議。git分支模型

目前我們有以下工作流程: 大師 - 一切都在這裏提交 部署 - 直播服務器

上使用的生產代碼,我們有哈德森CI對每一個新的檢查主承諾。每分鐘輪詢一次更改。 我們還有一個登臺服務器,用於簽署在我們的主分公司部署之前測試物理功能的工作請求

我們現在看到的主要問題是我們在工單/工作請求的基礎上工作,我們可能並不總是希望在發佈基礎上部署所有變更,但是如果和當票證從高級員工簽署時。

我已經看了Git的流量和github上流動的喜歡。兩者都有它們的優點,但是我無法找到一個包含登臺服務器和ci的策略。

閱讀任何幫助或建議將不勝感激!

更新1

我們的工作流程應遵循以下幾點:

Production: -------------I-----------O---- 
         /  /
      B---E---F---G J---K---L 
Master: A--/--C---D---H--\--/---M---N-\--- 
      \-1-/-2-/-3-/  \-1-/-2-/ 

Ci和師父所有的運行,所有的工作都進行的一個分支,合併,分期分段區域。 將特徵/故障單分支中的退出工作合併到生產中,僅在特定分支中進行更改。

糾正我,如果這是錯誤的,或者如果任何人有這個

回答

1

讓您擁有一個主分支更好的解決方案和任何承諾有去督促和一個臨時分支,任何犯有去臨時服務器我把它..

所以這對我來說很有意義。每票應該是它自己的分支關老爺。從那裏,一個開發者可以合併成階段來測試那裏..一旦它通過測試並簽署,該分支是好的去。從那裏你可以決定將哪些分支合併到你的「發佈」分支中,並將該分支合併到主控中進行部署。

你可以發佈分支甚至合併舉辦測試版本有一個更多的時間,以確保每個分支玩弄他人不錯。

或..如果您使用github ..只需讓每個開發人員根據門票分支一個新分支..然後發送一個PR到主人