脚本宝典收集整理的这篇文章主要介绍了『现学现忘』Git基础 — 5、Git的协作模式,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
与传统的集中式版本控制系统(CVCS)相反,Git 的分布式特性,使开发者间的协作变得更加灵活多样。
在集中式版本控制系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像。 而在 Git 中,每个开发者同时扮演着节点和集线器的角色。也就是说, 每个开发者既可以将自己的代码贡献到其他的仓库中,同时也能维护自己的公开仓库, 让其他人可以在其基础上工作并贡献代码。
由此,Git 的分布式协作可以为你的项目和团队,衍生出种种不同的工作流程, 接下来会介绍几种常见Git工作流程。
你可以选择使用其中的某一种,或者将它们的特性混合搭配使用。
Git为了便于客户机之间的协同工作,Git版本控制系统一般会设置一个中央版本库服务器,目的是让所有客户机都从该主机更新版本,提交最新版本,该工作模式下的客户机地位都平等。
集中式工作流像SVN一样,以中央仓库作为项目所有修改的单点实体,所有修改都提交到 Master
分支上。这种方式与 SVN 的主要区别就是开发人员有本地库,但是Git 很多特性并没有用到。
如下图:
上图说明:
master
。集中式工作流总结:
master
分支,组员可读可写。git clone
远程仓库到本地仓库,在master
分支上开发。git pull
更新远程仓库的master
分支版本到本地。git commit
到本地仓库, 接着git push
到远程仓库。git push
,一直会提交到本地仓库,没有推送到远程仓库。git pull
,导致本地仓库与中央仓库不一致,发生文件冲突。git pull
,导致增加Git分支合并次数,增加了Git变基次数,降低了Git的性能。功能分支工作流在集中式工作流的基础上,为各个新功能分配一个专门的分支来开发,即在master
主分支外在创建一个分支,程序员开发的新功能全部push
到此分支上,等到功能成熟的时候,再把此分支合并到主分支master
上。
如下图:
分支工作流总结:
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
作用是可以让其他组员或组长可以查看你的代码,并可以提出代码修改意见或者讨论。
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工作流总结:
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
工程师提出的多分支工作流。
分叉(Forking
)工作流也可以叫做分布式工作流,是在 GitFlow工作流的基础上的衍生,充分利用了Git在分支和克隆上的优势,再加上pull request
的功能,以达到代码审核的目的。既可以管理大团队的开发者(developer
)的提交,也可以接受不信任贡献者(contributor
)的提交。
这种工作流使得每个开发者都有一个服务端仓库(此仓库只有自己可以push
推送,但是所有人都可以pull
拉取修改),每个程序员都push
代码到自己的服务端仓库,但不能push
到正式仓库,只有项目维护者才能push
到正式仓库,这样项目维护者可以接受任何开发者的提交,但无需给他正式代码库的写权限。
这种工作流适合开源社区的开源项目,大家统一对项目做贡献,但是有一个人或一个团队作为开发者来管理项目,所有的贡献者的代码由开发者审核,其功能完善之后再由开发者push
到正式仓库中。
总结:
Forking
)工作流更适合安全可靠地管理大团队的开发者,而且能接受不信任贡献者的提交。图示如下:
提示:
- 每个成员都可以从中央版本库中拉取代码。
- 每级成员都只能向上一级提交代码。
- 上一级合并代码之后继续向上级提交代码。
- 最后只有独裁者才能向中央版本库提交代码。
分叉工作流(分布式仓库工作流)总结:
master
分支,从项目维护者可读不可写。fork
主项目维护者的远程仓库的副本,到自己的远程仓库,包括master
分支。(记住,从项目维护者的远程仓库独立于主项目维护者的远程仓库)git clone
主项目维护者的远程仓库的副本到本地仓库。feature
分支,在feature
分支上开发。git commit
到本地仓库中自己的feature
分支, 接着git push
到远程仓库。pull request
命令,从项目维护者合并自己feature
分支,到从项目维护者的远程仓库的master
分支上。feature
分支删除。feature
分支删除。pull request
向主项目维护者的远程仓库的推送。pull request
获取从项目维护者的远程仓库的推送。上面介绍了在Git分布式系统中经常使用的工作流程,但是在实际的开发中,你会遇到许多可能适合你的特定工作流程的变种,你可以按照实际的情况,灵活的进行组合和拓展。
参考:
- https://blog.csdn.net/shengzhu1/article/details/77990582
- https://blog.csdn.net/weixin_43691058/article/details/106427915
- https://blog.csdn.net/weixin_30344795/article/details/96683694
- https://git-scm.com/book/zh/v2/
以上是脚本宝典为你收集整理的『现学现忘』Git基础 — 5、Git的协作模式全部内容,希望文章能够帮你解决『现学现忘』Git基础 — 5、Git的协作模式所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。