
166
|
第七章
這個命令會更動個人的分支,接下來就該與團隊其他成員合作,將自己提出的異動納入
專案的主分支。
維持分支更新
Git 中儲存的分支一般分為兩類:專案的官方分支以及生命期較短的建議分支;共享的
專案分支一般用於整合來自其他開發人員,通過審核的更動,包含專案程式碼官方的歷
史紀錄。你本機上的這些分支應該維持在最新的狀態,作為個人工單分支的基礎,一般
慣例是不會在官方分支的本機複本直接寫入新的記錄,而是應該建立新的分支,完成自
己的工作,接著再將分支合併進官方分支;第三章介紹了幾種不同的分支方式,要是你
所在的團隊還沒有固定的分支策略,也許應該回頭看看第三章的內容。第二類的分支基
本上是開發人員的沙箱,這也是你測試新想法,讓程式碼可供他人審核的地方。這些短
生命期的分支也應該維持在最新狀態,但採取的方式會有些許的不同。
再一次…
rebase
與
merge
團隊會議還是沒有提到重設基線策略,團隊必須要決定更新分支狀態時採
取的作法(筆者仍然認為你應該採取對
團隊
最佳的作法,但筆者還是會
再示範重設基線的步驟,讓你知道重設基線並沒有比合併困難)。不論你
選擇哪一種方式,都應該謹慎的將決定的方式用文字記錄下來,讓 Git 的
新手也能夠用一致的方式執行命令。筆者發現要維持一致性最簡單的方式
是提供能夠直接複製/貼上的文件,讓成員直接在命令列操作,此外,圖
表也很有效(
http://gitforteams.com/resources/merge-rebase.html
)。
為了降低更新短生命期分支時需要處理的衝突數量 ...