当在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情，然而，如果在你的团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。
 
基本上你可以定义一个完全适合你自己项目的工作流程，或者使用一个别人定义好的。
 
在这章节中我们将一起学习一个当前非常流行的工作流程 git-flow。
 
什么是 git-flow？
 
一旦安装安装 git-flow，你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的，这就是我们的工作流程！
 
git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。
 
严格来讲，你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 git-flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。
 
安装 git-flow
 
近些年来出现了很多不同的安装方法。在本章节中我们会使用当前最流行的一种： AVH Edition。
 
要了解安装 git-flow 细节，请阅读下面这个文档 official documentation。
 
在项目中设置 git-flow
 
当你想把你的项目 “切换” 到 git-flow 上后，Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。
 
话虽如此，git-flow 却存在一些限制。让我们开始在一个新的项目上初始化它吧，之后我们就会有所发现：
 
$ git flow init
Initialized empty Git repository in /Users/tobi/acme-website/.git/
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
 
当在项目的根目录执行 “git flow init” 命令时（它是否已经包括了一个 Git 仓库并不重要），一个交互式安装助手将引导您完成这个初始化操作。听起来是不是有点炫，但实际上它只是在你的分支上配置了一些命名规则。
 尽管如此，这个安装助手还是允许你使用自己喜欢的名字。我强烈建议你使用默认的命名机制，并且一步一步地确定下去。
 
gitflow的分支模式
 
git-flow 模式会预设两个主分支在仓库中：
 
master 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。
 
 
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
 
 
让我们开始探索一些在现实应用中可能遇到的案例吧！
 
功能开发
 
对于一个开发人员来说，最平常的工作可能就是功能的开发。这就是为什么 git-flow 定义了很多对于功能开发的工作流程，从而来帮助你有组织地完成它。
 
开始新功能
 
让我们开始开发一个新功能 “rss-feed”：
 
$ git flow feature start rss-feed
Switched to a new branch 'feature/rss-feed'

Summary of actions:
- A new branch 'feature/rss-feed' was created, based on 'develop'
- You are now on branch 'feature/rss-feed'
 
概念
 
在这些命令的输出文本中，git-flow 会对刚刚完成的操作打印出一个很有帮助的概述
 
当你需要帮助的时候，你可以随时请求帮助。例如：
 
$ git flow feature help
 
正如上面这个新功能一样，git-flow 会创建一个名为 “feature/rss-feed” 的分支（这个 “feature/” 前缀 是一个可配置的选项设置）。你已经知道了，在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
 git-flow 也会直接签出这个新的分支，这样你就可以直接进行工作了。
 
完成一个功能
 
经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：
 
$ git flow feature finish rss-feed
Switched to branch 'develop'
Updating 6bcf266..41748ad
Fast-forward
    feed.xml | 0
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 feed.xml
Deleted branch feature/rss-feed (was 41748ad).
 
最重要的是，这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：
 
一个在更广泛的 “开发” 背景下的全面测试。
稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。
 
之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。
 
管理 releases
 
Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。
 
创建 release
 
当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：
 
$ git flow release start 1.1.5
Switched to a new branch 'release/1.1.5'
 
请注意，release 分支是使用版本号命名的。这是一个明智的选择，这个命名方案还有一个很好的附带功能，那就是当我们完成了release 后，git-flow 会适当地_自动_去标记那些 release 提交。
 
有了一个 release 分支，再完成针对 release 版本号的最后准备工作（如果项目里的某些文件需要记录版本号），并且进行最后的编辑。
 
完成 release
 
现在是时候按下那个危险的红色按钮来完成我们的release了：
 
git flow release finish 1.1.5
 
这个命令会完成如下一系列的操作：
 
首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
清理操作，版本分支会被删除，并且回到 “develop”。
 
从 Git 的角度来看，release 版本现在已经完成。依据你的设置，对 “master” 的提交可能已经触发了你所定义的部署流程，或者你可以通过手动部署，来让你的软件产品进入你的用户手中。
 
hotfix
 
很多时候，仅仅在几个小时或几天之后，当对 release 版本作做全面测试时，可能就会发现一些小错误。
 在这种情况下，git-flow 提供一个特定的 “hotfix” 工作流程（因为在这里不管使用 “功能” 分支流程，还是 “release” 分支流程都是不恰当的）。
 
