交叉型工作流程

纯洁的微笑 2021-10-29 17:01:30 ⋅ 21 阅读

交叉型工作流程跟前面讨论过的流程相比大不相同,不再使用单一的服务器端中心代码仓库,而是给每个开发人员一个服务器端的代码仓库,也就是说每个开发人员都有两个Git仓库:私人的本地仓库和公共的服务器端仓库。

本流程的主要优势是不需要把提交的代码跟别人的代码集成,而以往使用单一中心代码库时则需要经常进行此类操作。开发者只能将自己的代码提交到属于自己的服务器端代码仓库,只有专门的运维人员能够向正式的代码仓库推送代码。运维人员从其他开发人员那里接收提交的代码,而不用向开发人员开放正式代码库的写权限。

交叉型的工作流程为大型的、有机组织的团队(包括具备信任风险的第三方)提供了灵活而安全的协作方式,也是开源项目理想的工作流程。

它是如何工作的

交叉型工作流程在开始的时候也拥有一个正式的公共库,该库保存在服务器端。当一个新的开发人员想要进入项目工作时,他们不直接从正式库克隆。

相反,他们在服务器端创建一个正式库的拷贝,这个新拷贝是他们的个人公共库。其他开发人员不允许向该库推送,但可以从这里拉取变更(稍后将看到这样做是很重要的)。创建了个人的服务器中心库后,开发人员执行git clone把该库的拷贝克隆到本地,作为个人的开发环境,这个其它流程没有什么两样。

开发人员完成开发工作后,将本地提交推送到自己的服务器端公共库(不是正式库),然后创建一个“拉取请求”以便让运维知道有一个更新准备就绪可以用来集成了,这个“拉取请求”同样可以用来发起讨论以便对提交的代码进行评审或解决可能存在的问题。

为了将这个特性集成到正式代码库,运维人员从该贡献者的个人公共库拉取变更到自己的本地仓库、检查以确保变更集不会破坏项目、合并变更到自己的本地master分支、推送这个master分支到服务器端的正式库,现在那个工程师贡献的代码变成了项目的一部分,其他工程师应当从正式库拉取变更以同步他们个人本地库。

正式代码仓库

需要注意的是,交叉型流程里的“正式”代码库这个概念仅仅是一个约定,从技术层面来讲,Git不认为它和其他工程师的公共库有什么不同。这个正式库之所以“正式”是流程约定的,它的用途比较独特,是运维人员的公共库。

交叉型流程的分支操作

所有这些个人公共库可以很高效的跟其他开发人员共享分支,每个人还是应该使用分支隔离独立的特性,就像特性分支流程、Gitflow流程那样,不同的是分支共享的方式不一样,在交叉流程中,分支被拉到其他开发人员的本地库中,而在特性分支流程和Gitflow流程里,分支都被推送到正式库。

示例

项目运维人员初始化正式库

 

所有基于Git的项目首先都要在服务器建立供团队成员访问的正式库,只不过在这个流程下,正式库只对运维人员开放而已。

初建的恶公共库应该都是空白的,运维人员运行如下命令建立正式库:

ssh user@host
git init --bare /path/to/repo.git

Bitbucket和Stash的GUI工具提供了一个完成上述操作的功能,其他工作流程也是通过上述命令完成中心库的建立的。必要的话,运维人员可以把现有的代码推送到这个库里。

开发人员从正式库建立个人库

下一步,其他开发人员需要从正式库岔出个人库,可以在服务器上执行git clone命令在需要的位置克隆正式库。(岔出的个人库是存储在服务器端的,Bitbucket和Stash的GUI工具也提供了一个完成上述操作的功能)。

完成这个操作后,每个开发人员都有了自己的服务器端的代码库,它们跟正式库一样都是空白的。

开发人员克隆个人库到本地

接下来每个开发人员需要克隆自己的公共库,直接使用git clone命令即可。

这个例子假设使用Bitbucket作为这些个人库的主机,每个开发人员也都有Bitbucket的账号,他们运行如下命令克隆服务器端的个人库:

git clone https://user@bitbucket.org/user/repo.git

