Git 工做流程

版本控制几乎是全部开发项目的必备，Git是目前主流的版本控制系统，下面介绍几种经常使用的工做流程。

目录：

• 最简模式
• 特征分支
• 开发分支
• 开发 + 特性分支
• 发布分支

1. 最简模式

这是最简单的工做流模式，只使用master分支。

这种方式只适合于很是小的项目，例如我的项目。

当团队增加后，这种方式会极其混乱，产生大量的代码冲突。

2. Feature 特征分支

在上种方式上添加了 feature 特征分支。

每一个 feature 分支都是用来开发某个新功能，以便与项目的其余部分隔离。

当 feature 分支中的功能开发完成后，这个分支就合并到 master 分支。

因此 feature 分支的生命周期比较短。

3. Developer 开发分支

开发分支基于 master 分支建立，并与 master 同样长期存在。

开发分支是开发时随时提交的代码，master 分支中是达到可发布状态的代码。

这种模式与最简模式同样，只适合很是小的团队。

4. Developer + Feature 混搭

这2种策略能够很好的混合使用。

master 分支中老是可发布的代码。

feature 分支只与 developer 分支合并。

当 developer 分支中的代码测试经过后，合并到 master 分支，而后发布。

5. Release 发布分支

在上一种模式上进行了扩展，这种方式适用于频繁发布的大型项目。

当 feature 都开发完成，合并到 developer 分支，测试经过后进入到发布状态，这时，建立一个 release 分支。

release 为预上线分支，若是上线前发现了bug，在 release 上进行修改提交，这样就能够容许其余团队在不干扰发布工做的状况下处理新功能。

当 release 肯定发布时，要合并到 master 和 developer 分支。

这种模式基础上还有一种扩展：hotfix分支，用于修复紧急bug，从 master 建立，修复完成后，合并到 master 和 developer 分支。

也就造成了这个经典的 git 工做流图：

翻译整理自：

https://medium.com/@jurtzmarc...