创建 Hotfixes
 
$ git flow hotfix start missing-link
 
这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。
 这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。
 
就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！
 
完成 Hotfixes
 
在把我们的修复提交到 hotfix 分支之后，就该去完成它了：
 
$ git flow hotfix finish missing-link
 
这个过程非常类似于发布一个 release 版本：
 
完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。
这个 hotfix 程序将被标记起来以便于参考。
这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。
 
还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。
 
回顾一下
 
最后，在结束这个章节之前，我要再次强调几个重点。
 首先，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。
 其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。
 
记住，使用 git-flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。

GitFlow 代码版本管理
 
Git的优点
 
  现在大多数公司的研发团队都在Git作为代码管理工具，使用CVS、SVN等已经很少。至于为什么选用git，参考《Git、CVS、SVN比较》。Git主要有以下优点：
 
Git是分布式的，本地库包含了远程库的所有内容；
Git有优秀的分支模型，利于管理；
Git由于代码都在本地，打分支和合并分支方便快速，且代价小。
 
当然Git的优点还有很多，感兴趣的，可以去看一下Git本身的设计，内在的架构体现了很多的优势，不愧是出资天才程序员Linus (Linux之父) 之手。
 
GitFlow
 
  虽然有Git这样优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大的挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：
 
如何开始一个Feature的开发，而不影响别的Feature？
由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
哪些分支已经合并回了主干？
如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?
大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打的各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。
 
诸如以上问题，代码需要代码规范一样，同样代码管理也需要一个清晰的流程和规范，荷兰程序员Vincent Driessen为了解决这个问题提出了A Successful Git Branching Model。流程图如下：
 
 
Gitflow工作流程围绕项目发布定义了严格的分支模型。尽管它比 Feature Branch Workflow 更复杂一些，但它也为管理更大规模的项目提供了坚实的框架。
与 Feature Branch Workflow 比起来，Gitflow 流程并没有增加任何新的概念或命令。 其特色在于，它为不同的分支分配了非常明确的角色，并且定义了使用场景和用法。除了用于功能开发的分支，它还使用独立的分支进行发布前的准备、记录以及后期维护。当然，你还是能充分利用 Feature Branch Workflow 的好处：拉拽请求（Pull Request）、隔离的试验以及更高效率的合作。
 
GitFlow常用分支
 
master
 
主分支, 产品的功能全部实现后, 最终在 master 分支对外发布;
该分支为只读唯一分支, 只能从其他分支(release/hotfix)合并, 不能在此分支修改;
另外所有在 master 分支的推送应该打标签做记录, 方便追溯;
例如 release 合并到 master, 或 hotfix 合并到 master。
 
develop
 
主开发分支, 基于 master 分支克隆;
包含所有要发布到下一个 release 的代码;
该分支为只读唯一分支, 只能从其他分支合并;
feature 功能分支完成, 合并到 develop(不推送);
develop 拉取 release 分支, 提测;
release/hotfix 分支上线完毕, 合并到 develop 并推送。
 
feature
 
功能开发分支, 基于 develop 分支克隆, 主要用于新需求新功能的开发;
功能开发完毕后合到 develop 分支(未正式上线之前不推送到远程中央仓库!!!);
feature 分支可同时存在多个, 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除。
 
release
 
测试分支, 基于 feature 分支合并到 develop 之后, 从 develop 分支克隆;
主要用于提交给测试人员进行功能测试, 测试过程中发现的 BUG 在本分支进行修复, 修复完成上线后合并到 develop/master 分支并推送(完成功能), 打 Tag
属于临时分支, 功能上线后可选删除。
 
hotfix
 
补丁分支, 基于 master 分支克隆, 主要用于对线上的版本进行 BUG 修复;
修复完毕后合并到 develop/master 分支并推送, 打 Tag;
属于临时分支, 补丁修复上线后可选删除;
所有 hotfix 分支的修改会进入到下一个 release。
 
工作原理
 
master分支
 
