分支工作的一個較佳的實踐, 即git工作的最佳實踐

從最初的svn到後來的git,上來給我的感覺就是git更方便, 可以在本地進行版本的提交,回退. 後來對hash有所了解, 知道了git的每個版本其實都是一個固定的hash. 這個hash有自己的父節點, 只要記住了這個hash, 提交就不會丟失.
實際呢? 對git的理解也是在這裏, 大家還是在一個 develop 上去開發, 工作模式跟 svn 其實沒有差別(除了我們自己的個人分支外, 在本地可以進行一些其他的處理)

分支的功能

develop分支

1. 最初開發階段

當初我們在 develop 分支上開發, develop 就相當於我們原來的 svn 的一個分支一樣, 大家都在這裏進行開發. 知道我們真的進行決定發版後.

2. 發布版本階段

後來開始進行版本的發布後, 我們大家的工作版本仍然在 develop 分支上, 然後 test 分支會從 develop 上進行切過來, 然後 release 分支上又會從 test 分支上進行切出. 然後在對應的分支上進行bug的提交.

好處沒有啥,就是比較好理解吧. 壞處是在 develop 上的東西終究會直接上到 release, 不能對某些功能進行很好的控制, 也不能很好的控制代碼質量. 因為工程的功能點比較多, 也不可能對所有的功能進行全部的回歸. 只能盡量的對一些改動的地方進行重點測試.

3. 按照功能點進行的分支控制

開始按照通用的工作流, 所謂的 git flow 進行開發.但是可能又會稍有不同.
我們每個人的開發起點都是基於 release 分支的(或者 master), 基於一個比較穩定的版本然後開始自己的特性分支開發. 每一個特性就是一個固定的功能.
基於功能點的分支

後記與總結

記錄的很亂, 最後也總結一個下.
每一個分支都有每一個分支的功能. 每個人又是在每個人的分支上進行開發, 這個開發的起點一定是穩定的分支, 這樣你增加的功能就會比較單一(只是你自己開發的分支). 對於以後的發布和合並都會比較好處理. 如果分支的開發周期比較長, 最好經常 rebase 一下release 的代碼, 避免以後合並處理的沖突較多.
develop: 開發內部的協調和自測分支;
test: 測試分支, 提測分支;
release: 發布分支, 比較穩定的分支;
master: 線上分支, 穩定版本的分支;

對於bug的修復, 如果是自己的特性分支問題, 那麽就在自己的特性分支上開發. 如果是穩定版本的修復, 一定是在對應的穩定版本進行修復. 然後經過 test 分支的回歸(如果是 hotfix 可以直接合並到 release 或者 master 上進行緊急測試), 合並到對應的版本上去.

git的實際工作經驗總結