Git开发管理之道


无网不剩无网不剩 Git开发开发管理之道管理之道Git开发开发管理之道管理之道 2010-10-302010-10-30 Git的强大是众所周知的,本文要分享的是关于"使用Git的分支和合并功能来进行版本管理的开发模型"。以下是译Git的强大是众所周知的,本文要分享的是关于"使用Git的分支和合并功能来进行版本管理的开发模型"。以下是译 文,文,原文地址原文地址原文地址原文地址 这篇文章我想介绍一下一年前就提到过的我所有项目(工作/私有)都在使用的开发模式,经过事实验证,确实非常可这篇文章我想介绍一下一年前就提到过的我所有项目(工作/私有)都在使用的开发模式,经过事实验证,确实非常可 行。很早就想写了,一直没腾出时间。我不会涉及项目的细节,只是谈谈分支的使用策略和发布管理。行。很早就想写了,一直没腾出时间。我不会涉及项目的细节,只是谈谈分支的使用策略和发布管理。 上图是使用Git这个版本控制工具来管理所有源码的。上图是使用Git这个版本控制工具来管理所有源码的。 为为什什么么使用使用Git为为什什么么使用使用Git converted by Web2PDFConvert.com 如果要看详细的Git与集中式源码管理工具的优势与劣势,可以参见如果要看详细的Git与集中式源码管理工具的优势与劣势,可以参见这这篇文章篇文章这这篇文章篇文章,那里有很多口水仗。作为一个开发人,那里有很多口水仗。作为一个开发人 员,所有的源码管理工具中,我最喜欢Git。Git从根本上改变了开发人员对分支和合并的使用,传统的CVS/SVN,分支员,所有的源码管理工具中,我最喜欢Git。Git从根本上改变了开发人员对分支和合并的使用,传统的CVS/SVN,分支 和合并都是高级话题,而且使用起来稍显麻烦,隔一段时间才会用一次。但是有了Git,这些操作就成了家常便饭。和合并都是高级话题,而且使用起来稍显麻烦,隔一段时间才会用一次。但是有了Git,这些操作就成了家常便饭。 由于使用简单,方便重复操作,分支和合并不再是让人望而生畏的操作,版本管理工具应该尽可能地对分支/合并提由于使用简单,方便重复操作,分支和合并不再是让人望而生畏的操作,版本管理工具应该尽可能地对分支/合并提 供最好的支持。供最好的支持。 工具谈得差不多了,回到开发上。我待会要讲到的模型其实是一些每个开发人员都应该遵守的步骤,如果想管理好软工具谈得差不多了,回到开发上。我待会要讲到的模型其实是一些每个开发人员都应该遵守的步骤,如果想管理好软 件的开发流程的话。件的开发流程的话。 分布式但集中化分布式但集中化分布式但集中化分布式但集中化 我们要使用的仓库是一个"中心库",当然这个中心库只是被认为是这样(因为Git是分布式的,从技术层面上来说是没我们要使用的仓库是一个"中心库",当然这个中心库只是被认为是这样(因为Git是分布式的,从技术层面上来说是没 有中心库的),我们将把这个仓库叫做"origin",因为Git用户都熟悉这个名字。有中心库的),我们将把这个仓库叫做"origin",因为Git用户都熟悉这个名字。 每个开发者pull和push到origin,但除了中心化的push-pull关系外,每个开发者还可以从其他开发者那pull changes。每个开发者pull和push到origin,但除了中心化的push-pull关系外,每个开发者还可以从其他开发者那pull changes。 比如说,对于一个比较大的新特性,在把代码提交到origin之前,很可能会安排2个或多个开发者。上图中有几个小团比如说,对于一个比较大的新特性,在把代码提交到origin之前,很可能会安排2个或多个开发者。上图中有几个小团 队:Alice和Bob,Alice和David,Clair和David。队:Alice和Bob,Alice和David,Clair和David。 从技术角度来说,其实就是Alice定义了一个叫Bob的Git remote,指向到Bob的仓库。从技术角度来说,其实就是Alice定义了一个叫Bob的Git remote,指向到Bob的仓库。 main分支分支main分支分支 中心仓库有两个分支:中心仓库有两个分支: mastermaster developdevelop origin上的master分支,Git用户应该很熟悉,跟master并行的有一个develop分支origin上的master分支,Git用户应该很熟悉,跟master并行的有一个develop分支 converted by Web2PDFConvert.com 我们把origin/master作为主要分支,源码的HEAD总是表示production-ready(可随时部署)状态。而origin/develop上的我们把origin/master作为主要分支,源码的HEAD总是表示production-ready(可随时部署)状态。而origin/develop上的 代码是为下一次的代码发布准备的。每日构建也是基于此分支。代码是为下一次的代码发布准备的。每日构建也是基于此分支。 当develop分支达到了一个稳定状态并准备发布时,所有的改变都要合并到master分支,并标上版本号。如何实现的当develop分支达到了一个稳定状态并准备发布时,所有的改变都要合并到master分支,并标上版本号。如何实现的 下面细说。下面细说。 这样每次与master合并都会有新的部署发布。这点可以自动化,如使用Git hook脚本来实现自动部署代码到线上。这样每次与master合并都会有新的部署发布。这点可以自动化,如使用Git hook脚本来实现自动部署代码到线上。 支持支持(supporting)分支分支支持支持(supporting)分支分支 我们的开发模型使用了一些支持分支放在master和develop分支的旁边,方便开发小组之间的并行开发。不像main分我们的开发模型使用了一些支持分支放在master和develop分支的旁边,方便开发小组之间的并行开发。不像main分 支,这些分支是有时间限制的,因为他们最终都会被移除。支,这些分支是有时间限制的,因为他们最终都会被移除。 我们会使用到的不同的分支我们会使用到的不同的分支 Feature branchesFeature branches Release branchesRelease branches Hotfix branchesHotfix branches 每个分支都有各自的作用,并且有严格的规定,如:只能从哪个分支上去新开分支,只能合并到那个分支。这个待会每个分支都有各自的作用,并且有严格的规定,如:只能从哪个分支上去新开分支,只能合并到那个分支。这个待会 细说。细说。 Feature branchesFeature branches 继承分支: develop继承分支: develop 合并分支:develop合并分支:develop 命名规范:除了master,develop,release-命名规范:除了master,develop,release-,hotfix-,hotfix- Feature branches是用来开发新特性的(短期,远期都可以)。当开始开发新特性时,很可能不知道这个特性会出现在Feature branches是用来开发新特性的(短期,远期都可以)。当开始开发新特性时,很可能不知道这个特性会出现在 哪个目标版本。一旦开发完成就可以合并到develop,当然如果开发失败,就可以抛弃。哪个目标版本。一旦开发完成就可以合并到develop,当然如果开发失败,就可以抛弃。 创创建一个建一个 Feature branch创创建一个建一个 Feature branch 当要创建一个新特性时,从develop分支上再进行分支当要创建一个新特性时,从develop分支上再进行分支 $$ git checkout -b myfeature develop git checkout -b myfeature develop Switched to a new branch "myfeature"Switched to a new branch "myfeature" converted by Web2PDFConvert.com 新特性完成时,可以合并到develop新特性完成时,可以合并到develop $$ git checkout develop git checkout develop Switched to branch 'develop'Switched to branch 'develop' $$ git merge --no-ff myfeature git merge --no-ff myfeature Updating ea1b82a..05e9557Updating ea1b82a..05e9557 (Summary of changes)(Summary of changes) $$ git branch -d myfeature git branch -d myfeature Deleted branch myfeature (was 05e9557).Deleted branch myfeature (was 05e9557). $$ git push origin develop git push origin develop —no-ff (译者注:no fast foward)标签,使得每一次的合并都创建一个新的commit记录。即使这个commit只是fast-—no-ff (译者注:no fast foward)标签,使得每一次的合并都创建一个新的commit记录。即使这个commit只是fast- foward,这样可以避免丢失信息foward,这样可以避免丢失信息 不幸的是,我没有找到让—no-ff成为commit默认参数的方法(译者注:修改.consolerc?),但确实应该提供一个方法。不幸的是,我没有找到让—no-ff成为commit默认参数的方法(译者注:修改.consolerc?),但确实应该提供一个方法。 Release branchRelease branch 继承分支: develop继承分支: develop 合并分支:develop 和 master合并分支:develop 和 master 命名规范:release-*命名规范:release-* Release branch 是为新的production release准备的(译者注:相当于RC版),可以有一些小的bug,并为发布准备一些Release branch 是为新的production release准备的(译者注:相当于RC版),可以有一些小的bug,并为发布准备一些 元数据(版本号,构建日期等等)。把所有的这些工作都放到 Release branch,develop branch就能更清晰地知道下一元数据(版本号,构建日期等等)。把所有的这些工作都放到 Release branch,develop branch就能更清晰地知道下一 个版本要开发哪些特性。个版本要开发哪些特性。 从develop分支合并到release分支的关键因素是:develop分支达到了release分支所要求的状态。至少所有针对该从develop分支合并到release分支的关键因素是:develop分支达到了release分支所要求的状态。至少所有针对该 release的特性要被合并。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版release的特性要被合并。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版 本号。本号。 创创建一个建一个Release branch创创建一个建一个Release branch Release branch是通过develop分支而创建。举个例子,假如1.1.5是当前的production release,然后会有一个比较大Release branch是通过develop分支而创建。举个例子,假如1.1.5是当前的production release,然后会有一个比较大 的版本发布。develop的状态已经可以发布版本了,经过商榷后,决定发布为1.2版本(而不是1.1.6或2.0),所以我们创的版本发布。develop的状态已经可以发布版本了,经过商榷后,决定发布为1.2版本(而不是1.1.6或2.0),所以我们创 建一个release分支,并给这个分支一个新的版本号建一个release分支,并给这个分支一个新的版本号 $$ git checkout -b release-1.2 develop git checkout -b release-1.2 develop Switched to a new branch "release-1.2"Switched to a new branch "release-1.2" converted by Web2PDFConvert.com $$ ./bump-version.sh 1.2 ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2.Files modified successfully, version bumped to 1.2. $$ git commit -a -m git commit -a -m "Bumped version number to 1.2""Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2[release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)1 files changed, 1 insertions(+), 1 deletions(-) 这个新分支可能会存在一定的时间,直到可以被合并到production branch。这段时间内,bug修补可以在这个分支上这个新分支可能会存在一定的时间,直到可以被合并到production branch。这段时间内,bug修补可以在这个分支上 进行(而不是develop分支)。添加新特性(尤其比较大的)是不允许的。最后还是要被合并到develop,然后继续在进行(而不是develop分支)。添加新特性(尤其比较大的)是不允许的。最后还是要被合并到develop,然后继续在 develop分支上开发,直到下一个版本。develop分支上开发,直到下一个版本。 完成一个完成一个release branch完成一个完成一个release branch 当release branch已经准备就绪,需要做几件事。首先,release分支被合并到master分支上(每一个提交到master上的当release branch已经准备就绪,需要做几件事。首先,release分支被合并到master分支上(每一个提交到master上的 commit都是一个新版本,切记)。然后master上的commit都要添加tag,方便将来查看和回滚。最后release上所做的修commit都是一个新版本,切记)。然后master上的commit都要添加tag,方便将来查看和回滚。最后release上所做的修 改必须合并到develop分支上,保证bug已被修补。改必须合并到develop分支上,保证bug已被修补。 前两个步骤:前两个步骤: $$ git checkout master git checkout master Switched to branch 'master'Switched to branch 'master' $$ git merge --no-ff release-1.2 git merge --no-ff release-1.2 Merge made by recursive.Merge made by recursive. (Summary of changes)(Summary of changes) $$ git tag -a 1.2 git tag -a 1.2 为了把release上的改变保存到develop,我们需要合并到develop为了把release上的改变保存到develop,我们需要合并到develop $$ git checkout develop git checkout develop Switched to branch 'develop'Switched to branch 'develop' $$ git merge --no-ff release-1.2 git merge --no-ff release-1.2 Merge made by recursive.Merge made by recursive. (Summary of changes)(Summary of changes) 这个步骤可能会导致冲突,如果这样的话,解决冲突,然后再提交。这个步骤可能会导致冲突,如果这样的话,解决冲突,然后再提交。 现在一切都完成了,可以把release branch干掉了。现在一切都完成了,可以把release branch干掉了。 $$ git branch -d release-1.2 git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe).Deleted branch release-1.2 (was ff452fe). Hotfix branchHotfix branch 继承分支: master继承分支: master 合并分支:develop 和 master合并分支:develop 和 master 命名规范:hotfix-*命名规范:hotfix-* Hotfix branch和Release branch有几分相似,都是为了新的production release而准备的。比如运行过程中发现了Hotfix branch和Release branch有几分相似,都是为了新的production release而准备的。比如运行过程中发现了 bug,就必须快速解决,这时就可以创建一个Hotfix branch,解决完后合并到master分支上。好处是开发人员可以继bug,就必须快速解决,这时就可以创建一个Hotfix branch,解决完后合并到master分支上。好处是开发人员可以继 续工作,有专人来负责搞定这个bug。续工作,有专人来负责搞定这个bug。 创创建建Hotfix branch创创建建Hotfix branch Hotfix是从master分支上创建的。假如当前运行版本是1.2,然后发现有bug,但是develop还在开发中,不太稳定,这Hotfix是从master分支上创建的。假如当前运行版本是1.2,然后发现有bug,但是develop还在开发中,不太稳定,这 时就可以新开一个Hotfix branch,然后开始解决问题。时就可以新开一个Hotfix branch,然后开始解决问题。 converted by Web2PDFConvert.com $$ git checkout -b hotfix-1.2.1 master git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1"Switched to a new branch "hotfix-1.2.1" $$ ./bump-version.sh 1.2.1 ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1.Files modified successfully, version bumped to 1.2.1. $$ git commit -a -m git commit -a -m "Bumped version number to 1.2.1""Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)1 files changed, 1 insertions(+), 1 deletions(-) 解决问题,一次或几次commit解决问题,一次或几次commit $$ git commit -m git commit -m "Fixed severe production problem""Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem[hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)5 files changed, 32 insertions(+), 17 deletions(-) 完成完成Hotfix branch完成完成Hotfix branch 当结束时,bugfix要被合并到master,同时也要合并到develop,保证下个版本发布时该bug已被修复。这跟release当结束时,bugfix要被合并到master,同时也要合并到develop,保证下个版本发布时该bug已被修复。这跟release branch完成时一样。branch完成时一样。 首先更新master和tag release首先更新master和tag release $$ git checkout master git checkout master Switched to branch 'master'Switched to branch 'master' $$ git merge --no-ff hotfix-1.2.1 git merge --no-ff hotfix-1.2.1 Merge made by recursive.Merge made by recursive. (Summary of changes)(Summary of changes) $$ git tag -a 1.2.1 git tag -a 1.2.1 接下来与develop合并接下来与develop合并 $$ git checkout develop git checkout develop Switched to branch 'develop'Switched to branch 'develop' $$ git merge --no-ff hotfix-1.2.1 git merge --no-ff hotfix-1.2.1 Merge made by recursive.Merge made by recursive. (Summary of changes)(Summary of changes) 有一个例外,就是当一个release branch存在时,bugfix要被合并到release而不是develop,因为release最终会被合并有一个例外,就是当一个release branch存在时,bugfix要被合并到release而不是develop,因为release最终会被合并 到develop。到develop。 最后移除branch最后移除branch $$ git branch -d hotfix-1.2.1 git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).Deleted branch hotfix-1.2.1 (was abbe5d6). 总结总结总结总结 这个开发模型其实没有什么新颖的,一开始提到的"大图"确实在我们的项目起到了非常大的作用。这是很优雅的一这个开发模型其实没有什么新颖的,一开始提到的"大图"确实在我们的项目起到了非常大的作用。这是很优雅的一 个模型,很容易实现,也容易在团队成员之间达成一致。个模型,很容易实现,也容易在团队成员之间达成一致。 PS:需要这个模型大图的,可以去PS:需要这个模型大图的,可以去原文地址原文地址原文地址原文地址下载下载 --EOF----EOF-- 若无特别说明,本站文章均为原创,转载请保留链接,谢谢若无特别说明,本站文章均为原创,转载请保留链接,谢谢 converted by Web2PDFConvert.com Add New CommentAdd New Comment Showing Showing 00 comments comments Trackback URL Trackback URL http://disqus.com/forums/lzyyblog/git__27/trackback/ make the world a little better and eaisermake the world a little better and eaiser Post as … converted by Web2PDFConvert.com
还剩6页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

myoula

贡献于2011-01-17

下载需要 15 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf