从 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了?
: 很怕分支策略一个开错导致后面版控一整个乱掉
: 感谢