我們使用:
直到項目接近完成,或者我們正在創(chuàng)建一個里程碑版本(例如。產(chǎn)品演示,演示版),然后我們(定期)從我們當前的開發(fā)分支到:
發(fā)布分支中沒有新特性。只有重要的bug在發(fā)布分支中被修復,修復這些bug的代碼被重新集成到開發(fā)分支中。
有一個開發(fā)和一個穩(wěn)定(發(fā)布)分支的兩部分流程使我們的生活變得更容易了,我不相信我們可以通過引入更多的分支來改進它的任何部分。每個分支也有它自己的構建過程,這意味著每隔幾分鐘就會產(chǎn)生一個新的構建過程,所以在代碼簽入之后,我們在大約半小時內(nèi)得到了所有構建版本和分支的新可執(zhí)行文件。
有時,我們也有一個開發(fā)人員的分支,致力于一項新的、未經(jīng)證實的技術,或者創(chuàng)建一個概念的證明。但通常情況下,只有當更改影響到代碼基的許多部分時,才會這樣做。這種情況平均每3-4個月發(fā)生一次,這樣的分支通常在一兩個月內(nèi)重新整合(或報廢)。
一般來說,我不喜歡每個開發(fā)人員都在自己的分支中工作,因為你“跳過去,直接搬到集成地獄”。我強烈反對。如果你有一個共同的代碼庫,你應該一起工作。這使得開發(fā)人員對他們的簽入更加謹慎,每個程序員都知道哪些更改可能會破壞構建,因此在這種情況下測試更加嚴格。
關于入住早期的問題:
如果你只需要完美碼要簽入,實際上什么都不應該簽入。沒有任何代碼是完美的,對于QA來驗證和測試它,它需要在開發(fā)分支中,這樣才能構建一個新的可執(zhí)行文件。
對于我們來說,這意味著一旦一個特性完成并由開發(fā)人員進行測試,它就會被簽入。如果有已知的(非致命的)錯誤,甚至可以簽入,但在這種情況下,通常會通知受bug影響的人。不完整和工作中的代碼也可以簽入,但前提是它不會造成任何明顯的負面影響,如崩潰或破壞現(xiàn)有的功能。
有時,不可避免的合并代碼&數(shù)據(jù)檢查會使程序在新代碼生成之前無法使用。我們做的最起碼是在簽入注釋中添加一個“等待構建”,并/或發(fā)送一封電子郵件。