在团队开发中使用版本控制系统时，达成统一的工作流程很重要。 Git确实可以在各个方面做很多事情，但是如果团队中没有形成特定有效的工作流程，混乱是不可避免的。
基本上可以定义适合自己项目的工作流程，也可以使用别人定义的内容。
在本章中，您将学习当前非常流行的工作流git-flow。
什么是git-flow？ 安装git-flow后，有几个扩展命令。 这些命令按预定义的顺序自动执行多个操作。 是的，这是我们的工作流程！
Git-flow并不能代替Git，而是标准的Git命令的脚本组合。
严格来说，使用千兆流工作流不需要安装任何特殊的内容。 您只需要知道哪些工作流由哪些具体任务组成，哪些工作流附带相应的参数，以及如何以相应的顺序轻松执行相应的Git命令。 当然，使用git-flow脚本会很方便。 你不需要记住这些命令和顺序。
近年来有各种各样的安装方法来安装git-flow。 本章使用当前最流行的AVH Edition。
有关安装千兆流的详细信息，请阅读以下文档official documentation :
如果您想在项目中设置Git-flow hxsdc，然后将您的项目“切换”到git-flow，git可以像往常一样工作。 这取决于是在仓库中使用特殊的Git-flow命令还是普通的git命令。 也就是说，git-flow不会戏剧性地改变你的仓库。
尽管如此，git-flow有一些限制。 用新项目初始化那个吧。 在那之后，我们发现：
$ gitflowinitinitializedemptygitrepositoryin/users/tobi/acme-website/. git/branchnameforproductionreleases 3360 [ ] Feature branches？ [feature/]Release branches？ [release/]Hotfix branches？ 在[hotfix/]项目的根目录下运行" git flow init "命令时，交互式安装助手将引导您完成此初始化操作。 是否已经包含git flow init命令并不重要。 听起来有点华丽，但实际上只是在你的分支上配置了命名规则。
尽管如此，这个安装助手还是允许你使用你喜欢的名字。 强烈建议使用默认命名机制，并逐步确定。
gitflow的分支模式在git-flow模式下，缺省情况下有两个主分支位于仓库中。
master只能用于包含产品代码。 你不是直接在这个主分支上工作，而是在其他指定的、独立的特性分支上工作。 不直接将变更提交到主分支也是许多工作流的通用规则。develop是你进行新开发的基础分支。 当hxsdc发起新的功能分支时，它是_开发_的基础。 另外，该分支也收集已经完成的所有功能，等待合并到主分支中。
这两个分支被称为长期分支。 这些都活在项目的整个生命周期中。 其他分支，例如对功能的分支、对发行的分支，只是暂时存在。 它们将根据需要创建，并在自己的任务完成后被删除。
探索几个在现实APP中可能遇到的案例吧！
功能开发对开发者来说，最常见的工作可能是功能的开发。 所以，git-flow定义了很多功能开发的工作流程，有助于有组织地完成它。
开始开发新功能“rss-feed”吧。
$ gitflowfeaturestartrss-feedswitchedtoanewbranch ' feature/RSS-feed ' summary of actions 3360-anew branch ' feature/RSS based on ' develop '-youarenowonbranch ' feature/RSS-feed '概念在这些命令的输出文本中，git-flow会打印刚完成的操作的摘要
当hxsdc需要帮助时，可以随时求助。 例如：
$ git flow feature help与上面的新功能一样，git-flow将创建一个名为“feature/rss-feed”的分支。 此" feature/"前缀是可配置的选项设置。 你已经知道了。 在你开发新功能的时候使用1
个独立的分支是版本控制中最重要的规则之一。git-flow 也会直接签出这个新的分支，这样你就可以直接进行工作了。 完成一个功能
经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：
$ git flow feature finish rss-feedSwitched to branch 'develop'Updating 6bcf266..41748adFast-forward feed.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 feed.xmlDeleted branch feature/rss-feed (was 41748ad).最重要的是，这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：
一个在更广泛的 “开发” 背景下的全面测试。稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。
管理 releasesRelease 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。
创建 releasehxsdc认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：
$ git flow release start 1.1.5Switched 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” 分支流程都是不恰当的）。
这个命令会创建一个名为 “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 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。hxsdc能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。