Gitflow工作流程 - Jeffery-Zou - 博客园

标签: | 发表时间:2020-03-13 20:44 | 作者:
出处:https://www.cnblogs.com

在工作场合实施 Git的时候,有很多种工作流程可供选择,此时反而会让你手足无措。本文罗列了企业团队最常用的一些 git工作流程,包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。愿以此文抛砖引玉。

在你开始阅读之前,请记住:这些流程应被视作为指导方针,而非“铁律”。我们只是想告诉你可能的做法。因此,如果有必要的话,你可以组合使用不同的流程。

(本文主要介绍Gitflow Workflow……)

imgimg

Vincent Driessen曾经写过一篇博文,题为“ A successful Git branching model”(一个成功的Git分支模型)。Gitflow工作流程就是从这篇文章里来的。

Gitflow工作流程围绕项目发布定义了严格的分支模型。尽管它比Feature Branch Workflow更复杂一些,但它也为管理更大规模的项目提供了坚实的框架。

与Feature Branch Workflow比起来,Gitflow流程并没有增加任何新的概念或命令。其特色在于,它为不同的分支分配了非常明确的角色,并且定义了使用场景和用法。除了用于功能开发的分支,它还使用独立的分支进行发布前的准备、记录以及后期维护。当然,你还是能充分利用Feature Branch Workflow的好处:拉拽请求(Pull Request)、隔离的试验以及更高效率的合作。

它是怎么工作的?

Gitflow流程仍然使用一个中央代码仓库,它是所有开发者的信息交流中心。跟其他的工作流程一样,开发者在本地完成开发,然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。

用于记录历史的分支

Gitflow使用两个分支来记录项目开发的历史,而不是使用单一的master分支。在Gitflow流程中,master只是用于保存官方的发布历史,而develop分支才是用于集成各种功能开发的分支。使用版本号为master上的所有提交打标签(tag)也很方便。

imgimg

事实上,Gitflow流程就是围绕这两个特点鲜明的分支展开的。

用于功能开发的分支

每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作,这种分支也可以被推送到中央仓库。但是,在创建新的功能开发分支时,父分支应该选择develop(而不是master)。当功能开发完成时,改动的代码应该被合并(merge)到develop分支。功能开发永远不应该直接牵扯到master。

imgimg

注意:组合使用功能开发分支和develop分支的这种设计,其实完全就是Feature Branch Workflow的理念。然而,Gitflow流程并不止于此。且看下文分解。

用于发布的分支

imgimg

一旦develop分支积聚了足够多的新功能(或者预定的发布日期临近了),你可以基于develop分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始,也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug,做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候,这个分支会被合并入master,并且用版本号打上标签。另外,发布分支上的改动还应该合并入develop分支——在发布周期内,develop分支仍然在被使用(一些开发者会把其他功能集成到develop分支)。

使用专门的一个分支来为发布做准备的好处是,在一个团队忙于当前的发布的同时,另一个团队可以继续为接下来的一次发布开发新功能。这也有助于清晰表明开发的状态,比如说,团队在汇报状态时可以轻松使用这样的措辞,“这星期我们要为发布4.0版本做准备。”从代码仓库的结构上也能直接反映出来。常用的一些措辞还有:基于develop新建分支,合并入master;命名规则为:release- 或release/

用于维护的分支

imgimg

发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯一一种可以直接基于master创建的分支。一旦问题被修复了,所做的改动应该被合并入master和develop分支(或者用于当前发布的分支)。在这之后,master上还要使用更新的版本号打好标签。

这种为解决紧急问题专设的绿色通道,让团队不必打乱当前的工作流程,也不必等待下一次的产品发布周期。你可以把用于维护的分支看成是依附于master的一种特别的发布分支。

举例说明 \

下面的例子将演示Gitflow流程如何被用来管理一次产品发布。假设你已经创建好了一个中央仓库。

1. 创建develop分支

imgimg

第一步是给默认的master配备一个develop分支。一种简单的做法是:让一个开发者在本地建立一个空的develop分支,然后把它推送到服务器。

git branch develop            
git push -u origin develop

develop分支将包含项目的所有历史,而master会是一个缩减版本。现在,其他开发者应该克隆(clone)中央仓库,并且为develop创建一个追踪分支。

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

到现在,所有人都把包含有完整历史的分支(develop)在本地配置好了。

2. 小马和小明开始开发新功能

imgimg

我们的故事从小马和小明要分别开发新功能开始。他们俩各自建立了自己的分支。 注意,他们在创建分支时,父分支不能选择master,而要选择develop。

git checkout -b some-feature develop            

他们俩都在自己的功能开发分支上开展工作。通常就是这种Git三部曲:edit,stage,commit:

git status            
git add <some-file>
git commit

3. 小马把她的功能开发好了

imgimg

在提交过几次代码之后,小马觉得她的功能做完了。如果她所在的团队使用“拉拽请求”,此刻便是一个合适的时机——她可以提出一个将她所完成的功能合并入develop分支的请求。要不然,她可以自行将她的代码合并入本地的develop分支,然后再推送到中央仓库,像这样:

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

第一条命令确保了本地的develop分支拥有最新的代码——这一步必须在将功能代码合并之前做! 注意,新开发的功能代码永远不能直接合并入master。必要时,还需要解决在代码合并过程中的冲突。

4. 小马开始准备一次发布

