2013-04-10 60 views
1

基於我的SO post我一直使用Github作爲我們的VCS,並藉助於Windows Github工具,處理這些基本操作非常棒。然而,像合併類似的操作,我必須回到Gitbash(SO Post),但那沒關係。Github的發佈控制和問題跟蹤

因此,源代碼級別VCS就位。現在,我們希望採取步驟 轉發並使用其簡單的問題跟蹤器具有「發佈控制」。對我們而言, 這意味着能夠跟蹤每個穩定版本(可以是新的 功能或錯誤修復等。)The idea是創建問題,將它們與 里程碑聯繫起來,並使用Gi​​thub提交註釋來解決問題並將其標記爲 它是一個穩定的版本。標記來自哪裏?

我知道我們有一個「開發」分支用於持續的變化,並定期與主人合併(即每個穩定的構建)。

這是正確的方法嗎?我們需要能夠從1.1版本開始恢復/建立1.0版本 - 以防萬一在將來需要它的情況下進行回滾(這是可能的嗎?如何?)Github是否滿足要求,還是我們還需要使用一些external tools

請分享您的經驗和建議。

回答

0

當我在等待其他專家的評論時,我想分享一個我碰到過的模型,看起來很棒!

A successful Git branching modelSO Post

總之,這裏是我如何解決我的基本需求(和它的規模有需要時) -

  • 最初保持兩個分支「主」和「發展「
  • 大師應該總是有一個穩定的版本和開發有一個持續的來源(可能不穩定)
  • 在未來,如果我們需要修復發佈後的錯誤,我們可以創建一個修補程序分支和當穩定合併它與主/發展
  • 我發現一件好事是,我可以保持穩定版本的標籤形式(即對於每個新版本的新標籤)
  • 最終,主分支將會以發展爲我們繼續與各穩定版本

有很多更可與上面的模型來處理,但我看到了我最初的擔憂合併解決。有更好的建議嗎?