Git分支管理

一、git-flow 的工作流程
当在团队开发中使用版本控制系统时,商定一个统一的工作流程是至关重要的。git-flow 是一个当前非常流行的工作流程。git-flow 并不是要替代 Git,它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。一旦安装安装 git-flow,你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。严格来讲,你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解,哪些工作流程是由哪些单独的任务所组成的,并且附带上正确的参数,以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然,如果你使用 git-flow 脚本就会更加方便了,你就不需要把这些命令和顺序都记在脑子里。

项目中存在两个长期分支:

master 分支一般对应的是生产环境的代码,是稳定的发布版本,包含确定即将发布的代码;
develop 分支对应的是开发环境的代码,存放的都是最新的开发版。
三种短期分支:

feature branch 新功能分支,一般一个新功能对应一个分支,对于功能的拆分需要比较合理,以避免一些后面不必要的代码冲突;
hotfix branch 热修复分支,紧急修 bug 的时候用;
release branch 发布分支,发布时候用的分支,一般测试时候发现的 bug 在这个分支进行修复;
短期分支一旦完成开发,就会被合并到 develop 或 master,然后被删除。

GitFlow 的优势有如下几点:

并行开发:GitFlow可以很方便的实现并行开发。每个新功能都会建立一个新的 feature分支,从而和已经完成的功能隔离开来,而且只有在新功能完成开发的情况下,其对应的 feature分支才会合并到主开发分支上(也就是我们经常说的develop分支)。另外,如果你正在开发某个功能,同时又有一个新的功能需要开发,你只需要提交当前 feature 的代码,然后创建另外一个feature 分支并完成新功能开发。然后再切回之前的 feature 分支即可继续完成之前功能的开发。
协作开发:GitFlow 还支持多人协同开发,因为每个 feature 分支上改动的代码都只是为了让某个新的 feature 可以独立运行。同时我们也很容易知道每个人都在干啥。
发布阶段:当一个新 feature 开发完成的时候,它会被合并到 develop 分支,这个分支主要用来暂时保存那些还没有发布的内容,所以如果需要再开发新的 feature,我们只需要从 develop 分支创建新分支,即可包含所有已经完成的 feature 。
支持紧急修复:GitFlow 还包含了 hotfix 分支。这种类型的分支是从某个已经发布的 tag 上创建出来并做一个紧急的修复,而且这个紧急修复只影响这个已经发布的 tag,而不会影响到你正在开发的新 feature。

  1. 最开始每个repo 都有两个 branch:master 和 develop,develop 基于 master 创建, 而feature 开发、bug fix 这些都是从develop branch 创建的
    Git分支管理_第1张图片

2.feature 分支都是从 develop 分支创建,完成后再合并到 develop 分支上,等待发布。

Git分支管理_第2张图片

3.当需要发布时,我们从 develop 分支创建一个 release 分支然后这个 release 分支会发布到测试环境进行测试,如果发现问题就在这个分支直接进行修复。在所有问题修复之前,我们会不停的重复发布->测试->修复->重新发布→重新测试这个流程。

Git分支管理_第3张图片

4.发布结束后,这个 release 分支会合并到 develop 和 master 分支,从而保证不会有代码丢失。master 分支只跟踪已经发布的代码,合并到 master 上的 commit 只能来自 release 分支和 hotfix 分支。

Git分支管理_第4张图片

5.hotfix 分支的作用是紧急修复一些 Bug。它们都是从 master 分支上的某个 tag 建立,修复结束后再合并到 develop 和 master 分支上。

Git分支管理_第5张图片

Git-flow 工作流定义了一个围绕项目发布的严格分支模型。其优点是清晰可控,使多人项目协作开发更加规范;缺点是相对复杂,需要同时维护两个长期分支。

二、安装 git-flow
在 linux 下安装 git-flow 很简单,直接 apt-get install git-flow 或者 yum install gitflow 就行,而在 windows 下安装比较麻烦,首先需要安装 git ,然后再安装 git-flow。

windows 安装 git-flow:

安装 git-flow (其中 “C:\Program Files\Git” 是git 的安装目录,根据实际情况修改):

git clone --recursive git://github.com/nvie/gitflow.git
cd gitflow/contrib
./msysgit-install.cmd “C:\Program Files\Git”
验证安装:

git flow version
1.12.3 (AVH Edition)
三、使用 git-flow

  1. 在项目中设置 git-flow
    $ git flow init
    No branches exist yet. Base branches must be created now.
    Branch name for production releases: [master]
    Branch name for “next release” development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [F:/aaa/dd/cpp/.git/hooks]
当在项目的根目录执行 “git flow init” 命令时(它是否已经包括了一个 Git 仓库并不重要),一个交互式安装助手将引导您完成这个初始化操作。

2.新功能开发
$ git flow feature start const-ref-pointer
Switched to a new branch ‘feature/const-ref-pointer’

Summary of actions:

  • A new branch ‘feature/const-ref-pointer’ was created, based on ‘develop’
  • You are now on branch ‘feature/const-ref-pointer’

Now, start committing on your feature. When done, use:

 git flow feature finish const-ref-pointer

此时会多出一个分支 feature/const-ref-pointer ,开发工作都会在在该分支进行

$ git branch
develop

  • feature/const-ref-pointer
    master

功能开发完成后,结束当前阶段的工作

$ git flow feature finish const-ref-pointer
Switched to branch ‘develop’
Updating 4a18517…057aae6
Fast-forward
ref1.cpp | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 ref1.cpp
Deleted branch feature/const-ref-pointer (was 057aae6).