以往介绍的流程只使用一个origin指向远端的中心库,但是交叉型流程至少需要两个远端库:一个指向中心正式库,一个指向开发者个人库。这两个远端的名字可以随便取,通常的习惯是使用origin作为开发人员自己服务器端个人库的名称(git clone执行时自动生成),使用upstream作为正式库的名称。

git remote add upstream https://bitbucket.org/maintainer/repo

开发人员需要自己使用上述命令创建upstream远端连接,开发人员使用这个远端连接跟正式库保持一致。如果upstream库需要认证的话,需要提供自己的用户名,比如:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

将来跟中心库连接时(克隆或拉取)都需要提供对应的密码。

开发人员进行特性开发

在开发人员克隆的本地库里,他们可以跟以前流程里一样进行代码修改、提交变更、创建分支等工作:

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

所有这些变更在推送到他们自己的公共库之前完全是私有的,如果正式库的代码已经发生了变化,工程师可以把新的提交记录git pull回来:

git pull upstream master

由于开发人员都在自己专用的特性分支下工作,这个操作一般来说会产生“fast-forward”合并。

开发人员发布特性

开发人员负责的特性开发完毕了,紧接着需要做两件事情。首先,需要把自己的代码推送到服务器上自己的个人库里,以便于其他人员读取。此时,开发人员自己本地的origin远端连接应该已经建立了,他们执行如下命令即可:

git push origin feature-branch

此处跟其他工作流程不同,这里的origin远端连接指向的是开发者在服务器端的个人公共库,而不是正式的主代码库。

其次,开发人员需要通知项目运维人员准备合并自己的特性到正式代码库中。Bitbucket和Stash提供了一个完成“拉取请求”的功能,可以让开发者选择想要合并到正式代码库的具体分支。一般来说,这个合并是要把特性分支合并到upstream远端连接对应的master分支中。

项目运维人员集成这些特性

项目维护人员收到拉取请求后,就要决定是否要将收到的特性集成到正式代码库中,他们可以选择下述两种方式中的一种进行决策:

  1. 直接在拉取请求里检查代码
  2. 将这些代码拉取到他的本地代码库并进行手工合并

第一个方式比较简单,运维人员可以查看变更带来的差异、对其进行注释、通过GUI工具进行合并。但是如果拉取请求出现了冲突,使用第二个方式就很有必要了。在这个案例中,运维人员需要从开发人员的服务器端个人库获取特性分支、合并到自己本地的master分支中、解决任何可能的冲突。

git fetch https://bitbucket.org/user/repo feature-branch
# Inspect the changes
git checkout master
git merge FETCH_HEAD

一旦变更被集成到运维人员自己的本地master中后,他们需要将其推送到服务器上的正式库,便于开发人员读取:

git push origin master

开发人员的origin远端指向是项目的正式代码库,开发人员贡献的特性现在就完全集成到项目中来了。

开发人员和正式代码库同步

由于主代码库发生了变化,其他开发人员应当跟正式库保持同步:

git pull upstream master

何去何从

如果你有很深的SVN背景,那么交叉式工作流程似乎显得很激进,但是别担心,很多要做的事情在上面介绍的特性分支流程里已经阐述过了,本流程跟只通过一个中心库进行分支共享的方式不同,开发者提交的代码只被发布到了面向开发者自身的服务器端代码库。

这篇文章介绍了一个开发人员贡献的代码如何整合到master分支,同样的方法论可以被用于集成代码到任何代码库,比如你的团队的部分成员正在一个特定的特性上协同开发,他们可以使用同样的方式共享变更,而不用接触到主代码仓库。

这就使交叉型工作流在组织比较松撒的团队里变得非常强大,任何开发人员能够很容易地共享变更给他人,任意分支能够被高效地整合进正式代码库。


