我很想知道分佈式SC環境中如何使用「分支」。 我們剛開始在團隊環境中使用mercurial,我希望從別人的經驗中學習 - 有什麼好的方法來「組織」分支實踐(希望我可以繞過痛苦和時間來做一個愚蠢的方式。 ..)在分佈式環境中分支
從我讀過的主幹應該包含正在進行的開發代碼,一個分支可能是一個'穩定'版本,其他可能是實驗或功能...合併到主幹上...
但是 - 對我來說有點不清楚的是bug修復和QA之類的東西......我讀過的大部分內容都提到要分別爲QA分支(在完成時將樹幹合併到分支中,然後推分支到樹幹 - 這看起來很麻煩,而且沒有解釋)
我也讀過你在穩定的分支(或發行分支)中進行bug修復,然後與主幹合併......這似乎與直覺相反 - 因爲你可能會像你一樣打破「穩定」分支修復錯誤...我期望穩定的分支是'穩定的',並且與版本#無法觸及...
我可以看到分支是必要的 - 但幫助我理解一些在那裏的做法。我們正在使用解釋型語言(未編譯)來開發Web應用程序 - 因此改變事物並破壞事情是非常容易的。
謝謝。
=======================
羅傑·亞歷克斯 - 感謝 - 這是有道理的 -
不過,我很現在有一個'小'的關鍵點'融合'分佈式模型與集中......在那裏寫了很多建議有一箇中央存儲庫 - 一個「水坑」(如果你願意)每個人都去'分享'或'拉'最新。
所以現在我發現你推薦的分佈式模型 - 打破了(至少在我心中)......我不想保留5個以上的主幹(main,hotfix,deploy/QA,develop,feature-n )並且讓每個人都進行拉/推 - 所以看起來開發人員LOCALLY似乎將從開發中拉出來 - 他們可能會在本地分支以獲取功能。或修補程序...然後一些管理員會將中央開發與中央釋放合併...開發團隊可能有一個本地發佈支持來修復QA團隊返回的問題......他們是否應該推動發佈和讓ADMIN與DEV合併?然後把他們自己的改變從CENTRAL DEV回到他們的本地?或者他們應該在本地合併 - 並將RELEASE推回中央?
與此一致 - 我不認爲有必要或想要有主要的本地副本...
好像保持開發團隊(推薦)3樹幹中央存儲庫(MAIN, QA,DEV)真的會混淆分佈式模型的工作流程。但是,有一箇中心MAIN--被推送到你的製作工具箱 - 似乎需要一箇中心QA,它將gests推送到QA包裝盒,然後由一個單獨的團隊進行質量檢查。(因此不能合乎邏輯地放在每個人的設備上盒子本地)
哇 - 管理大型工作流程很糾結 - 在管理這些東西時必須有一些文獻 - 不同的工作流程想法等。工具他們自己不會很好地描述如何使用它們...(就像電鑽不帶有關於如何建立內閣的指令!!!笑)
再次感謝
我想發佈一個答案,並鏈接到相同的博客文章,但你擊敗了我。我們使用與所描述的類似的模型,它對我們來說工作得非常好。所以,+1 –
QA分支在哪裏適合?或QA檢查「發佈」 - 與發佈工作合併回到開發...... ???? – jpmyob
@jpmyob:關於在發佈中的工作,請注意圖 - 承諾發佈總是合併回來開發,以及掌握。關於質量保證,沒有硬性規定,但我認爲你會發現它通常是在發佈分支上完成的,因爲開發分支在任何給定時間都可能被破壞。所以一般來說:大多數工作都是針對開發完成的,當您準備發佈時,您會裁剪一個發佈分支並針對該分支執行質量檢查。 QA期間發現的錯誤在發佈分支上得到修復。當QA完成時,您將發佈分支合併到master和development中。 –