Git flow

Git flow

集中式工做流

功能分支工做流

Gitfow工做流

---

根据Vincent Driessen的文章描述，git flow 的工做流程图以下：

git flow 的主要分支有两个，master和trunk。这两个分支是长期维护的，而且这两个分支的代码应该是同步的。另外使用其余的临时性分支来进行项目的开发维护。

咱们本身的流程与上图提到的流程略有不一样。如下是详细的描述：

1. master 主分支

• master分支具备全部的历史版本。主要用于版本的管理。每一次发版以后，都会基于这次发版在master上创建一个tag，用于版本的跟踪。
• master 上的代码永远是稳定的。
• 不直接向master push 代码。

2. trunk 功能集成分支

trunk分支主要用于开发管理，做为功能的集成分支。当有新的功能需求时，从trunk 分支检出一个功能分支进行开发。

3. 临时性分支

dev-

release-

hotfix-

test-

4. 测试(test)分支 & 功能开发(dev)分支

在新建功能分支以前，须要先建立一个上游的test分支。基于trunk建立并检出一个新的分支，做为新功能开发的测试分支。同时再基于test分支建立一个功能开发分支。

• 测试分支从trunk分支检出
• 基于test分支建立功能开发分支。不直接在test分支上作提交。
• test分支测试完毕以后上线，从test 合并回trunk分支。

• test分支为保护分支，从功能分支合并到test分支须要作code review。

  推荐命名规范：test-[功能模块名称]

  # 若是以这种方式检出，须要提交到远程仓库，并在gitlab上设置为保护分支，
  # 建议直接从gitlab上建立并检出分支。
  $git checkout -b test-tradeEntry trunk

  在建立测试分支的时候，须要设置为保护分支，建议从gitlab直接建立，并设置为保护分支。而后再checkout

  

  点击跳转分支管理页面

  

  点击建立新分支

  

  选择新建的分支

  

  打开新分支的设置页面

  

  设置分支为保护分支

  

与此同时，从测试分支检出功能开发分支（dev）：

• 功能分支从 test 分支检出
• 必须合并回test

• 命名避免使用 master, trunk, release-, or hotfix- 。

  推荐命名规范：dev-[功能模块名称]

  # 也能够像建立test分支同样在gitlab上建立功能分支。若是使用命令行的方式则进行以下的操做
  
  $ git checkout test-tradeEntry
  
  $ git checkout -b dev-tradeEntry test-tradeEntry
  
  # 同时把在本地建立的分支推送到远程仓库
  $ git push --set-upstream origin dev-tradeEntry

此时开发的分支就创建好了。 咱们在本地开始开发，若是是多人协同进行一个功能的开发的话，建议再基于dev-tradeEntry在本地检出本身开发的分支进行开发feature-tradeEntry-lsy，而后再合并到dev-tradeEntry分支上。

推荐命名规范： feature-[功能模块名称/与dev功能模块名一致]-[开发者姓名]

$ git checkout -b feature-tradeEntry-lsy dev-tradeEntry

开发完成须要合并：

$git add .

    $git commit -m 'feat(模块名): 提交信息'

    $git push

    $git checkout dev-tradeEntry

    $git pull

    $git merge --no-ff feature-tradeEntry-lsy （--no-ff no fast forward 会产生新的提交记录。）

    $git push origin dev-tradeEntry

开发完成，须要提交测试 dev -> test:

因为须要作code review 。 合并的操做并不禁开发者直接操做，而是发起一个Pull Request， 在gitlab 为Merge Request。当经过code review 以后，便可进行合并。

进入gitlab dev分支页面，建立一个合并请求：

建立合并请求

合并以后便可进行提测。测试期间产生的bug，在开发本地修改合并到dev以后，再同步dev代码到test分支上进行下一轮测试，如此循环往复直到测试验收经过。

测试完成，须要上线合并 test -> trunk:

$git checkout trunk

    $git pull

    $git merge --no-ff test-tradeEntry （--no-ff no fast forward 会产生新的提交记录。）

    $git branch -d test-tradeEntry

    $git push origin trunk

5. 预发布(release)分支

• release 从 trunk 检出
• 必须合并回 trunk 以及合并到 master
• 命名惯例： release-*

预发布分支用于进行发布前的集成回归，能够基于此进行bug的修改。修改完成后，合并回trunk以及master， 而且在master 上打一个tag，同时进行上线。能够在push master的时候设置钩子进行发布的构建。

$ git checkout -b release-1.2 trunk

在确认没有问题以后，能够合并到master分支：

$ git checkout master

$ git pull

$ git merge --no-ff release-1.2

# 对合并生成的新节点，作一个标签

$ git tag -a 1.2

再合并回trunk 分支：

$ git checkout trunk

$ git pull

$ git merge --no-ff release-1.2

$ git branch -d release-1.2

6. bug修改(fixbug)分支

若是线上发布的版本须要紧急修复，能够直接从master上检出一个hotfix的分支，用于bug 修改。

• 从master 检出
• 必须合并回master
• 必须合并到trunk
• 命名惯例： hotfix-*

$ git checkout -b hotfix-1.2.1 master

    #修改完毕以后合并回master

    $ git checkout master

    $ git pull

    $ git merge --no-ff hotfix-1.2.1

    $ git tag -a 1.2.1

    #合并到trunk

    $ git checkout trunk

    $ git pull

    $ git merge --no-ff hotfix-1.2.1

    $ git branch -d hotfix-1.2.1

注意：当在进行bug fix 的时候若是有一个release 正在发版，则应该把hotfix合并到release上，而不是trunk。

7. 基于master 的 tag

git tag -a 0.1 -m "Initial public release" master

git push --tags