跳转到内容

分布式版本控制

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

程序设计中,分布式版本控制(英语: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) (英语). 

外部链接

[编辑]