【译】5种Git工作流改善你的开发流程

1,335 阅读6分钟

alt

掘金翻译计划
原文地址:文章链接

我还从没见过哪个开发者看到冲突信息不会沮丧的扯头发。

尝试解决每个合并冲突是每个开发者讨厌的,尤其当你正准备上线部署的时候。

这就是正确设置Git工作流可以为你的开发工作带来巨大的好处。

当然,拥有正确的Git工作流并不会为你解决所有的问题,但这是朝着正确方向迈出的一步。 毕竟,当每个团队都在远程工作时,在不破坏代码库的情况一起构建需求是至关重要的。

你如何设置它取决与你正在进行的项目,你团队的发布时间表,团队规模等!

这篇文章中,我们会带你通过5中不同的Git工作流了解,它们的优点,缺点,以及你何时需要使用它们,我们开始吧!

1.基础Git工作流

最基础的工作流就是仅有一个分支--主分支。开发者直接向它提交,并用它来部署到平台和生产环境中。 alt

					[基本的Git工作流,所有提交都直接添加到主分支]  

这种工作流通常不被推荐除非你在一个独立的项目工作,并且你想要快速上手。

由于只有一条分支,这里实际上没有进程。这使得开始使用Git变得毫不费力,然而,你需要记住使用这种工作留流时的一些缺点:

1.在代码上进行写作将导致多个冲突。
2.将有缺陷的软件交付生产的几率变高。 3.维护干净的代码更困难。

2.Git特性分支工作流

Git特性功能分支工作流变成必需的,当多个开发人员在同一个代码库中工作时。

想象下你有一个开发人员在开发新的功能。并且其他的开发者在开发第二个功能。这时,如果他们从相同的分支开发并且提交,这使代码库变得非常混乱,并产生大量冲突。 alt

							[具有特性分支的Git工作流]  

为了避免这种情况,两个开发者可以从主分支中创建两个独立的分支,并且在他们的功能分支上独立开发。当他们完成他们的功能,他可以合并他们各自的分支到主分支上,而且不用等待第二个特性完成就可以进行部署。

使用这种工作流的优点是,Git特性分支工作流在代码协作中,不用担心代码冲突。

3.Git特性工作流与开发分支

在这种工作流中,主分支总是反映生产就绪的状态。无论何时团队想要部署到生产环境,他们就会从主分支进行部署。

开发分支反映了下个版本最新交付的开发变更的状态。开发者从开发分支创建新的特性分支开发新功能。一旦功能分支准备好了,就对它进行测试,合并到开发分支,与开发分支的代码进行测试,避免之前发生了合并,然后将它们合并到主分支。 alt

            				 [Git特性工作流与开发分支]  

这种工作流的好处是,可以让团队一致地合并新特性,在准备阶段测试它,并且部署到生产环境。虽然维护代码很简单,但对于一些团队来说,他可能有些烦人,因为感觉像是经历一个乏味的过程。

4.Gitflow工作流

Gitflow工作流和我们之前讨论的与其他两个分支(发布分支和热修复分支)相结合的工作流很相似。

热修复分支

热修复分支是唯一从主分支创建并直接合并到主分支而不是开发分支的分支。它仅被用来快速给线上问题打补丁。这个分支的优点是,它能让你快速部署线上问题,而不打扰其他工作流或不用等待下次发布周期。

一旦修复合并到主分支并部署后,它应该被同时合并到开发和当前的发布分支。这样是为确保任何人从开发分支复制代码创建的新特性分支都有最新的代码。

发布分支

发布分支是,在开发分支为发布计划的所有特性成功合并其中之后从开发分支派生出来的。

没有新特性相关的代码添加到发布分支。仅有发布相关的代码会被添加到发布分支,例如,文档,缺陷修复,其他一些发布相关的任务会被添加到这个分支。

一旦这个分支被合并到主分支并部署到生产环境,它还会被合并到开发分支,这样当一个新特性从开发分支派生出来时,也会拥有最新的代码。 alt

           					 [Gitflow工作流与热修复和发布分支]

Vincent Driessen 首次发表了这种工作流,并且使之流行起来,它被广泛应用于有发布周期的组织。

由于Git是一个包装器,你可以安装Git-flow到你当前的仓库中,它是非常简单的过程,除了给你创建分支以外,不会改变仓库中任何东西。

在Mac机器上安装,在终端运行 brew install git-flow

在Windows机器上安装,你需要下载并安装 download and install the git-flow. 。安装完之后,在项目中执行 git flow init

5.Git Fork工作流

Fork工作流在开源软件团队中很流行。
流程通常是这样的:

1.开发者从开源软件官方库派生。在自己账户中创建这个仓库的副本。 2.开发者从他们的账户中克隆这个仓库到他们本地系统。 3.官方仓库的远端路径被添加克隆到本地系统的仓库中。 4.开发者在本地系统中创建新特性分支,改动写些东西,然后提交它们。 5.这些分支上的改动被推送到开发者账户复制的仓库副本中。 6.来自分支的拉取请求被打开到官方仓库。 7.官方库的管理者检查变更并允许变更合并到官方仓库。