從 1.0.13 tag 開 1.0.14 branch，然後在 1.0.14 branch，修完之後 squash 成一個
commit，然後再 cherry-pick 回 master 及 dev，release 之後在 1.0.14 branch 下
1.0.14 tag，再把 1.0.14 branch 刪掉。
下次要再繼續修正 1.0.14 版有的問題時，就從 1.0.14 tag 開一個 1.0.15 的 branch
出來修正，以此類推。
※ 引述《JohnnyDell (強尼戴爾)》之銘言：
: 請問各位都是採用怎麼樣的分支策略呢?
: 目前是開發Java web app的專案，用的版控是git(一般自架的git)。現階段是採用
: A successful Git branching model (http://nvie.com/posts/a-successful-git-branc
: hing-model/)
: 也就是從master開始，分出develop支線，在由develop去開各個feature跟bugfix，
: 分支寫好後就merge回develop。要release時是從develop開出release分支，進行改
: 版號之類的準備動作，再將release分支同時merge到master與develop。如此便等於
: 把develop跟master的差距merge回去master了，在master上打一個tag(e.g., 1.0.2)
: 1.0.x的發佈都是這樣，但是接下來要往1.1.x了。就不曉得一般做法是怎麼樣分支的呢?
: 因為1.0.x之後還是可能會有需要fix的bug或者甚至小修改，此bug也可能需要到develop。
: 假設目前develop和master已經merge release/1.0.13(意即目前發佈的版本號到1.0.13)
: 1. 在develop的這個commit開一個1.0.x的分支，後續1.0.x的從此分支去做?
: 2. 在master的這個commit開一個1.0.x的分支，後續1.0.x的從此分支去做?
: 以上兩種之後的tag就會打在1.0.x的分支上?
: 因為1.1.x就是繼續從develop往下做並且merge到master
: 3. 在develop的這個commit開一個1.1.x的分支，後續1.1.x的從此分支去做?
: 第三種的就不清楚要怎麼樣發佈1.1.x版本，因為如果merge到master不就也檔到1.0.x了?
: 很怕分支策略一個開錯導致後面版控一整個亂掉
: 感謝