Git工作流指南

Git工作流指南：Gitflow工作流.2vo_-、/ XJ丿今【丿7、这节介绍的Gitflow工作流借鉴自在nvie的 Vincent Driessen。Gitflow 工作流定义了一个围绕项目发布的严格分支模型。虽然t比功能分支工作流复 杂几分，但提供了用于一个健壮的用于管理大型项目的框架。Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一 个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做 准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处： Pull Requests、 隔离实验性开发和更高效的协作。工作方式Gitflow 工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样， 开发者在本地工作并push分支到要中央仓库中。历史分支相对使用仅有的一个 master 分支Gitflow工作流使用2个分支来记录项目的历史。 master 分支存储了正式发布的历史，而develop分支作为功能的集成分支。这样也 方便 master 分支上的所有提交分配一个版本号。v01v0.2心IDevelop00剩下要说明的问题围绕着这2个分支的区别展开。功能分支每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。但功能分 支不是从 master 分支上拉出新分支，而是使用develop分支作为父分支。当新功能 完成时，合并回 develop 分支。新功能提交应该从不直接与 master 分支交互。Featurev0.2V10MasterDevelopFeature注意，从各种含义和目的上来看，功能分支加上develop分支就是功能分支工作流的 用法。但Gitflow工作流没有在这里止步。发布分支MasterReleaseDevelopFeatureFeature一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就 从develop分支上fork 发布分支。新建的分支用于开始发布循环，所以从这个 时间点开始之后新的功能不能再加到这个分支上这个分支只应该做Bug修复、 文档生成和其它面向发布任务。一旦对外发布的工作都完成了发布分支合并到master分支并分配一个版本号打好Tag另外，这些从新建发布分支以来的做的修改要合并回develop 分支。使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时， 另一个团队可以继续开发下个版本的功能。这也打造定义良好的开发阶段（比如，可以很轻松地说，这周我们要做准备发布版本 4.0，并且在仓库的目录结构中可以实际看到）。常用的分支约定:用于新建发布分支的分支：develop 用于合并的分支：master分支命名：release-* 或 release/*维护分支FeatureMasterHotfixReleaseDevelopFeature维护分支或说是热修复（hotfix ）分支用于生成快速给产品发布版本（productionreleases ）打补丁，这是唯一可以直接从master分支fork出来的分支。修复完成， 修改应该马上合并回 master 分支和 develop 分支（当前的发布分支） ，master 分 支应该用新的版本号打好Tag。为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一 个发布循环。你可以把维护分支想成是一个直接在 master 分支上处理的临时发布。示例下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓 库。创建开发分支第一步为 master 分支配套一个develop分支。简单来做可以本地创建一个空的develop 分支 ，push 到服务器上：git branch developgit push -u origin develop以后这个分支将会包含了项目的全部历史，而 master 分支将只包含了部分历史。其它 开发者这时应该克隆中央仓库，建好develop分支的跟踪分支:git clone ssh:/userhost/path/to/repo.gitgit checkout -b develop origin/develop现在每个开发都有了这些历史分支的本地拷贝。小红和小明开始开发新功能这个示例中小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于 master 分支，而是应该基于develop分支:git checkout -b some-feature develop他们用老套路添加提交至U各自功能分支上：编辑、暂存、提交:git statusgit addgit commit小红完成功能开发添加了提交后，小红觉得她的功能0K了。如果团队使用 Pull Requests , 这时候可 以发起一用于合并到develop分支。否则她可以直接合并到她本地的develop分 支后 push 到中央仓库：git pull origin developgit checkout developgit merge some-featuregit pushgit branch -d some-feature第一条命令在合并功能前确保develop分支是最新的。注意，功能决不应该直接合并 到master分支。冲突解决方法和集中式工作流一样。小红开始准备发布这个时候小明正在实现他的功能，小红开始准备她的第一个项目正式发布。像功能开发一样，她用一个新的分支来做发布准备。这一步也确定了发布的版本号：git checkout -b release-0.1 develop这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方， 像是一个专门用于改善发布的功能分支。只要小红创建这个分支并push到中央仓库，这个发布就是功能冻结的。任何不在 develop 分支中的新功能都推到下个发布循环中。小红完成发布一旦准备好了对外发布，小红合并修改到master分支和develop分支上，删除发布 分支。合并回develop分支很重要，因为在发布分支中已经提交的更新需要在后面的 新功能中也要是可用的。另外如果小红的团队要求 Code Review 这是一个发起Pull Request 的理想时机。git checkout mastergit merge release-0.1git pushgit checkout developgit merge release-0.1git pushgit branch -d release-0.1 发布分支是作为功能开发（ develop 分支）和对外发布（ master 分支）间的缓冲。 只要有合并到 master 分支，就应该打好Tag以方便跟踪。git tag -a 0.1 -m Initial public release mastergit push -tagsGit有提供各种勾子（hook ），即仓库有事件发生时触发执行的脚本。可以配置一个 勾子，在你push中央仓库的master分支时，自动构建好对夕卜发布。最终用户发现Bug对外发布后，小红回去和小明一起做下个发布的新功能开发，直到有最终用户开了一个 Ticket 抱怨当前版本的一个Bug。为了处理Bug，小红（或小明）从master分支上 拉出了一维护分支，提交修改以解决问题，然后直接合并回master分支：/、git checkout -b issue-#001 masterFix the buggit checkout master git merge issue-#001 git push/、就像发布分支，维护分支中新加这些重要修改需要包含到develop分支中，所以小红 要执行一个合并操作。然后就可以安全地删除这个分支了：git checkout developgit merge issue-#001git pushgit branch -d issue-#001下一站到了这里，但愿你对集中式工作流、功能分支工作流和 Gitflow 工作流已经感觉很舒 适了。你应该也牢固的掌握了本地仓库的潜能，push/pull模式和Git健壮的分支和 合并模型。记住，这里演示的工作流只是可能用法的例子，而不是在实际工作中使用Git不可违 逆的条例。所以不要畏惧按自己需要对工作流的用法做取舍。不变的目标就是让Git 为你所用