gitflow工作流

贯穿整个开发周期，master和develop分支是一直存在的，master分支可以被视为稳定的分支，而develop分支是相对稳定的分支，特性开发会在feature分支上进行，发布会在release分支上进行，而bug修复则会在hotfix分支上进行。

master分支

develop分支

feature分支

release分支

hotfix分支

大家可能会发现我们这个跟标准的Gitflow工作流有些差别，其实也没有什么标准不标准的，前面说到要结合团队的实际情况，我们团队对于目前所采用的工作方式都是达成共识的，所以有一些差异并没有关系。

说了这么久，还没有一句git命令，那就让大家感受一下吧（感谢Bugly小色熊整理）：

1). 首先将远程代码拉取到本地

    git clone xxx
    git checkout -b develop origin/develop

2).新建feature分支

    git checkout -b feature

3).多人在feature上开发，如果中途需要将develop的变更合入feature，所有人需要将本地的代码变更提交到远程

    git fetch origin 
    git rebase origin/feature
    git push origin feature

然后由feature负责人rebase develop分支，删除原来feature分支，重新新建feature分支；

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git push origin :feature
    git push origin feature

这样可以保证feature保持线性变更；

4).feature开发完成后，所有人需要将本地的代码变更提交到远程

    git fetch origin 
    git rebase origin/feature
    git push origin feature

然后由feature负责人rebase develop分支，然后将feature分支合入develop，删除feature；

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git checkout develop
    git merge feature
    git push origin :feature

这样可以保证develop保持线性变更，各feature的变更完整可追溯；
5).合入feature后拉出对应的release/feature分支，后续bug修复在release/feature上

    git checkout develop
    git checkout -b release/feature

release/feature分支的同步合并与feature分支相同
6).release/feature分支bug修复完成后，拉取对应的tag推送远程进行发布

    git tag -a v1.0 -m 'feature发布'
    git push origin v1.0

之后将release/feature合入develop分支，然后删除

    git rebase develop
    git checkout develop
    git merge release/feature
    git push origin :release/feature

7).发布完成后将release合入master分支，保证master为最新稳定版本（实际操作为发起merge request）