你的 git 工作流是怎样的？

Question

GitFlow 是由 Vincent Driessen 提出的一个 Git 操作流程规范，包含以下几个关键分支：

名称	说明
master	主分支
develop	主开发分支,包含确定即将发布的代码
feature	新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理，以避免一些后面不必要的冲突
release	发布分支，发布时候用的分支，一般测试时候发现的 bug 在这个分支就行修复
hotfix	hotfix 分支，紧急修复 bug 的时候用

GitFlow 的优势有如下几点:

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

然后就是 GitFlow 最经典的几张流程图

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

当需要发布时，我们从 develop 分支创建一个 release 分支

然后这个 release 分支会发布到测试环境进行测试，如果发现问题就在这个分支上直接进行修复。在所有问题修复之前，我们会不停的重复发布->测试->修复->重新发布->重新测试这个流程。
发布结束后，这个 release 分支会合并到 develop 分支和 master 分支，从而保证不会有代码丢失。

master 分支值只能跟踪已经发布的代码，合并到 master 分支上的 commit 只能来自 release 分支和 hotfix 分支

hotfix 分支的作用是紧急修改一些 bug。
他们都是从 master 分支上的某个 tag 建立，修复结束后再合并到 develop 和 master 分支上