全部评论: 0

    我有话说:

    Git中心式工作流程

    Git中心式工作流程

    Git特性分支工作流程

    Git特性分支工作流程

    Git典型工作流程介绍

    Git典型工作流程介绍

    Gitflow工作流程

    Gitflow工作流程来源于Vincent Driessen的网站nvie。 这个工作流程围绕项目发布定义了一个严格的模型,它比特性分支工作流程复杂很多,为更大型的项目提供了强劲的管理框架。 本流程

    最全Mac工具

      MacTool Mac 开源免费工具汇总, 只罗列开源好用的。更全列表请参考awesome-mac 必备 Homebrew - 体验通过命令行安装 Mac 软件的工具(大部分是

    工具集001

      1.  Google项目管理工具 Tables   2. 终端 taskwarrior --- TODO List Taskwarrior is

    代码评审流程(摘要)

    代码评审流程(摘要)

    工具集002

      文件对比 https://www.diffchecker.com/excel-diff 快速找出类似文件的不同之处。  

    完整研发流程中用到的环境类型和协作关系

    研发流程有多个不同的环节构成,一般分为开发、测试、验证和部署,这些环节需要不同的环境来支撑。对于企业来说,这些环境又需要互相配合来完成正常的研发部署工作,为了避免混乱的相互引用、提高协作的效率,界定

    Gfast 工作流引擎 1.0 正式发布

    Gfast管理系统采用go语言开发,基于GF(Go Frame)的后台管理系统,现增加工作流引擎模块开源发布,实现工作流引擎与业务解绑,不同业务数据均可接入,以业务数据驱动的状态机机制,让

    关系数据库管理系统openGauss 1.0.1版本发布

    openGauss简介 openGauss是一款开源关系数据库管理系统,采用木兰宽松许可证v2发行。openGauss内核源自PostgreSQL,深度融合华为在数据库领域多年的经验,结合企业级

    数据生成工具 ZenData 发布 1.5 版本,新增 CSV 和 Excel 输出格式,字段定义支持表达式

    随着DevOps的日益流行,越来越多的团队开始关注持续集成和持续交付。在这种大背景下,自动化测试就越来越重要了。那么问题来了,如何能够实现大规模、工程化的自动化测试呢?这里面会涉及到诸多的问题,比如

    Kooteam 0.1.3 发布,重构系统日志模块,简化安装流程

    Kooteam是一款轻量级的在线团队协作工具,提供各类文档工具、在线思维导图、在线流程图、项目管理、任务分发等工具,并接入了微信小程序,钉钉开放平台,使用便捷高效。

    老板要我开发一个简单的工作流引擎

    第1关 一天,老板找到我,说要做个简单的工作流引擎。 我查了一天啥是工作流,然后做出了如下版本: 按顺序添加任意个审批人组成一个链表,最后加一个结束节点 记录当前审批人,当审批完后,审批人向后

    WeCube 2.7.0 版本发布,一站式架构和运维管理工具

    WeCube简介 微众银行在分布式架构实践的过程中,发现将银行核心系统构建于分布式架构之上,会遇到一些与传统单体应用不同的痛点(例如,服务器增多,部署难度大;调用链长,全链路跟踪困难; 系统复杂,问题定位时间长等),在逐步解决这些痛点的过程中,总...

    Hikyuu 1.1.5 发布,量化交易研究框架

    Hikyuu Quant Framework是一款基于C++/Python的开源量化交易研究框架,用于策略分析及回测。其核心思想基于当前成熟的系统化交易方法,将整个系统化交易抽象为由市场环境判断策略

    mongoHelper 0.3.9 发布,spring-data-mongodb 增强工具包,简化 CRUD 操作

    mongoHelper 是基于 spring-data-mongodb 的增强工具包,简化 CRUD 操作,提供类 jpa 的数据库操作。 传统关系数据库及围绕它们构建的 orm 在项目开发中有很

    还在为朋友圈积赞苦恼么

      还在为朋友圈积赞苦恼么 分分钟搞定 github地址--- https://github.com/TransparentLC/WechatMomentScreenshot 网站地址---- https://akarin.dev/We...

    IntelliJ IDEA 开启很慢,运行不流畅,大项目卡顿?一招配置解决!

    来源:Java面试题精选 一、前言 IDEA默认启动配置主要考虑低配置用户,参数不高(默认最低128m,最高512m),导致启动慢,然后运行也不流畅,这里我们需要优化下启动和运行配置;但是在工作