# 关于 gitflow

# 概念：

Git Flow 是构建在 Git 之上的一个组织、管理软件开发活动的模型。Git Flow 是一套使用 Git 进行源代码管理时的一套行为规范和，通过利用 Git 创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。这种软件开发的活动模型被称为 “Git Flow”。

# 原理：

gitflow 的核心就 branch，通过在项目的不同阶段对 branch 的不同操作包括但不限于 create、marge、rebase、等来实现一个完整的高效率的工作流程。一般而言，软件开发模型有常见的瀑布模型、迭代开发模型、以及最近出现的敏捷开发模型等不同的模型。每种模型有各自应用场景。Git Flow 重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题。因此，Git flow 可以很好的于各种现有开发模型相结合使用，尤其是多人合作开发时提高效率。用一张图来了解 gitflow 的流程：从右向左看从上到下看

# Branch：

Branch 是 gitfolw 的核心。主要分为两大类 Main Branchs 和 Supporting branches, 其中 Main Branchs 中又包含了 Master 和 Develop，而 Supporting branches 中包含了 **Feature **、Release、Hotfix 以及其他自定义分支，下面逐一讲解：

# Master:

描述：
master 分支上存放的是最稳定的正式版的代码，并且该分支的代码应该是随时可在开发环境中使用的代码（Production Ready state）。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，master 分支上的代码要被更新，同时，每一次更新，都需要在 master 上打上对应的版本号 (tag)。
生成及销毁：
任何人不允许在 master 上进行代码的直接提交，只接受合入，Master 上的代码必须是要从经过多轮测试且已经发布一段时间 (根据 DAU 以及项目实际情况来定，个人建议 K 歌国际版可以定为一周) 且线上已经稳定的 release 分支合并进去，然后在 Master 上生成 tag (通常就是对应的版本号)
命名：
master

# Develop:

描述：
develop 分支是保存当前最新版本开发成果的分支。该分支上的代码允许有 BUG，但是必须保证编译通过，且该分支可以作为每天夜间测试的分支 (如果有夜间测试的话) 所以该分支也叫做 Nightly build。当 develop 分支上的代码已实现了软件需求说明书中所有的功能 (必须经过开发自测，但是不必经过 QA) 且相对稳定时候，就可以基于此分支来拉出新的 release 分支交付 QA 进行测试。
生成及销毁：
Develop 分支是由一个人 (通常是 Team Leader) 从 Master 中拉出，任何人不得在 Develop 上进行代码提交，只接受合入。Develop 上所有代码一定都是由 Supporting branches 中的 Branch 合并进来，且合入 Develop 的分支必须保证功能完整，可以独立运行，可允许包含一些 BUG (但是最好经过自测，不要有太大或者太明显的 BUG，比如一启动就 crash 之类的)。
命名：
develop
流程：

# Feature:

描述：
Feature 分支通常叫做功能分支，也可以叫做个人分支，一般命名为 feature/XXXX, 该分支就是每一个开发人员进行开发的分支，比如做一些功能、需求之类的东西，这个分支上的代码变更最终合并回 develop 分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。一般而言，feature 分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
生成及销毁：
每个开发者从通常会 Develop 分支中拉取自己的 feature，且开发者可以随意的在自己的 feature 上进行操作包括但不限于提交、回滚、删除。如果最终需要合并入 develop 那就要保证功能的完整性以及代码的稳定新，比如我在 feature 上做了 3 个需求但是由于时间关系我只做了两个，那也可以将 feature 合并入 develop，然后剩下的那一个需求等有时间了再去 feature 上做完之后再合入 develop。所以这里说的功能的完整性并不是值得要做完所有的功能，而是要保证你所要做的所有需求中的某一个或者某几个功能已经做完，不允许把做到一半的功合并入 develop。合并入 develop 尽量上删除远端的 feature 分支，本地的 feature 可以视情况而取舍。
命名：
feature 通常是从 develope 上拉取所有通常用 dev_功能描述_英文名 来命名。比如 feature/dev_refresh_molierzhang
流程：

# Release:

描述：
Release 分支通常叫做发布分支，也可以叫做测试 - 发布分支，一般命名为 Release/1.2.3（后面是版本号）, 该分支是为测试 - 发布新的产品版本而开辟的。因为包含测试流程，所以在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在 release 分支上进行这些工作可以让 develop 分支空闲出来以接受新的 feature 分支上的代码提交，进入新的软件开发迭代周期。注意：该分支上的代码一定是可编译可运行的，允许包含小 BUG
生成及销毁：
当 develop 分支上的代码已经包含了该版本所有即将发布的功能和需求，并且已通过自测且已基本稳定，我们就可以考虑准备基于 develop 拉取 release 分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到 release 分支之内（避免由此引入一些不可控的系统缺陷）。成功的派生了 release 分支之后，develop 分支就可以为 “下一个版本” 服务了。所谓的 “下一个版本” 是在当前即将发布的版本之后发布的版本。开发人员可以在此分支上修改 BUG，进行提交、回滚等操作，但是与 feature 不同的是 release 分支是被多人操作的，不像 feature，所以一定要小心避免冲突。当现在 QA 测试没有问题，便从 release 上发布上线，且经过一段时间的验证没有问题后合入 master，并且删除 release 分支，其实根据 release 分支的特性我们可以使用 Git Hook 触发软件自动测试以及生产环境代码的自动更新工作。这些自动化操作将有利于减少新代码发布之后的一些事务性工作。
命名：
release/1.2.3 后面跟对应的版本号
流程：
同 feature

# Hotfix:

描述：
Hotfix 叫热修复分支，除了是计划外创建的以外，hotfix 分支与 release 分支十分相似，当已经发布的版本（Master 上代码）遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从 master 分支上指定的 tag 版本拉取 hotfix 分支来组织代码的紧急修复工作。这样做的显而易见的好处是不会打断正在进行的 develop 分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行、独立的开展工作。
生成及销毁：
由 Master 上拉取，进行修复，负责修改 BUG 的同事可以进行提交及其它操作，后续的热修复测试也在此分支上进行。通过测试验证没问题后有一个人 (通常为 teamleader) 合并入 Master 分支，且同时也要合并入 Develop 分支
命名：
Hotfix/1.2.3 后面跟对应的版本号
流程：

# 总结

Git Flow 开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束。应该说，为我们的软件开发提供了一个可供参考的管理模型。Git Flow 开发模型让开发代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。

所谓模型，在不同的开发团队，不同的文化，不同的项目背景情况下都有可能需要进行适当的裁剪或扩充。

# 效率工具

推荐 sourceTree 和 gitkarken (用免费版即可，不用充钱) 前者对 gitsubmodel 的支持不太好，不过目前介于我们没有实现组件化所以暂时可以无视；后者完美支持 gitsubmodel，但是在拉取一些比较大的库的时候可能会卡死，前公司一个项目 30G+ 会有卡死情况出现，后者界面炫酷一些 iOS 的话 Xcdoe 自带 git 也可以试试。