本文参考了 Git分支管理策略

一、主分支 master

主分支只用来分布重大版本

二、开发分支 develop

主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做 develop。

如果想正式对外发布,就在 master 分支上,对 develop 分支进行"合并"(merge)将 develop 分支发布到 master 分支的命令:

  1. # 切换到Master分支
  2. git checkout master
  3. # 对 develop 分支进行合并
  4. git merge --no-ff develop

这里稍微解释一下,上一条命令的—no-ff参数是什么意思。默认情况下,Git 执行"快进式合并"(fast-farward merge),会直接将 master 分支指向 develop 分支。

使用—no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。关于合并的更多解释,请参考 Benjamin Sandofsky 的 《Understanding the Git Workflow》

三、临时性分支

除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有以下几种:

  • 功能分支 (feat)
  • 普通 fix 分支 (fix)
  • 修补 bug 分支 (fixbug)
  • 预发布分支 (release)
    这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有 master 和 develop。

四、功能分支

它是为了开发某种特定功能,从 develop 分支上面分出来的。开发完成后,要再并入 develop。

功能分支的名字,可以采用 feat/* 的形式命名。

创建一个功能分支:

  1. git checkout -b feat/xxx develop

开发完成后,将功能分支以 PR 的形式 merge 到 develop 分支,然后删除功能分支

五、普通 fix 分支

普通的局部代码优化(非 bug),从 develop 分支上面分出来的。开发完成后,要再并入 develop。

功能分支的名字,可以采用 fix/* 的形式命名。

创建一个普通 fix 分支:

  1. git checkout -b fix/xxx develop

开发完成后,将功能分支已 PR 的形式 merge 到 develop 分支,然后删除功能分支

六、修补 bug 分支

软件正式发布以后,难免会出现 bug。这时就需要创建一个分支,进行 bug 修补。

修补 bug 分支是从 master 分支上面分出来的。修补结束以后,再合并进 master 和 develop 分支。它的命名,可以采用 fixbug/* 的形式。

创建一个修补 bug 分支:

  1. git checkout -b fixbug/xxx master

修补结束后,以 PR 的形式 merge 到 master 分支,再合并到 develop 分支:

  1. git checkout develop
  2. git merge --no-ff fixbug/xxx

最后再删除 ‘修补 bug’ 分支

七、预发布分支

它是指发布正式版本之前(即合并到 master 分支之前),我们可能需要有一个预发布的版本进行测试。

预发布分支是从 develop 分支上面分出来的,预发布结束以后,必须合并进 develop 和 master 分支。它的命名,可以采用 release/* 的形式。

创建一个预发布分支:

  1. git checkout -b release/xxx develop

确认没有问题后,以 PR 的形式合并到 master 分支

再合并到 develop 分支:

  1. git checkout develop
  2. git merge --no-ff release/xxx

最后,删除预发布分支