Gitflow 工作流程围绕项目发布定义了严格的分支模型。尽管它比 Feature Branch Workflow 更复杂一些,但它也为管理更大规模的项目提供了坚实的框架。
与 Feature Branch Workflow 比起来,Gitflow 流程并没有增加任何新的概念或命令。其特色在于,它为不同的分支分配了非常明确的角色,并且定义了使用场景和用法。除了用于功能开发的分支,它还使用独立的分支进行发布前的准备、记录以及后期维护。当然,你还是能充分利用 Feature Branch Workflow 的好处:拉拽请求(Pull Request)、隔离的试验以及更高效率的合作。
流程仍然使用一个中央代码仓库,它是所有开发者的信息交流中心。跟其他的工作流程一样,开发者在本地完成开发,然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。
用于记录历史的分支
Gitflow 使用两个分支来记录项目开发的历史,而不是使用单一的 master 分支。在 Gitflow 流程中,master 只是用于保存官方的发布历史,而 develop 分支才是用于集成各种功能开发的分支。使用版本号为 master 上的所有提交打标签(tag)也很方便。
事实上,Gitflow 流程就是围绕这两个特点鲜明的分支展开的。
用于功能开发的分支
每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作,这种分支也可以被推送到中央仓库。但是,在创建新的功能开发分支时,父分支应该选择 develop(而不是 master)。当功能开发完成时,改动的代码应该被合并(merge)到 develop 分支。功能开发永远不应该直接牵扯到 master。
用于发布的分支
一旦 develop 分支积聚了足够多的新功能(或者预定的发布日期临近了),你可以基于 develop 分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始,也意味着本次发布不会再增加新的功能——在这个分支上只能修复 bug,做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候,这个分支会被合并入 master,并且用版本号打上标签。另外,发布分支上的改动还应该合并入 develop 分支——在发布周期内,develop 分支仍然在被使用(一些开发者会把其他功能集成到 develop 分支)。使用专门的一个分支来为发布做准备的好处是,在一个团队忙于当前的发布的同时,另一个团队可以继续为接下来的一次发布开发新功能。
用于维护的分支
发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯一一种可以直接基于 master 创建的分支。一旦问题被修复了,所做的改动应该被合并入 master 和 develop 分支(或者用于当前发布的分支)。在这之后,master 上还要使用更新的版本号打好标签。
创建 develop 分支
第一步是给默认的 master 配备一个 develop 分支。一种简单的做法是:让一个开发者在本地建立一个空的 develop 分支,然后把它推送到服务器。
- git branch develop git push - u origin develop
develop 分支将包含项目的所有历史,而 master 会是一个缩减版本。现在,其他开发者应该克隆(clone)中央仓库,并且为 develop 创建一个追踪分支。
- git clone ssh: //user@host/path/to/repo.git
- git checkout - b develop origin / develop
A 和 B 开发新功能
分别开发新功能开始。他们俩各自建立了自己的分支。注意,他们在创建分支时,父分支不能选择 master,而要选择 develop。
- git checkout - b some - feature develop
他们俩都在自己的功能开发分支上开展工作。通常就是这种 Git 三部曲:edit,stage,commit:
- git status git add < some - file > git commit
A 把他的功能开发好了
在提交过几次代码之后,A 觉得他的功能做完了。如果她所在的团队使用 "拉拽请求",此刻便是一个合适的时机——她可以提出一个将她所完成的功能合并入 develop 分支的请求。要不然,她可以自行将她的代码合并入本地的 develop 分支,然后再推送到中央仓库,像这样:
- git pull origin develop git checkout develop git merge some - feature git push git branch - d some - feature
第一条命令确保了本地的 develop 分支拥有最新的代码——这一步必须在将功能代码合并之前做!注意,新开发的功能代码永远不能直接合并入 master。必要时,还需要解决在代码合并过程中的冲突。
A 开始准备一次发布
尽管 B 还在忙着开发他的功能,A 却可以开始准备这个项目的第一次正式发布了。类似于功能开发,她使用了一个新的分支来做产品发布的准备工作。在这一步,发布的版本号也最初确定下来。
- git checkout - b release - 0.1 develop
这个分支专门用于发布前的准备,包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似,不同之处在于它是专为产品发布服务的。
一旦 A 创建了这个分支并把它推向中央仓库,这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。
A 完成了发布
一切准备就绪之后,A 就要把发布分支合并入 master 和 develop 分支,然后再将发布分支删除。注意,往 develop 分支的合并是很重要的,因为开发人员可能在发布分支上修复了一些关键的问题,而这些修复对于正在开发中的新功能是有益的。再次提醒一下,如果 A 所在的团队强调代码评审(Code Review),此时非常适合提出这样的请求。
- 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,你都应该随即打上合适的标签。
- git tag - a 0.1 - m "Initial public release"master git push--tags
Git 支持钩子(hook)的功能,也就是说,在代码仓库里某些特定的事件发生的时候,可以执行一些预定义的脚本。因此,一种可行的做法是:在服务器端配置一个钩子,当你把 master 推送到中央仓库或者推送标签时,Git 服务器能为产品发布进行一次自动的构建。
用户发现了一个 bug
当一次发布完成之后,A 便回去与 B 一起开发其他功能了。突然,某个用户提出抱怨说当前发布的产品里有一个 bug。为了解决这个问题,A(或者 B)基于 master 创建了一个用于维护的分支。她在这个分支上修复了那个 bug,然后把改动的代码直接合并入 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
上面介绍的是 git flow 的详细过程,但是这样开发起来会接的是否麻烦,git flow 对其进行了封装简化。
- git flow init
这个命令会进行一些默认的配置,可以自动创建上面介绍的所有分支:master、develop、feature、relase、hotfix 等分支。
完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始:
当进行新功能开发的时候:
- git flow feature start some_awesome_feature
完成功能开发之后:
- git flow feature finish some_awesome_feature
该命令将会把 feature/some_awesome_feature 合并到 develope 分支,然后删除功能 (feature) 分支。
将一个 feature 分支推到远程服务器
- git flow feature publish some_awesome_feature或者git push origin feature / some_awesome_feature
当你的功能点都完成时(需要发布新版本了),就基于 develop 创建一个发布 (release) 分支。
- git flow release start v0.1.0
当你在完成(finish) 一个发布分支时,它会把你所作的修改合并到 master 分支,同时合并回 develop 分支,所以,你不需要担心你的 master 分支比 develop 分支更加超前。
当系统出现问题的时候,需要进行紧急修改的时候,就好基于 master 创建一个维护(hotfix)分支。
- git flow hotfix start v0.1.0
当你在完成(finish) 一个维护分支时,它会把你所作的修改合并到 master 分支,同时合并回 develop 分支。
参考博客:http://www.cnblogs.com/cnblogsfans/p/5075073.html
来源: http://www.cnblogs.com/lcngu/p/5770288.html