如果让我做的话, 我会这么做.
从develop分出去的多个分支, 都只通过develop来交换代码, 互相之间不会合并.

各个分支同步develop分支的时候, 都使用--rebase选项, 将develop的最新提交同步到开发分支, 然后再将此开发分支使用--no-ff选项合并回develop, 这样保持单个分支的commit的连续性.

这是我本地测试的情况，都用的merge --no-ff模式合并

建议参考我校稿的这篇文章

http://fanyi.jobbole.com/2214/

比如hotfix分支，最后要checkout到develop分支进行merge就可以了

Hotfix分支从master分支建立，必须合并回develop分支和master分支，为Hotfix分支可以这样起名:hotfix-*

Hotfix分支在某种程度上非常像release分支，他们都意味着为某个新版本发布做准备，并且都是预先不可知的。Hotfix分支是基于当前生产环境的产品的一个bug急需解决而必须创建的。当某个版本的产品有一个严重bug需要立即解决，Hotfix分支需要从master分支上该版本对应的tag上进行建立，因为这个tag标记了产品版本

创建hotfix分支

Hotfix分支从master分支进行创建。例如当前线上1.2版本产品因为server端的一个Bug导致系统有问题。但是在develop分支进行更改是不靠谱的，所以我们需要建立hotfix分支，然后开始解决问题:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

千万别忘记在创建分支后修改版本号。

然后解决掉bug，提交一次或多次。

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

结束hotfix 分支

完成工作后，解决掉的bug代码需要合并回master分支，但同时也需要合并到develop分支，目的是保证在下一版中该bug已经被解决。这多么像release分支啊。

首先，对master分支进行合并更新，然后打tag

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

备注:你可以使用-s or -u 参数为你的tag设置标签签名。

紧接着，在develop分支合并bugfix代码

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

这里可能会有一些异常情况，当一个release分支存在时，hotfix 分支需要合并到release 分支，而不是develop分支。当release分支的使命完成后，合并回release分支的bugfix代码最终也会被合并到develop分支。(当develop分支急需解决这些bug，而等不到release分支的结束，你可以安全的将这些bugfix代码合并到develop分支，这样做也是可以的)。

最后删除这些临时分支

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).