跳转到内容

分散式版本控制

本页使用了标题或全文手工转换
维基百科,自由的百科全书

程式设计中,分散式版本控制(英语:distributed revision controldistributed version control,又译为分布式版本控制),又称去中心化版本控制decentralized version control),是一种版本控制的方式,它允许软体开发者可以共同参与一个软体开发专案,但是不必在相同的网路系统下工作。其作法是在每个开发者电脑中复制一份完整的代码库以及完整历史[1]。因此在无法连接网路时,仍可以进行软体的分支合并,可以加速大部份的作业,增加此情形可以进行的工作,而且系统的代码库可以在多家电脑上备份,不需靠单一位置的备份[1][2][3][4]。而多个位置的代码库再透过其他机制来达到同步。

以分散式版本控制方法,作出的软体版本控制系统,称为分散式版本控制系统(distributed revision control system,缩写为DRCS,或是distributed version control system,缩写为DVCS)。著名的分散式版本控制系统有Monotone、Git等。

分散式和集中式版本控制系统的比较

[编辑]

分散式版本控制系统(DVCS)用对等网路的作法来处理版本控制,而集中式版本控制系统则是用主从式架构的作法。分散式版本控制系统同步各软件存储库的方式是用对等网路的方式传送Patch。在代码库中没有单一的中央版本,每一个用户都有工作复本以及完整的变更历史。

和集中式版本控制系统相比,分散式版本控制系统的优点如下:

  • 用户在没有网路的情形下,也可以存取其电脑中的软件存储库。
  • DVCS下的常见工作(例如上传、看修改履历、回退变更)不需要和中央伺服器通讯即可达成,因此速度很快[5]。DVCS下,只有要和其他人分享变更内容时才需要通讯。
  • 允许个人作业,使用者可以将不希望公开的早期修改(甚至是草稿)上传[来源请求]
  • 工作复本的作用类似远端备份,因此不会依赖单一的实体机器,带来单点失效的风险[5]
  • 允许不同的开发模型,例如用分支或Commander/Lieutenant模型[来源请求]
  • 自由及开放源代码软件专案中,若有管理上的冲突或是设计上的不一定,很容易可以从一专案中分叉出新的专案。

和集中式版本控制系统相比,分散式版本控制系统的缺点如下:

  • 一开始复制软件存储库会比较慢,因为预设设值会复制所有的分支以及版本历史。
  • 缺乏了集中式版本控制系统中有的锁定机能,针对一些无法用版本控制系统合并的二进位档案(例如图形档),或是太复杂的二进位或XML档案(例如office文件、PowerBI档、SQL Server Data Tools BI软体等)[来源请求]
  • 每一个使用者都需要备份所有的资料、分支及版本历史,因此需要额外的储存空间[6]
  • 各软件存储库内容不一定同步。

有些版本控制系统原来是集中式的,但也会加入一些分散式的特点。例如Subversion的许多机能可以在没有网路时执行[7]Visual Studio Online和Visual Studio Team Services除了集中式的版本管理外,也支援用Git进行的分散式版本控制。

也有些分散式版本控制系统设法要改善取出(checkout)时间以及储存成本的问题,例如微软开发的Git虚拟文件系统就可以在很大的代码库下运作[8],会提供一个虚拟档案系统,只在有需要时才会下载档案到电脑中。

工作模式

[编辑]

分散式版本控制比较适合大型专案,有一部份由独立的工作者所开发,像是Linux核心计划,因为开发者可以独立工作,可以提交其合并修改(或是拒绝他人的合并修改)。分散式模型的灵活性可以配合客制化的程式码产生工作流程。最常使用的是整合式工作流英语integrator workflow。在集中型的模型中,开发者需要将其工作串列化,以避免不同版本之间的问题。

中心存储库及分支存储库

[编辑]

每一个专案都有中心存储库,一般也是官方的存储库,会用专案维护者管理。开发者会复制中心存储库的内容,建立本地存储库。开发者再定期确认中心存储库的修改内容,使本地存储库和中心存储库同步。

