Git flow 是最早诞生，并且广泛得到采用的工作流程。
主要分支:
- Master: 作为线上分支，处在 production-ready 状态
- Develop: 最新的准备发布的开发版本
支援性分支:
- Feature: 开发新功能都从 develop 分支出来，完成后 merge 回 develop
- Release: 准备要 release 的版本，只修 bugs。从 develop 分支出来，完成后 merge 回 master 和 develop
- Hotfix: 必须马上修 master 赶上线的情况。会从 master 分支出来，完成后 merge 回 master 和 develop
但这么多分支一看就头疼，维护成本也高，Git flow的优点是清晰可控，缺点是相对复杂。
团队现阶段的开发基本基于功能驱动，需求是分支的出发点，在各自分支开发完成后合并到主分支然后删除开发分支。在现有流程中，开发新需求的时候，相当于，我们先根据需求创建了Feature分支，各自开发自测完后合并到Master分支，Master分支直接提供线上发布。
基于现状发现了一些问题：
- Commit混乱，Feature分支中各自随意的合并主分支后，太多的commit，会导致提交历史很难被理解，不便于区分和review。
- Commit Message没有统一的规范标准。
- 没有稳定的tag版本，不方便回滚。
一、分支的确立
可以从现有的Master新建一个Release分支代替现有的Master。所有Feature往Release上合并，Release在每周四之前将已完成并测试通过的Feature合并完并发布，经历过周末线上过度，Master每周一版记录tag，Master只做版本记录。可以解决回滚的问题。
二、分支的创建
主要分支:
- Master: 作为主分支，每周对应tag，用以记录项目迭代，方便回滚。
- Release: 最新的准备发布的开发版本，只接受周四一次的Feature的合并和bug修复。
支援性分支:
- Feature: 开发新功能都从 Release 分支出来，完成后 merge 回 Release
1.
Feature分支
这个分支的创建来源于需求，首先我们可以统一分支命名的方式便于理解区分。这里推荐可以以 开发者需求简称分支创建日期
这样的形式来命名。Feature分支正常情况只有一个前端和后端开发人员提交，不存在任何冲突，在这里可以随意的Commit直到你开发完成，完成后先以Feature分支来进行测试通过自身功能，再往Release分支合并。
2.
Release分支
这个分支由线上的Master分支拉取，这是一个只接收Feature合并和bug修改的分支。前面说Feature可以随便Commit，那些随意提交的Commit在这里会被带到Release来，那Release的Commit还是一样混乱，这里我是设想把Release当做一个可以查看提交明细的分支，可以看到每一次的提交，因为经常Commit和Push代码，别人就更容易知道你在做哪一部分工作。然而太多的commit，会导致提交历史很难被理解。但一旦往Master合并的时候，我们应该merge commits，将我们自身的提交简化，将一个Feature的提交合并成一个大的Commit，在Master的记录里可以清晰的看出来项目的进展。
3.
Master分支
这个分支就像一个里程碑的存在，记录每一次稳定的发布和迭代，可以从提交记录中清晰的看出项目的进展和修改。
这样确立分支是为了保持Master的纯净也是为了便于回滚。相比较现在的流程，其实只是多了一步把commit合并后提交到Master。
三、Commit的合并
针对commit 提交混乱的问题，这里说一些Idea中的commit合并的方式。
第一种方式，通过rebase的方法合并
1.点击菜单VCS->Git->ShowHistory
2.在History页上点击Log
3.例子中有4个commit（将a commit看成第1个），假如要将上面最后2个commit（第4和第3个）压缩成1个，那么选中第2个commit（第3个的parent），右键菜单Copy Revision Number，把复制的commit sha1粘贴在一边，防止粘贴板内容被后续的操作覆盖掉
4.菜单VCS->Git->Rebase，勾上Interactive，Onto粘贴第3步中复制的commit sha1
5.在交互式rebase菜单中，将第一个选为pick，后面的都选为squash，点Start Rebasing
6.在Additional Rebase Input中编辑下压缩以后的commit message
7.合并完的结果
这里对应的命令行操作相当于，git rebase -i Head~4 branch(去了当前分支最新的四个commit),越下面的越新。
这样一来，第二行的commit会和第一行的合并成为一个commit。
第二种方式，通过reset的方法合并
1.和原来一样，这次假设把上面两个b的提交合并到一起，选中最下面的b的提交。右键菜单Reset Current Branch to Here。
2.选择Soft，点Reset。上面两行commit修改的文件修改会被保留，这时候重新commit，相当于把两次合并成一次commit。这种方式可能更方便一点。
需要注意的是，合并commit的操作应该在push到远程分支之前，不然如果别人拉取或cherry pick了你的commit，当你rebase你的commits时，一切就变的混乱了。
四、Commit Message的规范
这里参考一些比较通用的模板，主要内容是标题和主题内容，形式如下：
<type>: <subject>
<body>对格式的说明如下：
type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。所有的type类型如下：
feat： 新增feature
fix: 修复bug，对应修改了什么bug
docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
perf: 优化相关，比如提升性能、体验
test: 测试用例，包括单元测试、集成测试等
chore: 改变构建流程、或者增加依赖库、工具等
revert: 回滚到上一个版本
格式要求：
# 标题行：描述主要变更内容
#
# 主体内容：更详细的说明文本， 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#<type>: <subject> 这一个段落是必须的，必须注明类型和概要。一个commit只完成一个type。
关于commit message的规范可以结合commit合并一起使用，在commit合并的时候，将commit message规范化。
五、补充，关于SourceTree和Gitflow
SourceTree 是 Windows 和Mac OS X 下免费的 Git 和 Hg 客户端管理工具，同时也是Mercurial和Subversion版本控制系统工具。支持创建、克隆、提交、push、pull 和合并等操作。
SourceTree拥有一个精美简洁的界面，大大简化了开发者与代码库之间的Git操作方式，这对于那些不熟悉Git命令的开发者来说非常实用。
简单说SourceTree是git客户端管理工具，这个APP不仅自带官方汉化还自带gitflow。可以将流程化分支管理的工作交给SourceTree去完成，这里大致的介绍一下。
1.首先通过初始化仓库的操作，定义化初始化的各分支名（对应gitflow的各个分支）
2.当需要开发一个新功能的时候. 切换到 develop 分支上, 接着还是点击gitflow 按钮, 选择建立新的功能, 然后为功能起一个名称b. 这样本地分支目录下就会多了一个feature文件夹, 里面有一个b分支。
3.当这个功能b开发完成后, 还是点击gitflow按钮。 点完成当前版本.代码会自动合并到develop分支上, 并且可以选择删除当前的b分支.
4.当需要发布的时候, 切换到develop分支上, 点击gitflow按钮, 选择建立新的发布版本1.2. 这样本地分支目录下就会多了一个release文件夹, 里面有一个1.2分支.
当1.2没问题后, 还是点击gitflow按钮, 点完成当前版本, 给当前版本打个tag. 代码会自动合并到master分支和develop分支上.
5.如果线上版本一步小心有了一个bug, 切换到master分支上, 还是点击gitflow按钮, 点建立新的修复版本1.1.1. 完成后还是点击gitflow按钮, 点完成当前版本, 给当前版本打个tag. 代码会自动合并到master分时和developer分支上.
这期间, 统一的入口点都是点击gitflow来完成的，各个分支的创建和完成，已经完成后的合并分支，都可以通过gitflow的创建和完成操作完成，只需要关心我们要做什么，完成了什么，除非在合并过程中发生了冲突，都可以通过SourceTree来完成。冲突的时候SourceTree也提供对比人工merge的功能。具体需要了解的可以自行了解。
5140
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
