『现学现忘』Git基础 — 5、Git的协作模式
1、分布式工作流程
与传统的集中式版本控制系统(CVCS)相反,Git 的分布式特性,使开发者间的协作变得更加灵活多样。
在集中式版本控制系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像。 而在 Git 中,每个开发者同时扮演着节点和集线器的角色。也就是说, 每个开发者既可以将自己的代码贡献到其他的仓库中,同时也能维护自己的公开仓库, 让其他人可以在其基础上工作并贡献代码。
由此,Git 的分布式协作可以为你的项目和团队,衍生出种种不同的工作流程, 接下来会介绍几种常见Git工作流程。
你可以选择使用其中的某一种,或者将它们的特性混合搭配使用。
2、集中式工作流
Git为了便于客户机之间的协同工作,Git版本控制系统一般会设置一个中央版本库服务器,目的是让所有客户机都从该主机更新版本,提交最新版本,该工作模式下的客户机地位都平等。
集中式工作流像SVN一样,以中央仓库作为项目所有修改的单点实体,所有修改都提交到 Master
分支上。这种方式与 SVN 的主要区别就是开发人员有本地库,但是Git 很多特性并没有用到。
如下图:
上图说明:
- 一个远程仓库。
- 一个主分支
master
。 - 团队每个成员都有一个本地仓库,在本地仓库中进行代码的编辑、暂存和提交工作。
集中式工作流总结:
- 适用人群:小型开发小团队,习惯使用SVN工具的小团队。
- 工作方式:
- 团队组长创建远程仓库,创建一个
master
分支,组员可读可写。 - 每个开发人员都
git clone
远程仓库到本地仓库,在master
分支上开发。 - 每次开发都要
git pull
更新远程仓库的master
分支版本到本地。 - 每次开发完成就
git commit
到本地仓库, 接着git push
到远程仓库。
- 团队组长创建远程仓库,创建一个
- 缺点:
- 忘了
git push
,一直会提交到本地仓库,没有推送到远程仓库。 - 忘了
git pull
,导致本地仓库与中央仓库不一致,发生文件冲突。 - 大量操作
git pull
,导致增加Git分支合并次数,增加了Git变基次数,降低了Git的性能。
- 忘了
3、分支工作流
功能分支工作流在集中式工作流的基础上,为各个新功能分配一个专门的分支来开发,即在master
主分支外在创建一个分支,程序员开发的新功能全部push
到此分支上,等到功能成熟的时候,再把此分支合并到主分支master
上。
如下图:
分支工作流总结:
- 适用人群:小型开发团队,熟悉Git分支的团队。
- 工作方式:
- 团队组长创建远程仓库,创建一个
master
分支,组员可读不可写。 - 每个开发人员都
git clone
远程仓库到本地仓库。 - 每个开发人员创建自己的
feature
分支,在feature
分支上开发。(记住,feature
分支是基于master
分支) - 每个开发人员每次开发完成就
git commit
到本地仓库中自己的feature
分支, 接着git push
到远程仓库。 - 通过
pull request
提醒团队组长,浏览组员提交feature
分支。 - 组长把
feature
分支拉下来,然后合并到自己本地仓库的master
分支上测试。 - 组长测试
feature
分支通过之后,由组长负责把feature
分支合并到远程仓库的master
分支上。 - 组长在远程仓库把合并过的
feature
分支删除。 - 组员在本地仓库把合并过的
feature
分支删除。 - 组员将本地仓库分支切换为
master
分支,然后git pull
将本地仓库的master
分支更新到远程仓库的master
分支版本。
- 团队组长创建远程仓库,创建一个
- 缺点:
- 增加团队组长的工作量。
- 增加团队组员提交步骤。
说明:
Pull Request
作用是可以让其他组员或组长可以查看你的代码,并可以提出代码修改意见或者讨论。
4、GitFlow 工作流(最流行)
Gitflow工作流没有用超出上面功能分支工作流的概念和命令,而是为不同的分支,分配一个很明确的角色,并定义分支之间如何交互,和什么时候进行交互。
- 除了有
master
主分支(用于存储正式发布的历史版本)外,还有一个作为功能集成分支的develop
分支。
当初始化完成后,某个程序员想要开发一个功能,并不是直接从master
分支上拉出新分支,而是使用develop
分支作为父分支来拉出新分支。
当新功能完成后,再合并回父分支,新功能的提交并不与master
分支直接交互。 - 一旦
develop
分支上有了做一次发布(或者说快到了既定的发布日)的足够功能,就从develop
分支上checkout
一个发布分支。
新建的发布分支用于开始发布循环,所以从这个时间点开始之后新的功能,不能再加到这个分支上,该分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了,发布分支合并到master
分支,并分配一个版本号打好Tag
。
另外,这些从新建发布分支以来的做的修改,要合并回develop
分支上。 - 维护分支或说是热修复(
hotfix
)分支用于,快速给产品发布版本(production releases
)打补丁,这是唯一可以直接从master
分支fork
出来的分支。
修复完成,修改应该马上合并回master
分支和develop
分支(当前的发布分支),master
分支应该用新的版本号打好Tag
。
为Bug修复使用专门分支,让团队可以快速处理掉问题,而不用打断其它工作或是等待下一个发布循环。
你可以把维护分支想成是一个直接在master
分支上处理的临时发布。
总结就是:Gitflow
工作流通过为功能开发、发布准备和维护设立了独立的分支,让发布迭代过程更流畅,充分的利用了分支的特点。严格的分支模型也为大型项目提供了一些非常必要的结构。
下图是完整的Gitflow
工作流开发方式图,但实际开发工作环境可能会精简:
Gitflow工作流总结:
- 适用人群:任何开发团队,熟悉Git分支的团队。
- 工作方式:
- 项目维护者创建项目维护者的远程仓库,创建
master
分支与develop
分支,贡献者可读不可写。 - 每个贡献者
git clone
远程仓库中的develop
分支到本地仓库。(记住,develop
分支相当于master
的分支,包括功能开发,修改,测试。master
分支相当于最终分支) - 每个贡献者在本地仓库创建自己的
feature
分支,在feature
分支上开发。 - 在
feature
分支又可以创建多个feature
分支,继续开发项目。 - 每个贡献者每次开发完成就
git commit
到本地仓库中自己的feature
分支, 接着git push
到远程仓库。 - 通过
pull request
提醒项目维护者,浏览贡献者提交feature
分支。 - 项目维护者把
feature
分支拉下来,然后合并到自己本地仓库的develop
分支上测试。 - 组长测试
feature
分支通过之后,由组长负责把feature
分支合并到远程仓库的develop
分支上。 - 项目维护者会
release
分支上git tag
打上版本号。 - 项目维护者可以从
develop
分支创建release
分支,接着把release
分支合并到master
分支上,同时master
分支同步到develop
分支。 - 项目维护者在远程仓库把合并过的
feature
分支删除。 - 每个贡献者在本地仓库把合并过的
feature
分支删除。 - 每个贡献者将本地仓库分支切换为
develop
分支,然后git pull
将本地仓库的master
分支更新到远程仓库的develop
分支版本。
- 项目维护者创建项目维护者的远程仓库,创建
说明:Gitflow工作流是
Vincent Driessen
工程师提出的多分支工作流。
5、Forking 工作流(偶尔使用)
分叉(Forking
)工作流也可以叫做分布式工作流,是在 GitFlow工作流的基础上的衍生,充分利用了Git在分支和克隆上的优势,再加上pull request
的功能,以达到代码审核的目的。既可以管理大团队的开发者(developer
)的提交,也可以接受不信任贡献者(contributor
)的提交。
这种工作流使得每个开发者都有一个服务端仓库(此仓库只有自己可以push
推送,但是所有人都可以pull
拉取修改),每个程序员都push
代码到自己的服务端仓库,但不能push
到正式仓库,只有项目维护者才能push
到正式仓库,这样项目维护者可以接受任何开发者的提交,但无需给他正式代码库的写权限。
这种工作流适合开源社区的开源项目,大家统一对项目做贡献,但是有一个人或一个团队作为开发者来管理项目,所有的贡献者的代码由开发者审核,其功能完善之后再由开发者push
到正式仓库中。
总结:
- 分叉(
Forking
)工作流更适合安全可靠地管理大团队的开发者,而且能接受不信任贡献者的提交。 - 在实际工作中,如果偶尔有需要团队外的成员帮我们解决问题时,可能会用到。
- 这种工作流程并不常用,只有当项目极为庞杂,或者需要多级别管理时,才会体现出优势。 利用这种方式,项目总负责人(即主管)可以把大量分散的集成工作,委托给不同的小组负责人分别处理,然后在不同时刻将大块的代码子集统筹起来,用于之后的整合。
图示如下:
提示:
- 每个成员都可以从中央版本库中拉取代码。
- 每级成员都只能向上一级提交代码。
- 上一级合并代码之后继续向上级提交代码。
- 最后只有独裁者才能向中央版本库提交代码。
分叉工作流(分布式仓库工作流)总结:
- 适用人群:大型开发团队,熟悉Git分支的团队。
- 工作方式:
- 主项目维护者创建远程仓库,创建一个
master
分支,从项目维护者可读不可写。 - 从项目维护者通过
fork
主项目维护者的远程仓库的副本,到自己的远程仓库,包括master
分支。(记住,从项目维护者的远程仓库独立于主项目维护者的远程仓库) - 从项目维护者
git clone
主项目维护者的远程仓库的副本到本地仓库。 - 从项目维护者创建自己的
feature
分支,在feature
分支上开发。 - 从项目维护者每次开发完成就
git commit
到本地仓库中自己的feature
分支, 接着git push
到远程仓库。 - 通过
pull request
命令,从项目维护者合并自己feature
分支,到从项目维护者的远程仓库的master
分支上。 - 从项目维护者在远程仓库把合并过的
feature
分支删除。 - 从项目维护者在本地仓库把合并过的
feature
分支删除。 - 从项目维护者在远程仓库通过
pull request
向主项目维护者的远程仓库的推送。 - 主项目维护者通过
pull request
获取从项目维护者的远程仓库的推送。 - 主项目维护者进行从项目维护者的远程仓库代码审查,测试。
- 主项目维护者确认无误后,可以直接合并到主项目维护者的远程仓库。
- 主项目维护者创建远程仓库,创建一个
6、总结
上面介绍了在Git分布式系统中经常使用的工作流程,但是在实际的开发中,你会遇到许多可能适合你的特定工作流程的变种,你可以按照实际的情况,灵活的进行组合和拓展。
参考:
『现学现忘』Git基础 — 5、Git的协作模式的更多相关文章
- 『学了就忘』Linux基础 — 8、虚拟机网络模式说明
目录 1.虚拟机网卡 2.网络连接模式对应工作的网卡 3.桥接模式说明 4.补充说明 这篇主要总结一下虚拟机网络配置中桥接模式.NAT模式和仅主机模式的区别. 打开VMware,选中虚拟机,点击网络适 ...
- 『现学现忘』Git基础 — 13、Git的基础操作
目录 1.Git最基础的使用方式 (1)初始化本地版本库 (2)查看文件的状态 (3)把文件添加到暂存区 (4)把暂存区的内容提交到本地版本库 2.总结本文用到的Git命令 1.Git最基础的使用方式 ...
- 『现学现忘』Git基础 — 3、Git介绍
目录 1.Git的历史 2.Git的特点 3.Git在项目协作开发中所解决的问题 1.Git的历史 Git是目前世界上最先进的分布式版本控制系统,开源.免费. Git 是 Linus (林纳斯)为了帮 ...
- 『现学现忘』Git基础 — 4、Git下载与安装
目录 1.Git下载 2.Git在Windows下的详细安装 3.验证Git是否安装成功 1.Git下载 进入官方地址下载Git客户端:https://git-scm.com/download/win ...
- 『现学现忘』Git基础 — 7、设置Git Bash终端默认路径
目录 1.Git Bash默认路径 2.如何查看Git Bash终端默认路径 3.如何修改Git Bash终端的默认路径 4.拓展:指定目录进入Git Bash终端 5.注意事项 如果您不熟悉Git命 ...
- 『现学现忘』Git基础 — 12、Git用户签名(补充)
目录 1.修改用户签名 2.取消用户签名 3.用户签名的优先级 4.总结本文用到的Git命令 1.修改用户签名 其实很简单,就是重新执行git config命令,换个用户名和邮箱地址就可以了,新配置的 ...
- 『现学现忘』Git基础 — 14、Git基础操作的总结与补充
目录 1.Git本地版本库结构 2.Git常用操作方法 3.补充:添加多个文件到暂存区 4.补充:提交操作未写备注 5.补充:从工作区直接提交到版本库 1.Git本地版本库结构 如下图所示: 工作区( ...
- 『现学现忘』Git基础 — 19、在Git中进行忽略文件操作
目录 1.忽略文件说明 2.忽略文件的原则 3..gitignore忽略规则 4.忽略文件的三种方式 (1)忽略单个仓库中的文件(远程共用) (2)忽略单个仓库中的文件(本地使用) (3)全局忽略 1 ...
- 『现学现忘』Git基础 — 23、Git中的撤销操作
目录 1.撤销操作说明 2.撤销工作区中文件的修改 3.撤销暂存区中文件的修改 4.总结 1.撤销操作说明 我们在使用Git版本管理时,往往需要撤销某些操作.比如说我们想将某个修改后的文件撤销到上一个 ...
- 『现学现忘』Git基础 — 24、Git中查看历史版本记录
目录 1.查看详细的历史版本记录 2.简化显示历史版本记录 3.历史版本记录常用操作 (1)指定查看最近几次提交的内容 (2)以简单图形的方式查看分支版本历史 (3)翻页与退出 4.查看分支相关的版本 ...
随机推荐
- Mybatis将mapper映射文件配置到recources下
关于为什么要将Mybatis的mappers.xml文件配置到resources目录下的粗浅看法: (1).使文件目录更加清晰.resources文件目录下通常为配置文件,所以将Mappers.xml ...
- CentOS 8 EOL如何切换源?
镜像下载.域名解析.时间同步请点击 阿里巴巴开源镜像站 CentOS 8操作系统版本结束了生命周期(EOL),Linux社区已不再维护该操作系统版本.建议您切换到Anolis或Alinux.如果您的业 ...
- ITerm让MAC终端更加灵活高效
一.ITerm2简介 1.安装 iTerm2 是一款完全免费的,专为 Mac OS 用户打造的命令行应用.直接在官网上http://iterm2.com/ 下载并安装即可. 2.配置 设置ITerm为 ...
- 羽夏看Win系统内核—— x64 番外篇
写在前面 此系列是本人一个字一个字码出来的,包括示例和实验截图.由于系统内核的复杂性,故可能有错误或者不全面的地方,如有错误,欢迎批评指正,本教程将会长期更新. 如有好的建议,欢迎反馈.码字不易, ...
- 团队vue基础镜像选择思考
前端镜像可以考虑使用nginx或者openresty; 镜像 大小 说明 nginx:1.20.2-alpine 8.41 MB 最小最新版本 nginx:1.21.4 50.95 MB 最新版本 n ...
- 什么是bean的自动装配?
Spring 容器能够自动装配相互合作的bean,这意味着容器不需要<constructor-arg>和<property>配置,能通过Bean工厂自动处理bean之间的协作.
- oracle.i18n.text.convert.CharacterConverterOGS.getInstance(I)Loracle/i18n/text/converter/CharacterConver;
看看项目是不是同时包含ojdbc系列jar包和nls_charset12.jar包.如果同时包含,则删除nls_charset12.jar.因为低版本的nls_charset12和ojdbc包冲突.
- 静态嵌套类(Static Nested Class)和内部类(Inner Class) 的不同?
Static Nested Class 是被声明为静态(static)的内部类,它可以不依赖于外部类 实例被实例化.而通常的内部类需要在外部类实例化后才能实例化,其语法看起 来挺诡异的,如下所示. / ...
- spring-boot-learning 缓存之redis
什么是BSD协议: BSD是"Berkeley Software Distribution"的缩写,意思是"伯克利软件发行版". BSD开源协议是一个给于使用者 ...
- 为什么要用Spring
1.方便解耦,简化开发 通过Spring提供的IoC容器,我们可以将对象之间的依赖关系交由Spring进行控制,避免硬编码所造成的过度程序耦合.有了Spring,用户不必再为单实例模式类.属性文件解析 ...