开发者在本地存储库建立新的分支,在分支上修改程式码。在开发完成之后,再将修改内容整合到中心存储库。

拉取请求

[编辑]

在分散式版本控制的软体中,若要修改软体,一般会用“拉取请求”(pull request)来进行,也称为“合并请求”(merge request)[9]。贡献者请专案维护者“拉取”修改的软体内容(因此称为拉取请求),若此修改内容应该成为正式代码库的一部份,就需要合并拉取请求中提到的软体内容[10]

开发者在有新的软体变更时,会提出“拉取请求”,告䜣专案维护者有新的软体变更。一般而言每一个拉取请求会有对应的讨论串,可以针对软体修改的内容进行讨论(代码审查)。可以存取存储库的人都可以看到提交的拉取请求。专案维护者可以接受或是拒绝拉取请求的内容[11]

若拉取请求经过审查,已被核可,就会合并到存储库中。依工作流程的不同,有可能在加入这段程式的软体版本正式发行前,进行软体的测试。因此,有些专案会有一个特殊的分支,合并未测试的拉取请求[10][12]。也有些专案会有自动化测试平台,执行并测试每一个拉取请求的内容,可能会用持续整合工具(例如Travis CI),再由审查者检查新的程式码测试覆盖率是否足够。

历史

[编辑]

第一代的开源分散式版本控制系统有GNU archMonotoneDarcs英语Darcs,不过开源的分散式版本控制系统一开始并不太流行,直到GitMercurial发布后才流行。

在2002年至2005年时,Linux内核的开发是透过BitKeeper[13]Git会推出的原因就是因为BitKeeper的公司收回了给Linus Torvalds及Linux核心开发者的免费软体授权[13]

相关条目

[编辑]

参考文献

[编辑]
  1. ^ 1.0 1.1 Chacon, Scott; Straub, Ben. Getting Started – About Version Control. Pro Git 2nd. Apress. 2014. Chapter 1.1 [4 June 2019]. (原始内容存档于2020-12-20). 
  2. ^ Spolsky, Joel. Distributed Version Control Is Here to Stay, Baby. Joel on Software. 2010-03-17 [4 June 2019]. (原始内容存档于2016-11-27). 
  3. ^ Intro to Distributed Version Control (Illustrated). www.betterexplained.com. [7 January 2018]. (原始内容存档于2020-11-09). 
  4. ^ What Is Git ? – Explore A Distributed Version Control Tool. www.edureka.co. [7 January 2018]. (原始内容存档于2020-10-12). 
  5. ^ 5.0 5.1 O'Sullivan, Bryan. Distributed revision control with Mercurial 请检查|url=值 (帮助). [July 13, 2007]. (原始内容存档于2009-02-20). 
  6. ^ What is version control: centralized vs. DVCS. www.atlassian.com. [7 January 2018]. (原始内容存档于2020-10-30). 
  7. ^ OSDir.com. Subversion for CVS Users :: OSDir.com :: Open Source, Linux News & Software. OSDir.com. [2013-07-22]. (原始内容存档于2016-08-23).  |url-status=|dead-url=只需其一 (帮助)
  8. ^ Jonathan Allen. How Microsoft Solved Git's Problem with Large Repositories. 2017-02-08 [2019-08-06]. (原始内容存档于2020-05-20). 
  9. ^ Sijbrandij, Sytse. GitLab Flow. GitLab. 29 September 2014 [4 August 2018]. (原始内容存档于2019-09-26). 
  10. ^ 10.0 10.1 Johnson, Mark. What is a pull request?. Oaawatch. 8 November 2013 [27 March 2016]. (原始内容存档于2020-06-16). 
  11. ^ Using pull requests. GitHub. [27 March 2016]. (原始内容存档于2019-01-28). 
  12. ^ Making a Pull Request. Atlassian. [27 March 2016]. (原始内容存档于2020-02-06). 
  13. ^ 13.0 13.1 McAllister, Neil. Linus Torvalds' BitKeeper blunder. InfoWorld. [2017-03-19]. (原始内容存档于2015-08-26) (英语). 

外部链接

[编辑]