master分支为初始分支, 也是用于记录历史的分支, 所有在master分支上的Commit应该Tag。
 GitFlow 使用两个分支来记录项目开发的历史, 而不是使用单一的 master 分支。在 Gitflow 流程中，master 只是用于保存官方的发布历史，而 develop 分支才是用于集成各种功能开发的分支。使用版本号为 master 上的所有提交打标签（tag）也很方便。事实上, Gitflow 流程就是围绕这两个特点鲜明的分支展开的。
 
 
Feature 分支
 
分支名 feature/*
 
每一个新功能的开发都应该各自使用独立的分支。
 为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库。
 但是，在创建新的功能开发分支时，父分支应该选择 develop（而不是 master）。
 当功能开发完成时，改动的代码应该被合并（merge）到 develop 分支。功能开发永远不应该直接牵扯到 master。
 
 
Release分支
 
分支名 release/*
 
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature。 (注意：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
 发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
 
 
Hotfix分支
 
分支名 hotfix/*
 
hotfix分支是维护分支，基于Master分支创建。发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯一一种可以直接基于 master 创建的分支。一旦问题被修复了，所做的改动应该被合并入 master 和 develop分支（或者用于当前发布的分支）。在这之后，master 上还要使用更新的版本号打好Tag。
 
 
工作主要流程
 
初始化项目为 gitflow, 默认创建 master 分支, 然后从 master 拉取第一个 develop 分支;
从 develop 拉取 feature 分支进行编码开发(多个开发人员拉取多个 feature 同时进行并行开发, 互不影响);
feature 分支完成后, 合并到 develop(不推送, feature 功能完成还未提测, 推送后会影响其他功能分支的开发),
 合并 feature 到 develop, 可以选择删除当前 feature, 也可以不删除, 但当前 feature 就不可更改了, 必须从 release 分支继续编码修改
从 develop 拉取 release 分支进行提测, 提测过程中在 release 分支上修改 BUG;
release 分支上线后, 合并 release 分支到 develop/master 并推送, 合并之后, 可选删除当前 release 分支, 若不删除, 则当前 release 不可修改。 线上有问题也必须从 master 拉取 hotfix 分支进行修改;
上线之后若发现线上 BUG, 从 master 拉取 hotfix 进行 BUG 修改;
hotfix 通过测试上线后, 合并 hotfix 分支到 master/develop 并推送, 合并之后, 可选删除当前 hostfix, 若不删除, 则当前 hotfix 不可修改, 若补丁未修复, 需要从 master 拉取新的 hotfix 继续修改;
当进行一个 feature 时, 若 develop 分支有变动, 如其他开发人员完成功能并上线, 则需要将完成的功能合并到自己分支上,即合并 develop 到当前 feature 分支;
当进行一个 release 分支时, 若 develop 分支有变动, 如其他开发人员完成功能并上线, 则需要将完成的功能合并到自己分支上, 即合并 develop 到当前 release 分支 (!!! 因为当前 release 分支通过测试后会发布到线上, 如果不合并最新的 develop 分支, 就会发生丢代码的情况)。
 
GitFlow流程命令代码示例
 
一般命令代码
 
创建develop分支
 
给默认的 master 配备一个 develop 分支, 一种简单的做法是：让一个开发者在本地建立一个空的 develop 分支, 然后把它推送到服务器。develop 分支将包含项目的所有历史，而 master 会是一个缩减版本。现在，其他开发者应该克隆（clone）中央仓库，并且为 develop 创建一个追踪分支。
 
git branch develop
git push -u origin develop
 
开始新Feature开发
 
当我们开始开发新功能时，我们需要各自建立了自己的分支。注意，在创建分支时，父分支不能选择 master，而要选择 develop。
 
git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature    

# 修改    
git status
git add some-file
git commit    
 
完成Feature
 
当新功能开发完毕时，需要将代码合并到develop分支，并删除feature分支。
 
git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature   
 
开始Relase
 
当功能开发完成时需要新建一个分支来进行产品代码发布的相关工作，这个分支专门用于发布前的准备，包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似，不同之处在于它是专为产品代码发布服务的。一旦创建了这个分支并把它推向中央仓库，这次产品发布包含的功能也就固定下来了。
 任何还处于开发状态的功能只能等待下一个发布周期。
 
git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit
 
完成Release
 
一切准备就绪之后，就要把发布分支合并入 master 和 develop 分支， 并为 master 分支打赏合适的标签，然后再将发布分支删除。注意，往 develop 分支的合并是很重要的，因为开发人员可能在发布分支上修复了一些关键的问题，而这些修复对于正在开发中的新功能是有益的。再次提醒一下，如果 A 功能团队强调代码评审（Code Review），此时非常适合提出这样的请求。
 
git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0   


git tag -a v0.1.0 master
git push --tags
 
开始Hotfix
 
如果线上发现bug，需要从 master 分支新建一个维护分支来修复线上bug。
 
git checkout -b hotfix-0.1.1 master  
 
完成Hotfix
 
当bug修复完毕，需要将代码合并到 master/develop 分支， 并将 master 打上Tag， 最后删除维护分支。
 
git checkout master
git merge --no-ff hotfix-0.1.1
git push


git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags
 
GitFlow 命令代码
 
初始化： git flow init
 这个命令会进行一些默认的配置，可以自动创建上面介绍的所有分支：master、develop、feature、relase、hotfix 等分支。
 完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始。
开始新 Feature: git flow feature start MYFEATURE
 该命令会创建一个feature分支
完成一个 Feature: git flow feature finish MYFEATURE
 该命令将会把 feature/MYFEATURE 合并到 develope 分支，然后删除功能(feature)分支。
Publish 一个 Feature(也就是 push 到远程服务器): git flow feature publish MYFEATURE
获取 Publish 的 Feature: git flow feature pull origin MYFEATURE
开始一个 Release: git flow release start RELEASE BASE
发布 Release: git flow release finish RELEASE
 当完成（finish)一个发布分支时，它会把所有的修改合并到 master 分支，同时合并回 develop 分支，所以不需要担心 master 分支比 develop 分支更加超前。
Publish 一个 Release: git flow release publish RELEASE
注意打标签 git push --tags
开始一个 Hotfix: git flow hotfix start VERSION BASENAME
发布一个 Hotfix: git flow hotfix finish VERSION
 当完成（finish)一个维护分支时，它会把所有的修改合并到 master 分支，同时合并回 develop 分支。
 

什么是Gitflow
 
Gitflow是基于Git的强大分支能力所构建的一套软件开发工作流，最早由Vincent Driessen在2010年提出。最有名的大概是下面这张图。
 
 
 
 
在Gitflow的模型里，软件开发活动基于不同的分支：
 
The main branches 
*   master 该分支上的代码随时可以部署到生产环境
 
  
develop 作为每日构建的集成分支，到达稳定状态时可以发布并merge回master
Supporting branche 
*   Feature branches 每个新特性都在独立的feature branch上进行开发，并在开发结束后merge回develop
 
  
Release branches 为每次发布准备的release candidate，在这个分支上只进行bug fix，并在完成后merge回master和develop
Hotfix branches 用于快速修复，在修复完成后merge回master和develop
Gitflow通过不同分支间的交互规划了一套软件开发、集成、部署的工作流。听起来很棒，迫不及待想试试了？等等，让我们先看看Gitflow不是什么。
 
Gitflow不是Git社区的官方推荐工作流。是的，不要被名字骗到，这不是Linux内核开发的工作流也不是Git开发的工作流。这是最早由Web developer Vincent Driessen和他所在的组织采用并总结出的一套工作流程。
Gitflow也不是Github所推荐的工作流。Github对Gitflow里的某些部分有不同看法，他们利用简化的分支模型和Pull Request构建了适合自己的工作流Github Flow。
现在我要告诉你，Gitflow在企业软件开发中甚至不是一个最佳实践。ThoughtWorks Technology Radar在2011年7月刊，2015年1月刊里多次表明了Gitflow背后的feature branch模型在生产实践中的危害，又在2015年11月刊里专门将Gitflow列为不被推荐的技术。
为什么Gitflow有问题
 
Gitflow对待分支的态度就像: Let's create branches just because... we can!
 
很多人吐槽，为什么开发一个新feature非得新开一个branch，而不是直接在develop上进行，难道就是为了……废弃掉未完成的feature时删除一个branch比较方便？
 
很多人诟病Gitflow太复杂。将这么一套复杂的流程应用到团队中，不仅需要每个人都能正确地理解和选择正确的分支进行工作，还对整个团队的纪律性提出了很高的要求。毕竟规则越复杂，应用起来就越难。很多团队可能不得不借助额外的帮助脚本去应用这一套复杂的规则。
 
然而最根本问题在于Gitflow背后的这一套feature branch模型。
 
VCS里的branch本质上是一种代码隔离的技术。使用feature branch通常的做法是：当developer开始一个新feature，基于develop branch的最新代码建立一个独立branch，然后在该branch上完成feature的开发。开发不同feature上的developers因为工作在彼此隔离的branch上，相互之间的工作不会有影响，直到feature开发完成，将feature branch上的代码merge回develop branch。
 
我们能看到feature branch最明显的两个好处是：
 
各个feature之间的代码是隔离的，可以独立地开发、构建、测试；
当feature的开发周期长于release周期时，可以避免未完成的feature进入生产环境。
后面我们会看到，第一点所带来的伤害要大于其好处，第二点也可以通过其他的技术来实现。
 
merge is merge
 
说到branch就不得不提起merge。merge代码总是痛苦和易错的。在软件开发的世界里，如果一件事很痛苦，那就频繁地去做它。比如集成很痛苦，那我们就nightly build或continuous integration，比如部署很痛苦，那我们就频繁发布或continuous deployment。 merge也是一样。所有的git教程和git工作流都会建议你频繁地从master pull代码，早做merge。
 
然而feature branch这个实践本身阻碍了频繁的merge: 因为不同feature branch只能从master或develop分支pull代码，而在较长周期的开发完成后才被merge回master。也就是说相对不同的feature branch，develop上的代码永远是过时的。如果feature开发的平均时间是一个月，feature A所基于的代码可能在一个月前已经被feature B所修改掉了，这一个月来一直是基于错误的代码进行开发，而直到feature branch B被merge回develop才能获得反馈，到最后merge的成本是非常高的。
 
现代的分布式版本控制系统在处理merge的能力上有很大的提升。大多数基于文本的冲突都能被git检测出来并自动处理，然而面对哪怕最基本的语义冲突上，git仍是束手无策。在同一个codebase里使用IDE进行rename是一件非常简单安全的事情。如果branch A对某函数进行了rename，于此同时另一个独立的branch仍然使用旧的函数名称进行大量调用，在两个branch进行合并时就会产生无法自动处理的冲突。
 
如果连rename这么简单的重构都可能面临大量冲突，团队就会倾向于少做重构甚至不做重构。最后代码的质量只能是每况愈差逐渐腐烂。
 
持续集成
 
如果feature branch要在feature开发完成才被merge回develop分支，那我们如何做持续集成呢？毕竟持续集成不是自己在本地把所有测试跑一遍，持续集成是把来自不同developer不同team的代码集成在一起，确保能构建成功通过所有的测试。按照持续集成的纪律，本地代码必须每日进行集成，我想大概有这几种方案：
 
每个feature在一天内完成，然后集成回develop分支。这恐怕是不太可能的。况且如何每个feature如果能在一天内完成，我们为啥还专门开一个分支？
每个分支有自己独立的持续集成环境，在分支内进行持续集成。然而为每个环境准备单独的持续集成环境是需要额外的硬件资源和虚拟化能力的，假设这点没有问题，不同分支间如果不进行集成，仍然不算真正意义上的持续集成，到最后的big bang conflict总是无法避免。
每个分支有自己独立的持续集成环境，在分支内进行持续集成，同时每日将不同分支merge回develop分支进行集成。听起来很完美，不同分支间的代码也可以持续集成了。可发生了冲突、CI挂掉谁来修呢，也就是说我们还是得关心其他developer和其他团队的开发情况。不是说好了用feature branch就可以不管他们自己玩吗，那我们要feature branch还有什么用呢？
所以你会发现，在坚持持续集成实践的情况下，feature branch是一件非常矛盾的事情。持续集成在鼓励更加频繁的代码集成和交互，让冲突越早解决越好。feature branch的代码隔离策略却在尽可能推迟代码的集成。延迟集成所带来的恶果在软件开发的历史上已经出现过很多次了，每个团队自己写自己的代码是挺high，到最后不同团队进行联调集成的时候就傻眼了，经常出现写两个月代码，花一个月时间集成的情况，质量还无法保证。
 
如果不用Gitflow...
 
如果不用Gitflow，我们应该使用什么样的开发工作流？如果你还没听过Trunk Based Development，那你应该用起来了。
 
 
 
 
是的，所有的开发工作都在同一个master分支上进行，同时利用Continuous Integration确保master上的代码随时都是production ready的。从master上拉出release分支进行release的追踪。
 
可是feature branch可以确保没完成的feature不会进入到production呀。没关系，Feature Toggle技术也可以帮你做到这一点。如果系统有一项很大的修改，比如替换掉目前的ORM，如何采用这种策略呢？你可以试试Branch by Abstraction。我们这些策略来避免feature branch是因为本质上来说，feature branch是穷人版的模块化架构。当你的系统无法在部署时或运行时切换feature时，就只能依赖版本控制系统和手工merge了。
 
Branch is not evil
 
虽然long lived branch是一种不好的实践，但branch作为一种轻量级的代码隔离技术还是非常有价值的。比如在分布式版本控制系统里，我们不用再依赖某个中心服务器，可以进行独立的开发和commit。比如在一些探索性任务上，我们可以开启branch进行大胆的尝试。
 
技术用的对不对，还是要看上下文。
 
[参考文献]
 
Long-lived-branches-with-gitflow in radar: https://www.thoughtworks.com/radar/techniques/long-lived-branches-with-gitflow
Gitflow in radar: https://www.thoughtworks.com/radar/techniques/gitflow
Feature Branching in radar: https://www.thoughtworks.com/radar/techniques/feature-branching
Fowler on feature branch: http://martinfowler.com/bliki/FeatureBranch.html
Fowler on continuous integration: http://www.martinfowler.com/articles/continuousIntegration.html
Paul Hammant on TBD: http://paulhammant.com/2015/12/13/trunk-based-development-when-to-branch-for-release/
Google's Scaled Trunk Based Development: http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/
Trunk Based Development at Facebook: http://paulhammant.com/2013/03/04/facebook-tbd/
Fowler on feature toggle: http://martinfowler.com/bliki/FeatureToggle.html
Jez Humble on branch by abstraction:http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
Fowler on branch by abstraction: http://martinfowler.com/bliki/BranchByAbstraction.html

 
目录标题
 
Git Flow
主要分支
master
develop
   
支撑性分支
feature
release
hotfix
   
小结
  
规范化提交
commit message格式
Commit Message Header
Commit Message Body（可选）
Commit Message Footer（可选）
   
好处
 

 
Git Flow
 
就像代码需要代码规范一样，代码管理同样需要一个清晰的流程及规范。
 
如何开始一个新特性的开发，而不影响阻塞其他特性开发？
分支多了如何管理，时间久了，如何知道每个分支是干什么的？
哪些分支已经合并回了主干？
如何进行Release的管理？开始一个Release的时候和另外正在开发的Feature冲突如何解决, 预发布如何才能不阻塞新的功能的开发？
线上代码出Bug了，如何进行修复管理？
 
Git Flow是Vincent Driessen在2010年提出的一个Git 管理模型，如图。
 
 
GitFlow包括如图五种分支
 
master
develop
feature
release
hotfix
 
以上图已经算把Git Flow的核心思想囊括在内了，看懂了上图，也就明白了Git Flow。
 
下面我们一一进行详解。
 
主要分支
 
master
 
master分支在该模型指一个生产环境分支，或者说是一个交付分支，不允许直接在分支上进行修改提交，只允许merge，且每次merge都应该当打上tag记录版本号。
 
develop
 
develop为主开发分支，包含最新的预发布的功能代码。该分支主要合并自其他分支，如Feature。
 
支撑性分支
 
其他三种都是支撑性、功能性、临时性的分支。
 
feature
 
创建自：develop，必须合并回：develop，命名:feature/xxxxx。，合并方式，注意–no–ff
 
 
feature用于开发一些后期会做版本发布的新功能，一旦开发完成，我们应当合并回Develop分支，并且删除该feature分支。
 
或者直接不合并直接删除（开发出来结果不理想或者需求变更）。
 
feature 在标准 Git Flow模型中只作为一个local本地分支，不需要推送至origin远端分支，当然如果为了多人协作考虑，不需要严格遵守。
 
release
 
创建自：develop，必须合并回：master、develop，命名:release/xxxxx。
 
当我们一个或多个feature分支开发完成并合并回develop分支时，你认为可以进行版本发布了，这个时候我们就可以根据develop分支创建release进行release流程，分支名为release，但是实际上他叫pre release更为合适。
 
这个分支上一般是没啥东西的提交，更多的是要求我们做版本发布前的基础自测，并可以在该分支上对自测发现的问题进行bug fix，不允许进行在该分支进行新特性开发，自测没问题了就可以并入devlop和master分支，在该分支做的bug修复可持续性集成回develop分支，不需要跟master一样确认无误才合并，同样–no–ff，对master分支打tag。
 
hotfix
 
创建自：master，必须合并回：master、develop，命名:hotfix/xxxxx。
 
hotfix和release比较类似，都是为了新交付版本发布做准备，不过release属于计划内正常的发布，而hotfix这更多是在生产环境出现严重bug需要尽快紧急修复,同时develop分支尚不稳定，无法支撑一次release发布，也没有正在进行的release分支，这是我们可以从master拉取一个hotfix分支就此bug进行修复。
 
同理在hotfix只允许进行bug以及打版本号之类的操作。修复完合并回master、develop。
 
小结
 
Git Flow通过使用创建分支，以获得并行互不冲突的开发环境，并且通过规范化的管理方式，管控这些临时分支命名、合并方式、生命周期等。
 
总的来说，Git Flow 并不是什么复杂的东西，只是让大家形成一个共同的思维模型，以达到形成一个更易于管理、易于理解的git仓库的目的。
 
规范化提交
 
Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。
 
目前市场上，有多种Commit message 的写法规范，我们目前推行的angular规范，该规范目前是使用比较广泛的写法之一。
 
commit message格式
 
每次提交，提交都应当包含三部分，标题，主体、脚注
 
<type>(<scope>): <subject>   // header   必须
// 空一行
<body>                       //body     可选
// 空一行
<footer>                     //footer   可选
 
Commit Message Header
 
单行，包含三个字段type（必须），scope（可选），subject（必须）
 
<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸  commit 目的的简短描述，不超过50个字符，以动词开头
  │       │
  │       └─⫸ Commit Scope: 说明 commit 影响的范围，比如网络层、前处理层、推理层等等，视项目定义不同自行划分。
  │  
  │
  └─⫸ Commit Type: feat|fix|docs|style|perf|refactor|test|build|ci|
 
type划分：
 
feat：引入新功能(feature)
fix：修补bug
docs：添加或更新文档(documentation)
style： 格式调整（不影响代码运行的变动，空格，花括号换行）
perf: 性能提升的代码更改(performance)
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试代码用例
build：依赖调整，影响构建系统、或者外部依赖第三方库的更改
ci：持续集成CI、CD的配置文件或者脚本的更改
chore：不属于之上范畴的其他不修改源文件及测试文件的其他杂项更改
 
Commit Message Body（可选）
 
相比head，更为清晰详细的说明，比如解释为什么做提交，以及改动影响了什么，代码思路等等等等，可以多行，注意一行不要超过70字
 
Commit Message Footer（可选）
 
脚注主要用来关联issues，对于gitlab之类的平台可以用commit关联并自动关闭issues。
 
还可以写一些 BREAKING CHANGE，描述一些与之前冲突不兼容的改动。
 
BREAKING CHANGE: 大概描述
// 空一行
<详细描述以及迁移指南>
// 空一行
// 空一行
Fixes #<issue number>  //github、gitlab等平台，在commit合并到master会自动关闭对应issue
 
好处
 
 
结构清晰，方便浏览，
更好的根据msg提供过滤选项快速查找信息，例如git log --pretty=oneline --grep feat: 过滤出全部feat类commit
可以根据commit信息生成changelog