在程式设计中，分散式版本控制（英语：distributed revision control 或 distributed version control，又译为分布式版本控制），又称去中心化版本控制（decentralized version control），是一种版本控制的方式，它允许软件开发者可以共同参与一个软件开发专案，但是不必在相同的网络系统下工作。其作法是在每个开发者电脑中复制一份完整的代码库以及完整历史。因此在无法连接网络时，仍可以进行软件的分支及合并，可以加速大部分的作业，增加此情形可以进行的工作，而且系统的代码库可以在多家电脑上备份，不需靠单一位置的备份。而多个位置的代码库再透过其他机制来达到同步。
以分散式版本控制方法，作出的软件版本控制系统，称为分散式版本控制系统（distributed revision control system，缩写为DRCS，或是distributed version control system，缩写为DVCS）。著名的分散式版本控制系统有Monotone、Git等。
分散式版本控制系统（DVCS）用对等网络的作法来处理版本控制，而集中式版本控制系统则是用主从式架构的作法。分散式版本控制系统同步各软件存储库的方式是用对等网络的方式传送Patch。在代码库中没有单一的中央版本，每一个用户都有工作复本以及完整的变更历史。
和集中式版本控制系统相比，分散式版本控制系统的优点如下：
和集中式版本控制系统相比，分散式版本控制系统的缺点如下：
有些版本控制系统原来是集中式的，但也会加入一些分散式的特点。例如Subversion的许多机能可以在没有网络时执行。Visual Studio Online和Visual Studio Team Services除了集中式的版本管理外，也支援用Git进行的分散式版本控制。
也有些分散式版本控制系统设法要改善取出（checkout）时间以及储存成本的问题，例如微软开发的Git虚拟文件系统就可以在很大的代码库下运作，会提供一个虚拟档案系统，只在有需要时才会下载档案到电脑中。
分散式版本控制比较适合大型专案，有一部分由独立的工作者所开发，像是Linux核心计划，因为开发者可以独立工作，可以提交其合并修改（或是拒绝他人的合并修改）。分散式模型旳灵活性可以配合客制化的程式码产生工作流程。最常使用的是整合式工作流（英语：integrator workflow）。在集中型的模型中，开发者需要将其工作串列化，以避免不同版本之间的问题。
每一个专案都有中心存储库，一般也是官方的存储库，会用专案维护者管理。开发者会复制中心存储库的内容，建立本地存储库。开发者再定期确认中心存储库的修改内容，使本地存储库和中心存储库同步。
开发者在本地存储库建立新的分支，在分支上修改程式码。在开发完成之后，再将修改内容整合到中心存储库。
在分散式版本控制的软件中，若要修改软件，一般会用“拉取请求”（pull request）来进行，也称为“合并请求”（merge request）。贡献者请专案维护者“拉取”修改的软件内容（因此称为拉取请求），若此修改内容应该成为正式代码库的一部分，就需要合并拉取请求中提到的软件内容。
开发者在有新的软件变更时，会提出“拉取请求”，告䜣专案维护者有新的软件变更。一般而言每一个拉取请求会有对应的讨论串，可以针对软件修改的内容进行讨论（代码审查）。可以存取存储库的人都可以看到提交的拉取请求。专案维护者可以接受或是拒绝拉取请求的内容。
若拉取请求经过审查，已被核可，就会合并到存储库中。依工作流程的不同，有可能在加入这段程式的软件版本正式发行前，进行软件的测试。因此，有些专案会有一个特殊的分支，合并未测试的拉取请求。也有些专案会有自动化测试平台，执行并测试每一个拉取请求的内容，可能会用持续整合工具（例如Travis CI），再由审查者检查新的程式码测试覆盖率是否足够。
第一代的开源分散式版本控制系统有GNU arch、Monotone和Darcs（英语：Darcs），不过开源的分散式版本控制系统不太流行，一直到Git及Mercurial发布后才流行。
在2002年至2005年时，Linux内核的开发是透过BitKeeper。Git会推出的原因就是因为BitKeeper的公司收回了给Linus Torvalds及Linux核心开发者的免费软件授权。
