亲宝软件园·资讯

展开

Git项目中协作模式

繁华似锦Fighting 人气:0

1、分布式工作流程

与传统的集中式版本控制系统(CVCS)相反,Git 的分布式特性,使开发者间的协作变得更加灵活多样。

在集中式版本控制系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像。 而在 Git 中,每个开发者同时扮演着节点和集线器的角色。也就是说, 每个开发者既可以将自己的代码贡献到其他的仓库中,同时也能维护自己的公开仓库, 让其他人可以在其基础上工作并贡献代码。

由此,Git 的分布式协作可以为你的项目和团队,衍生出种种不同的工作流程, 接下来会介绍几种常见Git工作流程。

你可以选择使用其中的某一种,或者将它们的特性混合搭配使用。

2、集中式工作流

Git为了便于客户机之间的协同工作,Git版本控制系统一般会设置一个中央版本库服务器,目的是让所有客户机都从该主机更新版本,提交最新版本,该工作模式下的客户机地位都平等。

集中式工作流像SVN一样,以中央仓库作为项目所有修改的单点实体,所有修改都提交到 Master分支上。这种方式与 SVN 的主要区别就是开发人员有本地库,但是Git 很多特性并没有用到。

如下图:

上图说明:

集中式工作流总结:

适用人群:小型开发小团队,习惯使用SVN工具的小团队。

工作方式:

缺点:

3、分支工作流

功能分支工作流在集中式工作流的基础上,为各个新功能分配一个专门的分支来开发,即在master主分支外在创建一个分支,程序员开发的新功能全部push到此分支上,等到功能成熟的时候,再把此分支合并到主分支master上。

如下图:

分支工作流总结:

适用人群:小型开发团队,熟悉Git分支的团队。

工作方式:

缺点:

说明:Pull Request作用是可以让其他组员或组长可以查看你的代码,并可以提出代码修改意见或者讨论。

4、GitFlow 工作流(最流行)

Gitflow工作流没有用超出上面功能分支工作流的概念和命令,而是为不同的分支,分配一个很明确的角色,并定义分支之间如何交互,和什么时候进行交互。

总结就是:Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支,让发布迭代过程更流畅,充分的利用了分支的特点。严格的分支模型也为大型项目提供了一些非常必要的结构。

下图是完整的Gitflow 工作流开发方式图,但实际开发工作环境可能会精简:

Gitflow工作流总结:

适用人群:任何开发团队,熟悉Git分支的团队。

工作方式:

说明:Gitflow工作流是Vincent Driessen工程师提出的多分支工作流。

5、Forking 工作流(偶尔使用)

分叉(Forking)工作流也可以叫做分布式工作流,是在 GitFlow工作流的基础上的衍生,充分利用了Git在分支和克隆上的优势,再加上pull request 的功能,以达到代码审核的目的。既可以管理大团队的开发者(developer)的提交,也可以接受不信任贡献者(contributor)的提交。

这种工作流使得每个开发者都有一个服务端仓库(此仓库只有自己可以push推送,但是所有人都可以pull拉取修改),每个程序员都push代码到自己的服务端仓库,但不能push到正式仓库,只有项目维护者才能push到正式仓库,这样项目维护者可以接受任何开发者的提交,但无需给他正式代码库的写权限。

这种工作流适合开源社区的开源项目,大家统一对项目做贡献,但是有一个人或一个团队作为开发者来管理项目,所有的贡献者的代码由开发者审核,其功能完善之后再由开发者push到正式仓库中。

总结:

图示如下:

提示:

分叉工作流(分布式仓库工作流)总结:

适用人群:大型开发团队,熟悉Git分支的团队。

工作方式:

6、总结

上面介绍了在Git分布式系统中经常使用的工作流程,但是在实际的开发中,你会遇到许多可能适合你的特定工作流程的变种,你可以按照实际的情况,灵活的进行组合和拓展。

参考

https:

https:

http://shouce.jb51.net/gitbook/Distributed-Git/Distributed-Workflows.html

https://git-scm.com/book/zh/v2/

加载全部内容

相关教程
猜你喜欢
用户评论