imgimg

尽管小明还在忙着开发他的功能,小马却可以开始准备这个项目的第一次正式发布了。类似于功能开发,她使用了一个新的分支来做产品发布的准备工作。在这一步,发布的版本号也最初确定下来。

git checkout -b release-0.1 develop            

这个分支专门用于发布前的准备,包括一些清理工作、全面的 测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似,不同之处在于它是专为产品发布服务的。

一旦小马创建了这个分支并把它推向中央仓库,这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。

5. 小马完成了发布

imgimg

一切准备就绪之后,小马就要把发布分支合并入master和develop分支,然后再将发布分支删除。 注意,往develop分支的合并是很重要的,因为开发人员可能在发布分支上修复了一些关键的问题,而这些修复对于正在开发中的新功能是有益的。再次提醒一下,如果小马所在的团队强调代码评审(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服务器能为产品发布进行一次自动的构建。

6. 用户发现了一个bug

imgimg

当一次发布完成之后,小马便回去与小明一起开发其他功能了。突然,某个用户提出抱怨说当前发布的产品里有一个bug。为了解决这个问题,小马(或者小明)基于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

原文链接: https://www.atlassian.com/git/workflows#!workflow-gitflow

 
本文作者:happydeer
原文链接:http://blog.csdn.net/happydeer/article/details/17618935
版权归作者所有,转载请注明出处

相关 [gitflow 工作流程 jeffery] 推荐:

Gitflow工作流程 - Jeffery-Zou - 博客园

- -
Git的时候,有很多种工作流程可供选择,此时反而会让你手足无措. 本文罗列了企业团队最常用的一些. git工作流程,包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow. 在你开始阅读之前,请记住:这些流程应被视作为指导方针,而非“铁律”.

拥抱 GitFlow,优化开发流程:团队协作的最佳实践

- - 掘金 架构
在软件开发领域,良好的团队协作和高效的版本控制流程对项目的成功至关重要. 在过去的几年里,GitFlow 成为了一种备受推崇的工作流模式,为团队提供了一种清晰而灵活的方式来管理代码库和开发过程. 无论是小型团队还是大规模项目,GitFlow 都被证明是优化团队协作和版本控制流程的理想选择. GitFlow 相比于传统的版本控制流程,如单一分支或简单分支管理,具有一些明显的优势.

OAuth 2.0 工作流程

- - 企业架构 - ITeye博客
原文链接:http://www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.3/com.ibm.ammob.doc_8.0.0.3/config/concept/con_oauth20_workflow.html%23con_oauth20_workflow?lang=zh.

理解Git的工作流程

- - 博客 - 伯乐在线
如果你不理解Git的设计动机,那你就会处处碰壁. 知道足够多的命令和参数后,你就会强行让Git按你想的来工作,而不是按Git自己的方式来. 这就像把螺丝刀当锤子用;也能把活干完,但肯定干的差极了,花费很长时间,还会弄坏螺丝刀. 想想常见的Git工作流程是怎么失效的吧. 从Master创建一个分支,写代码,然后把这个分支合并回Master.

苹果产品开发的绝密工作流程

- - 互联网的那点事...
长期以来苹果产品开发流程在很多方面都笼罩着一层神秘的面纱,而在Adam Lashinsky新发行的 《Inside Apple: How America’s Most Admired–and Secretive–Company Really Works》一书中对这些流程有所涉及. 这本书同时谈论了苹果公司各个不同的方面,包括其理念、招聘流程以及传说中的秘密等等.

简化工作流程,10款必备的HTML5开发工具

- - 博客园_新闻
英文原文: 10 Best HTML5 Development Tools For Web Developers to Streamline Their Workflow. 利用 HTML5 工具不仅可以帮助设计师和开发者创建更具吸引力的网站,还能增加网站的可用性和可访问性. 本文收集了 10 款 HTML5 开发工具让你在网页中搭建特效、动画、视频、音频等诸多功能,为你节省更多开发时间.

Git 工作流程 - 阮一峰的网络日志

- -
Git 作为一个源码管理系统,不可避免涉及到多人协作. 协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去. "工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡. 本文介绍三种广泛使用的工作流程:.

Git 分支管理策略与工作流程

- - IT瘾-dev
Git 是目前世界上最先进的分布式版本控制系统. 它使我们更方便的跟踪,管理和组织代码. 也帮助了我们更好的与其他开发者进行协作开发. 协作开发必须有一个规范来约束各个贡献者的行为. 这个规范就是 Git 工作流程(Git Workflow),也为我们规范各个分支管理策略等行为. Git 工作流程是有关如何使用 Git 以高效协作开发的规则或策略建议,下文这些常见工作流程只是作为指导参考,这些工作流不是一成不变的,我们应该根据自己的项目选择或制定合适自己的工作流.

交互设计在产品设计中的工作流程小议

- - 互联网分析沙龙
当产品的用户体验要求越来越高时,交互设计师的职责也越来越明晰了. 交互设计师除了自身的基本功外,还需要有一个规范的流程,才能够使工作完整有序. 图1 交互设计在产品设计中的流程图. 版本计划是指在产品或项目立项时,对产品的一个总的规划,通常包括产品的需求与目标,比如能够实现哪些功能,性能上如何. 这一过程,交互很少直接参与,或者列席一下发版立项,对计划情况有所知晓.