Git基础之git在项目中的协作模式

目录
  • 1、分布式工作流程
  • 2、集中式工作流
  • 3、分支工作流
  • 4、GitFlow 工作流(最流行)
  • 5、Forking 工作流(偶尔使用)
  • 6、总结

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分布式系统中经常使用的工作流程,但是在实际的开发中,你会遇到许多可能适合你的特定工作流程的变种,你可以按照实际的情况,灵活的进行组合和拓展。

参考

https://www.jb51.net/article/245636.htm

https://www.jb51.net/article/245629.htm

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

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

以上就是Git基础之git在项目中的协作模式的详细内容,更多关于Git项目中协作模式的资料请关注我们其它相关文章!

(0)

相关推荐

  • Git在项目协作开发中所解决问题

    目录 1.Git的历史 Tips: 2.Git的特点 3.Git在项目协作开发中所解决的问题 1.Git的历史 Git是目前世界上最先进的分布式版本控制系统,开源.免费. Git 是 Linus (林纳斯)为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件. Tips: Linus在1991年创建Linux,现在已经成为最大的服务器系统软件了. Linux的壮大是靠全世界热心的志愿者: 在2002年以前,世界各地的志愿者把源代码文件发给Linus,然后由Linus本人通过手工方

  • SVN与Git版本控制的优缺点差异全面分析

    目录 一.集中式vs分布式 1.Subversion属于集中式的版本控制系统 Subversion的特点概括起来主要由以下几条: 2.Git属于分布式的版本控制系统 Git具有以下特点: 二.版本库与工作区 1.SVN的版本库和工作区是分离的 2 .Git 的版本库和工作区如影随形 三.全局版本号和全球版本号 1. SVN与Git版本号比较 四.部分检出 1. SVN的部分检出 2. Git的检出 五.更新和提交 1.更新操作 2.SVN中的commit命令 3.Git中的暂存区域(stage)

  • Git工作流演示及三种工作方式

    目录 集中式工作流(不常用) Forking 工作流(偶尔使用) GitFlow 工作流(最流行) Git工作流演示 集中式工作流(不常用) 集中式工作流像SVN一样,以中央仓库作为项目所有修改的单点实体.所有修改都提交到 Master分支上.这种方式与 SVN 的主要区别就是开发人员有本地库,但是Git 很多特性并没有用到. Forking 工作流(偶尔使用) Forking 工作流是在 GitFlow 基础上,充分利用了 Git 的 Fork 和 pull request 的功能以达到代码审

  • Git工作流模式及命令的使用讲解

    目录 Git的工作方式 集中式工作流 功能分支工作流 Gitflow工作流 维护分支 工作流程 Forking工作流 Pull Request Git的工作方式 分为集中式工作流.功能分支工作流.Gitflow工作流和Forking,其中集中式工作流和功能分支工作流是已经使用过的,Gitflow和Forking两种工作流暂时没有使用过. 集中式工作流 一个远程仓库,一个主分支master,团队每个成员都有一个本地仓库,在本地仓库中进行代码的编辑.暂存和提交工作: git add <some fi

  • 使用版本控制原因及Git与Subversion介绍

    目录 前言 什么是版本控制? 那为什么还要力挺版本控制呢? Subversion 版本控制选择 分布式版本控制系统 Mercurial git 总结 前言 不知道什么是版本库的,扇自己两个大嘴巴:知道但不用的,扇自己四个大嘴巴.快扇去.你真扇了?那你是个大傻瓜.扇什么扇,有扇自己的功夫,还不赶紧去用版本库. 上面那句话是我根据<版本控制之道:使用Git>上一句读者感言发展而来的.版本控制真的那么重要,真的那么好吗? 什么是版本控制? [此段写给需要扇自己两个大嘴巴的人,以及部分需要扇四个大嘴巴

  • Git基础之git与SVN版本控制优缺点区别分析

    目录 Git和SVN的区别 (1)SVN(集中式版本管理系统) (2)Git(分布式版本管理系统) 2.SVN和Git的优缺点 (1)SVN优缺点 (2)Git优缺点 3.总结一下 Git和SVN的区别 (1)SVN(集中式版本管理系统) 集中式的版本控制系统都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新. Subversion属于集中式版本控制系统. 好处: 每个人都可以一定程度上看到项目中的其他人正在做些什么.

  • git基础之各版本控制系统介绍

    目录 1.什么是版本控制系统 2.我们为什么要用版本控制 3.版本管理系统的演变 (1)本地版本控制系统 (2)集中化版本控制系统 (3)分布式版本控制系统 1.什么是版本控制系统 版本控制是一种记录一个或若干个文件内容变化,以便将来查阅特定版本修订情况的系统.版本控制系统不仅可以应用于软件源代码的文本文件,而且可以对任何类型的文件进行版本控制. 有了它你就可以将某个文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态,你可以比较不同版本文件的变化细节,查出最后是谁修改了哪个地方.也

  • Git基础之git在项目中的协作模式

    目录 1.分布式工作流程 2.集中式工作流 3.分支工作流 4.GitFlow 工作流(最流行) 5.Forking 工作流(偶尔使用) 6.总结 1.分布式工作流程 与传统的集中式版本控制系统(CVCS)相反,Git 的分布式特性,使开发者间的协作变得更加灵活多样. 在集中式版本控制系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像. 而在 Git 中,每个开发者同时扮演着节点和集线器的角色.也就是说, 每个开发者既可以将自己的代码贡献到其他的仓库中,同时也能维护自己的公开仓

  • 详解如何去除vue项目中的#——History模式

    使用vue-cli搭建的环境,在配置好路由之后,可以看到下面的情况: 但是不难发现#的出现真的很丑陋,并且也不知道这是什么作用? 所以就去Stack Overflow上搜索了,果然还有~  看来Stack Overflow是真的强大,你在项目中遇到的问题实际上在so上都已经被问过并且解决了,这不:   这是最高票的回答,即在vue2中将mode模式设置为history,试过之后确实奏效! 但是知道这样可以解决问题,却不知道为什么,这是不行的, 随着连接,我们看到了文档. 所以这篇文章也就是引申到

  • vue-cli创建的项目中的gitHooks原理解析

    前言 在使用 vue create my-app 创建项目的时候,Vue 会自动帮我们做好一些预配置,你可以不使用它,但是一旦需要的时候,突然发现,咦~原来它已经帮我做好准备工作了,只需要按自己的需求配置一下就可以了,就会觉得 vue-cli 很贴心啊,帮我们节省了很多时间. 在 package.json 文件中会发现 gitHooks . lint-staged 等字段,不难看出它是在我们执行 git 命令的时候会自动执行的一些额外的操作,比如语法提示.错误提示等. 这个完整的过程是怎样的呢?

  • 如何去除vue项目中的#及其ie9兼容性

    一.如何去除vue项目中访问地址的# vue2中在路由配置中添加mode(vue-cli创建的项目在src/router/index.js) export default new Router({ mode: 'history', routes: [ { path: '/', name: 'menu', component: menu, children: [ { path: 'organization', component: organization, children: [ { path:

  • vue cli构建的项目中请求代理与项目打包问题

    在上篇文章给大家介绍了vue-cli webpack模板项目搭建及打包时路径问题的解决方法,可以点击查看. vue-cli构建的项目中,生产模式下的打包路径.与生产模式下的请求代理简单示意 总结 以上所述是小编给大家介绍的vue cli构建的项目中请求代理与项目打包问题,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的.在此也非常感谢大家对我们网站的支持! 您可能感兴趣的文章: Vue-cli创建项目从单页面到多页面的方法 Vue使用vue-cli创建项目 vue-cli项

  • idea中git从码云克隆项目到本地的方法

    1.首先需要在操作系统上安装Git分布式管理系统 此处自行百度............. 2.在Intellij IDEA中配置Git 打开Settings(File-->Settings) --> 在搜索栏内输入git,回车跳转到Git配置页面 --> 将git的运行路径填入Path to Git executable一栏(一般IDEA会自动定位),其他配置选项按默认即可 --> 点击Test进行测试,配置成功将显示如下界面 同理,配置GitHub也是一样(没有GitHub帐号的

  • 将Git存储库克隆到本地IntelliJ IDEA项目中的详细教程

    IntelliJ IDEA是Java语言开发的集成环境,IntelliJ在业界被公认为优秀的Java开发工具之一,尤其在智能代码助手.代码自动提示.重构.J2EE支持.Ant.JUnit.CVS整合.代码审查. 创新的GUI设计等方面的功能可以说是超常的. 点击下载IntelliJ IDEA最新试用版 将GitHub存储库克隆到我们的本地计算机 有几种方法可以将Git存储库克隆到本地计算机.您可以使用HTTPS或SSH等选项.我们将使用的是HTTPS,因为它可能是最简单的选择.当我们单击剪贴板图

  • 简述IDEA集成Git在实际项目中的运用

    1.企业实际项目中Git的使用 在实际的企业项目开发中,我们一般Java的项目在公司都有自己的局域网代码仓库,仓库上存放着很多的项目.以我工作过的公司如华为的项目,一般是存放在企业内部的CodeHub上:CETC电科是存放在码云Gitee的企业版仓库上.而基于Git的使用不再是老掉牙的原始Git命令行,或者是一般的TortoiseGit. 我们在企业中开发经常使用的是基于IDEA集成Git工具进行代码的提交,既方便又快捷.同时也是很多有经验的面试官会常用来面试考验培训班新手和实际开发者的常规性面

随机推荐