2012-09-17 107 views
2

我想弄清楚什麼是最好的工作流使用Git同步幾個開發人員使用的代碼庫。我有一個由我的團隊負責人爲我提供的腳本,它幾乎添加了我需要同步的所有代碼文件,而省去了批處理文件,編譯文件等。使用Git的推薦工作流程是什麼?

總之,我相信我應該做的在我開始處理問題之前同步,然後在完成測試時同步。但是,我擔心這會牽涉到從我收回回購代碼和發佈我的代碼之間的漫長流逝。這意味着,例如,我可能會使用一些在我不知情的情況下被破壞或修復的函數,或者我可能會在別人正在使用的時間內無意中破壞某些代碼。另外,我認爲發佈「未完成」代碼可能是一種不好的做法,但我不確定。

我如何管理我的同步,這樣我干擾儘量少用別人的代碼,並避免長時間的週轉時間?任何建議,歡迎。

回答

2

我的策略(有很多人)在這種情況下將是:

1)爲自己創建兩個分支,在自己的倉庫。一個工作代碼準備好發佈(您的發佈分支),一個用於開發/ bug修復(您的devel分支)。

2)一般:您devel的分支會從源再加上從您發佈分支最新的代碼。這樣,如果源文件有任何更改,您可以獲取並更新。此外,如果您的開發方面發生變化,您可以獲取該變化。 (例如,您已準備好發佈,但只是意識到源API已更改。)。你會得到一個devel分支,它有你的(穩定的)變化加上源代碼的變化,加上你可以使用的(不穩定的)修復。

3)一旦你準備好與發展,合併您修復科進你的發行版分支和審查/集成提供導線的發佈分支代碼。如果事情發生了變化,而且確實需要修復,則可以返回步驟2)。

這個想法是在任何時候都有一個方便的版本,但不斷地改變和修正它,保持它穩定和最新,同時有一個不穩定的開發分支和所有來源的最新代碼。

(project)   src-branch ----*----*---*-----*----------*------M 
            \    \    /
(personal) devel/bugfix-branch ------M-*-*--*-------M-M---*--*----/-- 
              \  /  \/
(personal)  release-branch ---------------M-*---*----*--*---M---- 

           ------ time -----> 

Legend: * commit, M merge

在最後一步你實際提供無論是混帳打上補丁或讓鉛從您發佈分支(您BARE庫的)審覈/集成抓取你的貢獻進入項目源。

+0

哇,這聽起來很酷。如果你能提供這個圖表,我會非常感激! –

+0

添加圖片到回答。 – count0

+0

謝謝!大! –

相關問題