昨天改完release分支的操作（http://www.jiangyouxin.net/2013/02/13/git_flow_2.html）。现在只剩hotfix了，当然，之后我发现我改的还是release。
按照原始定义，hotfix其实和release很像，唯一的不同是，release分支基于develop创建，而hotfix基于以前的版本TAG创建。源代码里，git-flow-hotfix明显是从git-flow-release复制了一份，然后作了些许修改，很多地方连注释都还没改过来。其实这哥俩没必要分这么清楚，在我的版本里，是使用release分支来实现原版hotfix分支的功能，只是启动命令稍有不同：
git flow release start <version> [<base>]
如果省略<base>，则release分支基于develop创建，代表一个主线版本；如果<base>是一个版本TAG，则release分支基于TAG创建，代表一个修补版本（厂里叫做擦屁股版本）。git-flow-release本来就有基于某个base创建分支的功能，只需要再改两点即可：
(1) 修改sanity检查部分，允许多个release分支共存
这是因为以前的git flow是允许一个release和一个hotfix分支共存的。
(2) 结束release分支，向master做--ff-only合并时，允许失败
如果一个release分支（原版是hotfix分支）从非最新发布版本的TAG（意味着master与TAG不重合）创建时，这个分支必然不能以Fast Forward的方式合并到master。但这是没有关系的，只要把TAG仍然打在分支上，并向develop合并即可。下一次发布develop时这个修改再引入master。
另外，原版git flow这种情况会直接用--no-ff合并，这是有严重问题的，会导致把新版本的修改引入旧版本。
============
至此微创新就做完了，总共只改了git-flow-feature和git-flow-release两个文件。总结起来，改前者是为了做一个squash的正确实现；改后者是因为原版本对merge --no-ff有一些不必要和错误的使用，以及让release分支同时支持hotfix的功能。
源代码放在了: https://github.com/JiangYouxin/gitflow
其中t/squash分支是我的版本。欢迎各种XX，谢谢。
============
为了说明我做的修改的正当性，我对git flow原版的问题，采取了毫不留情的态度；现在是该说好话的时候了。git flow本身非常简单，比如start命令就是git checkout -b而已，没有太多技术含量。它的主要功能，在于在做操作前执行充分的sanity检查（比如本地修改尚未提交之前，会拒绝将feature分支合并），防止在不恰当的时候做一些事情；同时绑定了一些操作（比如版本发布完成后，打TAG + 合并到develop 依序进行），防止某些事情被失望；另外在操作完成之后给一些贴心提示，让用户知道当前做了什么，之后要做什么。
来源：oschina
链接：https://my.oschina.net/u/987964/blog/108616