功能分支工做流

1.概述

一旦你玩转了集中式工做流，在开发过程当中能够很简单地加上功能分支，用来鼓励开发者之间协做和简化交流。

功能分支工做流背后的核心思路是全部的功能开发应该在一个专门的分支，而不是在 master 分支上。这个隔离能够方便多个开发者在各自的功能上开发而不会弄乱主干代码。另外，也保证了 master 分支的代码必定不会是有问题的，极大有利于集成环境。

功能开发隔离也让 pull requests 工做流成功可能，pull requests 工做流能为每一个分支发起一个讨论，在分支合入正式项目以前，给其它开发者有表示赞同的机会。另外，若是你在功能开发中有问题卡住了，能够开一个 pull requests 来向同窗们征求建议。这些作法的重点就是，pull requests 让团队成员之间互相评论工做变成很是方便！

2.工做方式

功能分支工做流仍然用中央仓库，而且 master 分支仍是表明了正式项目的历史。但不是直接提交本地历史到各自的本地 master 分支，开发者每次在开始新功能前先建立一个新分支。功能分支应该有个有描述性的名字，好比 animated-menu-items 或 issue-#1061，这样可让分支有个清楚且高聚焦的用途。

在 master 分支和功能分支之间，Git 是没有技术上的区别，因此开发者能够用和集中式工做流中彻底同样的方式编辑、暂存和提交修改到功能分支上。

另外，功能分支也能够（且应该）push 到中央仓库中。这样不修改正式代码就能够和其它开发者分享提交的功能。因为 master 仅有的一个『特殊』分支，在中央仓库上存多个功能分支不会有任何问题。固然，这样作也能够很方便地备份各自的本地提交。

3.Pull Requests

功能分支除了能够隔离功能的开发，也使得经过 Pull Requests 讨论变动成为可能。一旦某个开发完成一个功能，不是当即合并到 master，而是 push 到中央仓库的功能分支上并发起一个 Pull Request 请求去合并修改到 master。在修改为为主干代码前，这让其它的开发者有机会先去 Review 变动。

Code Review 是 Pull Requests 的一个重要的收益，但 Pull Requests 目的是讨论代码一个通用方式。你能够把 Pull Requests 做为专门给某个分支的讨论。这意味着能够在更早的开发过程当中就能够进行 Code Review。好比，一个开发者开发功能须要帮助时，要作的就是发起一个 Pull Request，相关的人就会自动收到通知，在相关的提交旁边能看到须要帮助解决的问题。

一旦 Pull Request 被接受了，发布功能要作的就和集中式工做流就很像了。首先，肯定本地的 master 分支和上游的 master 分支是同步的。而后合并功能分支到本地 master 分支并 push 已经更新的本地 master 分支到中央仓库。

4.示例

下面的示例演示了如何把 Pull Requests 做为 Code Review 的方式，但注意 Pull Requests 能够用于不少其它的目的。

1.小红开始开发一个新功能

在开始开发功能前，小红须要在本地一个独立的分支。使用下面的命令新建一个分支：

git checkout -b marys-feature master   ///// 表示若是分支还不存在则新建分支-b

这个命令检出一个基于 master 名为 marys-feature 的分支，Git 的 -b 选项表示若是分支还不存在则新建分支。这个新分支上，小红按老套路编辑、暂存和提交修改，按须要提交以实现功能：

git status
git add
git commit  将分支提交到远程

 

2.小红要去吃个午餐

早上小红为新功能添加一些提交。去吃午餐前，push 功能分支到中央仓库是很好的作法，这样能够方便地备份，若是和其它开发协做，也让他们能够看到小红的提交。

git push -u origin marys-featurev       ////  选项设置本地分支去跟踪远程-u

 

这条命令 push marys-feature 分支到中央仓库（origin），-u 选项设置本地分支去跟踪远程对应的分支。设置好跟踪的分支后，小红就可使用 git push 命令省去指定推送分支的参数。

3.小红完成功能开发

小红吃完午餐回来，完成整个功能的开发。在合并到 master 以前，她发起一个 Pull Request 让团队的其它人知道功能已经完成。但首先，她要确认中央仓库中已经有她最近的提交：

git push

 

而后，在她的 Git GUI 客户端中发起 Pull Request，请求合并 marys-feature 到 master，团队成员会自动收到通知。Pull Request 很酷的是能够在相关的提交旁边显示评注，因此你能够很对某个变动集提问。

4.小黑收到 Pull Request

小黑收到了 Pull Request 后会查看 marys-feature 的修改。决定在合并到正式项目前是否要作些修改，且经过 Pull Request 和小红来回地讨论。

5.小红再作修改

要再作修改，小红用和功能第一个迭代彻底同样的过程。编辑、暂存、提交并push更新到中央仓库。小红这些活动都会显示在 Pull Request 上，小黑能够断续作评注。

若是小黑有须要，也能够把 marys-feature 分支拉到本地，本身来修改，他加的提交也会同样显示在 Pull Request 上。

6.小红发布她的功能

一旦小黑能够的接受 Pull Request，就能够合并功能到稳定项目代码中（能够由小黑或是小红来作这个操做）：

git checkout master   -- 切换到本地master
git pull     -- 拉取最新master
git pull origin marys-feature   -- 拉取远程某分支到本地master
git push    -- 推送到远程master

 

不管谁来作合并，首先要检出 master 分支并确认是它是最新的。而后执行 git pull origin marys-feature 合并 marys-feature 分支到和已经和远程一致的本地 master 分支。你可使用简单 git merge marys-feature 命令，但前面的命令能够保证老是最新的新功能分支。最后更新的 master 分支要从新 push 回到 origin。

这个过程经常会生成一个合并提交。有些开发者喜欢有合并提交，由于它像一个新功能和原来代码基线的连通符。但若是你偏心线性的提交历史，能够在执行合并时 rebase 新功能到 master 分支的顶部，这样生成一个快进（fast-forward）的合并。

一些 GUI 客户端能够只要点一下『接受』按钮执行好上面的命令来自动化 Pull Request 接受过程。若是你的不能这样，至少在功能合并到 master 分支后能自动关闭 Pull Request。

7.与此同时，小明在作和小红同样的事

当小红和小黑在 marys-feature 上工做并讨论她的 Pull Request 的时候，小明在本身的功能分支上作彻底同样的事。

经过隔离功能到独立的分支上，每一个人均可以自主的工做，固然必要的时候在开发者之间分享变动仍是比较繁琐的。

5.总结

到了这里，希望你发现了功能分支能够很直接地在集中式工做流的仅有的 master 分支上完成多功能的开发。另外，功能分支还使用了 Pull Request，使得能够在你的版本控制 GUI 客户端中讨论某个提交。

功能分支工做流是开发项目异常灵活的方式。问题是，有时候太灵活了。对于大型团队，经常须要给不一样分支分配一个更具体的角色。GitFlow 工做流是管理功能开发、发布准备和维护的经常使用模式。