本文参考了 Git分支管理策略
一、主分支 master
主分支只用来分布重大版本
二、开发分支 develop
主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做 develop。
如果想正式对外发布,就在 master 分支上,对 develop 分支进行"合并"(merge)将 develop 分支发布到 master 分支的命令:
# 切换到Master分支
git checkout master
# 对 develop 分支进行合并
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/*
的形式命名。
创建一个功能分支:
git checkout -b feat/xxx develop
开发完成后,将功能分支以 PR 的形式 merge 到 develop 分支,然后删除功能分支
五、普通 fix 分支
普通的局部代码优化(非 bug),从 develop 分支上面分出来的。开发完成后,要再并入 develop。
功能分支的名字,可以采用 fix/*
的形式命名。
创建一个普通 fix 分支:
git checkout -b fix/xxx develop
开发完成后,将功能分支已 PR 的形式 merge 到 develop 分支,然后删除功能分支
六、修补 bug 分支
软件正式发布以后,难免会出现 bug。这时就需要创建一个分支,进行 bug 修补。
修补 bug 分支是从 master 分支上面分出来的。修补结束以后,再合并进 master 和 develop 分支。它的命名,可以采用 fixbug/*
的形式。
创建一个修补 bug 分支:
git checkout -b fixbug/xxx master
修补结束后,以 PR 的形式 merge 到 master 分支,再合并到 develop 分支:
git checkout develop
git merge --no-ff fixbug/xxx
最后再删除 ‘修补 bug’ 分支
七、预发布分支
它是指发布正式版本之前(即合并到 master 分支之前),我们可能需要有一个预发布的版本进行测试。
预发布分支是从 develop 分支上面分出来的,预发布结束以后,必须合并进 develop 和 master 分支。它的命名,可以采用 release/*
的形式。
创建一个预发布分支:
git checkout -b release/xxx develop
确认没有问题后,以 PR 的形式合并到 master 分支
再合并到 develop 分支:
git checkout develop
git merge --no-ff release/xxx
最后,删除预发布分支