SourceTree 实现 git flow 流程

为何使用 git 和 git flow，这篇文章 深刻理解学习Git工做流 的内容相信可以给你一个完整的答案。

• 咱们以使用SVN的工做流来使用git有什么不妥？
• git 方便的branch在哪里，团队多人如何协做？冲突了怎么办？如何进行发布控制？
• 经典的master-发布、develop-主开发、hotfix-不过修复如何避免代码不通过验证上线？
• 如何在github上面与他人一块儿协做，star-fork-pull request是怎样的流程？

这篇文章分为两部分，一部分引用 深刻理解学习Git工做流 文章中的 git flow 工做流内容，一部分是使用 SourceTree 中的 git flow 工具来实现可视化的 git flow 流程管理，避免咱们在使用 git 命令时遇到的坑。并且 SourceTree 的全部可视化操做都会展现相应的执行命令。

SourceTree Win10 安装过程及配置

Gitflow 工做流

Gitflow工做流经过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些很是必要的结构。

这节介绍的Gitflow工做流借鉴自在nvie的Vincent Driessen。

Gitflow工做流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工做流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。

Gitflow工做流没有用超出功能分支工做流的概念和命令，而是为不一样的分支分配一个明确的角色，并定义分支之间如何和何时进行交互。
除了使用功能分支，在作准备、维护和记录发布时，也定义了各自的分支。
固然你能够用上功能分支工做流全部的好处：Pull Requests、隔离实验性开发和更高效的协做。

2.3.1 工做方式

Gitflow工做流仍然用中央仓库做为全部开发者的交互中心。和其它的工做流同样，开发者在本地工做并push分支到要中央仓库中。

2.3.2 历史分支

相对于使用仅有的一个master分支，Gitflow工做流使用两个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支做为功能的集成分支。
这样也方便master分支上的全部提交分配一个版本号。

剩下要说明的问题围绕着这2个分支的区别展开。

2.3.3 功能分支

每一个新功能位于一个本身的分支，这样能够push到中央仓库以备份和协做。
但功能分支不是从master分支上拉出新分支，而是使用develop分支做为父分支。当新功能完成时，合并回develop分支。
新功能提交应该从不直接与master分支交互。

注意，从各类含义和目的上来看，功能分支加上develop分支就是功能分支工做流的用法。但Gitflow工做流没有在这里止步。

2.3.4 发布分支

一旦develop分支上有了作一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。
新建的分支用于开始发布循环，因此从这个时间点开始以后新的功能不能再加到这个分支上——
这个分支只应该作Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工做都完成了，发布分支合并到master分支并分配一个版本号打好Tag。
另外，这些重新建发布分支以来的作的修改要合并回develop分支。

使用一个用于发布准备的专门分支，使得一个团队能够在完善当前的发布版本的同时，另外一个团队能够继续开发下个版本的功能。
这也打造定义良好的开发阶段（好比，能够很轻松地说，『这周咱们要作准备发布版本4.0』，而且在仓库的目录结构中能够实际看到）。

经常使用的分支约定：

用于新建发布分支的分支: develop
用于合并的分支: master 分支命名: release-* 或 release/*

2.3.5 维护分支

维护分支或说是热修复（hotfix）分支用于给产品发布版本（production releases）快速生成补丁，这是惟一能够直接从master分支fork出来的分支。
修复完成，修改应该立刻合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

为Bug修复使用专门分支，让团队能够处理掉问题而不用打断其它工做或是等待下一个发布循环。
你能够把维护分支想成是一个直接在master分支上处理的临时发布。

2.3.6 示例

下面的示例演示本工做流如何用于管理单个发布循环。假设你已经建立了一个中央仓库。

建立开发分支

第一步为master分支配套一个develop分支。简单来作能够本地建立一个空的develop分支，push到服务器上：

git branch develop
git push -u origin develop

之后这个分支将会包含了项目的所有历史，而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库，建好develop分支的跟踪分支：

git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop

如今每一个开发都有了这些历史分支的本地拷贝。

小红和小明开始开发新功能

这个示例中，小红和小明开始各自的功能开发。他们须要为各自的功能建立相应的分支。新分支不是基于master分支，而是应该基于develop分支：

git checkout -b some-feature develop

他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：

git status
git add <some-file>
git commit

小红完成功能开发

添加了提交后，小红以为她的功能OK了。若是团队使用Pull Requests，这时候能够发起一个用于合并到develop分支。
不然她能够直接合并到她本地的develop分支后push到中央仓库：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令在合并功能前确保develop分支是最新的。注意，功能决不该该直接合并到master分支。
冲突解决方法和集中式工做流同样。

小红开始准备发布

这个时候小明正在实现他的功能，小红开始准备她的第一个项目正式发布。
像功能开发同样，她用一个新的分支来作发布准备。这一步也肯定了发布的版本号：

git checkout -b release-0.1 develop

这个分支是清理发布、执行全部测试、更新文档和其它为下个发布作准备操做的地方，像是一个专门用于改善发布的功能分支。

只要小红建立这个分支并push到中央仓库，这个发布就是功能冻结的。任何不在develop分支中的新功能都推到下个发布循环中。

小红完成发布

一旦准备好了对外发布，小红合并修改到master分支和develop分支上，删除发布分支。合并回develop分支很重要，由于在发布分支中已经提交的更新须要在后面的新功能中也要是可用的。
另外，若是小红的团队要求Code Review，这是一个发起Pull Request的理想时机。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

发布分支是做为功能开发（develop分支）和对外发布（master分支）间的缓冲。只要有合并到master分支，就应该打好Tag以方便跟踪。

git tag -a 0.1 -m "Initial public release" master git push --tags

Git有提供各类勾子（hook），即仓库有事件发生时触发执行的脚本。
能够配置一个勾子，在你push中央仓库的master分支时，自动构建好版本，并对外发布。

最终用户发现Bug

对外版本发布后，小红小明一块儿开发下一版本的新功能，直到有最终用户开了一个Ticket抱怨当前版本的一个Bug。
为了处理Bug，小红（或小明）从master分支上拉出了一个维护分支，提交修改以解决问题，而后直接合并回master分支：

git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push

就像发布分支，维护分支中新加这些重要修改须要包含到develop分支中，因此小红要执行一个合并操做。而后就能够安全地删除这个分支了：

git checkout develop
git merge issue-#001 git push git branch -d issue-#001

到了这里，希望你对集中式工做流、功能分支工做流和Gitflow工做流已经感受很温馨了。
你应该也牢固的掌握了本地仓库的潜能，push/pull模式和Git健壮的分支和合并模型。

记住，这里演示的工做流只是可能用法的例子，而不是在实际工做中使用Git不可违逆的条例。
因此不要畏惧按本身须要对工做流的用法作取舍。不变的目标就是让Git为你所用。

---

SourceTree 实现 git flow

经过文章《SourceTree Win10 安装过程及配置》 正确安装 SourceTree 以及管理示例源码，界面以下。

初始化 Git flow

点击右上角的 “Git 工做流” ，初次会提示咱们 “使用 Git Flow 来初始化此仓库”，已经帮助咱们预约义好了一些配置，咱们只须要点击 “肯定” 按钮便可。

点击“肯定”按钮后，咱们会发现 SourceTree 为咱们自动建立了 develop 分支，而且切换到了 develop 分支。

Git flow: 创建新功能

继续点击右上角的 “Git 工做流” ，此次会提示咱们选择具体的下一个流程动做，这里咱们演示一个 “创建新的功能” 流程。

点击 “建议新的功能” ，会让咱们对即将要开发的功能进行命名（名称请使用英文），这里咱们输入 simple-git-flow，点击肯定按钮，会自动帮助咱们建立 feature/simple-git-flow 分支，并切换到该分支上。

同时咱们也能看到 SourceTree 帮助咱们执行了什么命令来达到这样的效果。

已经自动切换到 feature/simple-git-flow 分支。

提交代码

此时咱们能够在分支上开发咱们的新功能，能够在分支上管理代码，而不影响到其余同事的开发工做。

为了简单演示，咱们修改下 readme.md 的内容以下：

在 SourceTree 界面，咱们须要在 未暂存文件 区域选中 readme.md 并点击 暂存所选 按钮，此时 readme.md 文件会进入到 已暂存文件 区域。只有 已暂存文件 的文件会进行 提交操做 。

在下方的空白区域输入本次提交的说明：a simple git flow 后点击提交按钮，就会提交源码。

以下图所示：能够看到刚刚提交的代码记录

完成新功能开发

通过不断的代码完善，而且通过单元测试后，代码已经完成后，此时就能够完成 新功能的开发 ，继续点击 Git 工做流

点击 “完成功能”，默认会以下图所示，在正常的开发流程下，咱们不须要更改任何设置，直接点击肯定便可。

SourceTree 展现所执行的命令及结果。

完成后，咱们会发现 feature/simple-git-flow 分支已经不见了，同时在 develop 分支上多了一个 a simple git flow 的提交信息。

至此整个 “建议新功能” 的 git flow 流程就完毕了。

总结

实际开发过程当中，会遇到各类状况，没法经过简短的文章来讲明全部的状况，具体须要在实践过程当中不断学习。

再次总结下为何要使用 SourceTree

1. 下降入门门槛。不少应届生并不知道版本管理工具和 git，经过可视化工具，能够避免初学者在使用过程当中由于不熟悉命令而产生的问题。
2. 使用 SourceTree 的全部操做，都会展现响应的执行命令，也能让初学者了解到具体的操做是经过什么命令来实现的。
3. 在彻底不熟悉命令的状况下，也能够经过 SourceTree 来参与团队协做开发。

而且在咱们的 Centos 服务器部署中，咱们使用 docker 来管理版本和发布，也基本用不到复杂的 git 命令，对于初学者的快速入门 SourceTree 足够了。