Git分支管理策略

Git分支管理策略

注:本文档参考网上主流的git的分支管理策略编写,仅供学习参考。

来源:https://www.jianshu.com/p/7aa32a0d9717

           https://www.jianshu.com/p/08c05a498b90

1. Git flow

1.1 简介

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

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


1.2 工作原理

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

1.3 主分支Master

首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。

1.4开发分支Develop -用于记录历史的分支

主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。

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

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

这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。

Git创建Develop分支的命令: git checkout -b develop master

将Develop分支发布到Master分支的命令

 #切换到Master分支             git checkout master

 #对Develop分支进行合并    git merge --no-ff develop


1.5功能开发的分支- Feature分支

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


创建一个功能分支:git checkout -b feature-x develop

将功能分支合并到develop分支:git checkout develop

git merge --no-ff feature-x

删除feature分支:git branch -d feature-x


1.6用于发布的分支– Release 分支

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


创建一个预发布分支:git checkout -b release-1.2 develop

合并到master分支: git checkout master

git merge --no-ff release-1.2

对合并生成的新节点,做一个标签:git tag -a 1.2


1.7用于维护的分支 – Hotfix分支

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


创建一个修补bug分支: git checkout -b fixbug-0.1 master

修补结束后,合并到master分支:   git checkout master

git merge --no-ff fixbug-0.1

git tag -a 0.1.1

再合并到develop分支:         git checkout develop

         git merge --no-ff fixbug-0.1

最后,删除"修补bug分支":   git branch -d fixbug-0.1


1.8 远程分支操作

创建远程分支,并查看本地分支和远程分支的映射关系,及各分支最新的提交状态。

查看本地分支与远程分支对应关系:

部分图片来自网络,仅供初学者谢谢参考,如有问题请指出,谢谢!

你可能感兴趣的:(Git分支管理策略)