Summary of actions:

  • The feature branch ‘feature/const-ref-pointer’ was merged into ‘develop’
  • Feature branch ‘feature/const-ref-pointer’ has been locally deleted
  • You are now on branch ‘develop’
    此时,刚才创建的分支 feature/const-ref-pointer 已经被合并进 develop,然后被删掉。

$ git branch

  • develop
    master
    3.管理release
    当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时,这意味着:第一,它包括所有新的功能和必要的修复;第二,它已经被彻底的测试过了。如果上述两点都满足,那就是时候开始生成一个新的 release 了:

$ git flow release start v0.1
Switched to a new branch ‘release/v0.1’

Summary of actions:

  • A new branch ‘release/v0.1’ was created, based on ‘develop’
  • You are now on branch ‘release/v0.1’

Follow-up actions:

  • Bump the version number now!
  • Start committing last-minute fixes in preparing your release
  • When done, run:

git flow release finish ‘v0.1’

现在会多出来一个release 分支 release/v0.1:

$ git branch
develop
master

  • release/v0.1

有了一个 release 分支,再完成针对 release 版本号的最后准备工作(如果项目里的某些文件需要记录版本号),并且进行最后的编辑。然后完成 release:

$ git flow release finish v0.1
Switched to branch ‘master’
Merge made by the ‘recursive’ strategy.
ref1.cpp | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 ref1.cpp
Already on ‘master’
Switched to branch ‘develop’
Already up to date!
Merge made by the ‘recursive’ strategy.
Deleted branch release/v0.1 (was 057aae6).

Summary of actions:

  • Release branch ‘release/v0.1’ has been merged into ‘master’
  • The release was tagged ‘v0.1’
  • Release tag ‘v0.1’ has been back-merged into ‘develop’
  • Release branch ‘release/v0.1’ has been locally deleted
  • You are now on branch ‘develop’
    查看 tag,会多出一个 v0.1 ,即本次发布版本。

$ git tag
v0.1
这个命令会完成如下一系列的操作:

首先,git-flow 会拉取远程仓库,以确保目前是最新的版本,也就是说如果远程仓库已经被其它人修改了,我们还需要合并进来解决冲突。
然后,release 的内容会被合并到 “master” 和 “develop” 两个分支中去,这样不仅产品代码为最新的版本,而且新的功能分支也将基于最新代码。
为便于识别和做历史参考,release 提交会被标记上这个 release 的名字(在我们的例子里是 “v0.1”)。
清理操作,版本分支会被删除,并且回到 “develop”。
4.hot fix
一般在发布版本之前发现的bug 都会直接在feature、bugfix或者develop 分支上进行修改,然后提交,而在发布之后,如果发现了问题,可以通过 hotfix branch 进行修复。比如在release 几个小时或几天之后,发现一些小问题,可以创建 hotfixes:

$ git flow hotfix start missing-compiler-file
Switched to a new branch ‘hotfix/missing-compiler-file’

Summary of actions:

  • A new branch ‘hotfix/missing-compiler-file’ was created, based on ‘master’
  • You are now on branch ‘hotfix/missing-compiler-file’

Follow-up actions:

  • Start committing your hot fixes
  • Bump the version number now!
  • When done, run:

git flow hotfix finish ‘missing-compiler-file’

这个命令会创建一个名为 hotfix/missing-compiler-file 的分支,我们要在这个分支上修改发现的问题,最后完成 hotfix:

$ git flow hotfix finish missing-compiler-file
Switched to branch ‘develop’
Merge made by the ‘recursive’ strategy.
compiler_instruction.md | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 compiler_instruction.md
Deleted branch hotfix/missing-compiler-file (was b482eb8).

Summary of actions:

  • Hotfix branch ‘hotfix/missing-compiler-file’ has been merged into ‘master’
  • The hotfix was tagged ‘missing-compiler-file’
  • Hotfix tag ‘missing-compiler-file’ has been back-merged into ‘develop’
  • Hotfix branch ‘hotfix/missing-compiler-file’ has been locally deleted
  • You are now on branch ‘develop’

查看tag 或多出来一个 missing-compiler-file:

$ git tag
missing-compiler-file
v0.1

这个过程非常类似于发布一个 release 版本:

完成的改动会被合并到 “master” 中,同样也会合并到 “develop” 分支中,这样就可以确保这个错误不会再次出现在下一个 release 中。
这个 hotfix 程序将被标记起来以便于参考。
这个 hotfix 分支将被删除,然后切换到 “develop” 分支上去。
5.同步到远程仓库
release finish只是完成了本地代码的一系列操作,还需要同步到远程仓库。

git push origin --all

git push origin --tags

四、注意事项
gitflow 在进行merge 的时候,默认情况下它会检查本次merge有多少次commit记录,如果仅有一条采用 fast-forward 模式,如果超过一条则采用no-fast-forward模式,no-fast-forward模式下会多生成一条merge的commit记录。这样做的好处是当只有一条提交记录时如果生成一条merge记录实际上会复杂化代码记录的管理;当有多条commit记录时生成的一个merge记录,可以方便的进行代码回退和记录检查。
如果 merge时发生冲突,不会终止流程,只是不会将本地的release分支删除,当前已经处于develop分支,待解决完冲突后需再次执行finish指令。
需要注意的是,如果本地还有未finish的release分支,将不允许使用start指令开启新的release分支,这一点是对并行发布的一个限制。

五、其他代码工作流

与Gitflow相似的代码管理工作流还有,Github flow和Gitlab flow。

Github flow是简化版的Gitflow,它使用master和feature来管理代码,它只有一个长期分支,就是master。Gitlab flow更关注代码的持续集成,一个版本需要创建测试环境、预览环境、生产环境的分支,最终汇总到stable branch用于发布。

你可能感兴趣的:(git)