Git教程 之 版本控制
- Git教程 之 版本控制
- 版本控制
- 版本控制类型
- 单用户版本控制系统（VCS）
- 单用户版本控制系统（VCS）特点
- 常见的单用户版本控制系统（VCS）
- 集中式版本控制系统（CVCS）
- 集中式版本控制系统（CVCS）特点
- 常见集中式版本控制系统（CVCS）
- 常见集中式版本控制系统（CVCS）局限
- 分布式版本控制系统（DVCS）
- 分布式版本控制系统（DVCS）特点
- 常见分布式版本控制系统（DVCS）
- Git
- 分布式版本控制系统（DVCS）特性
- 版本控制总结
Git教程 之 版本控制
版本控制
版本控制（Version Control），也称为修订控制（Revision Control）或源代码管理（Source Code Management, SCM），是一种用于管理对文档、计算机程序、大型网站和其它信息集合的更改的技术。它使得团队成员能够协作工作，同时跟踪每一个修改，并且可以在需要时恢复到以前的版本。
** 上面的介绍太官方** 看起来不是很清楚。
其实举个我们实际生活中的例子，如果你写过毕业论文的话。我们的毕业论文一般都要有很多次修改，而且我们是用word编辑毕设论文，那么在这个过程中，会出现什么情况呢？
而且很容易出现，我们忘记保存，或者改名字改错了把一些版本给覆盖的情况，是不是，所以在这个地方，我们需要一种管理工具，能够有效跟踪我们的每一个修订，而且可以恢复到任何一个版本，也许我们还会需要能够对比两次版本的差异等等功能，而不是我们手动去改（这样极容易出错）。
版本控制类型
由版本控制的发展历史来，我们的版本控制发展，大概分为三个类型：单用户版本控制系统（VCS）、集中式版本控制系统（CVCS）、
分布式版本控制系统（DVCS）。单用户的版本控制只能提供单机的版本控制，现代的版本控制一般是为了多人协作，所以我们就简单介绍一下单用户版本控制系统（VCS），主要大家使用的是集中式版本控制系统（CVCS）、分布式版本控制系统（DVCS）。
单用户版本控制系统（VCS）
单用户版本控制系统（VCS），也称为本地版本控制系统，是最早期的一种版本控制形式，主要用于个人项目或单一开发者的环境中。这类系统的主要目的是帮助开发者跟踪文件的修改历史，以便能够在需要时恢复到之前的版本。尽管它们的功能相对简单，但对于小型项目或者个人工作来说已经足够
单用户版本控制系统（VCS）特点
- 本地化
- 简单
- 提供基础的历史记录能力
- 缺乏分支能力
- 多人协作能力有限
常见的单用户版本控制系统（VCS）
- RCS (Revision Control System)
- SCCS (Source Code Control System)
- Pristine File System (PFS)
集中式版本控制系统（CVCS）
集中式版本控制系统通过一个中央服务器存储所有版本库的数据，开发者从服务器检出代码进行修改，然后提交回服务器。常见的 CVCS 工具包括 CVS 和 Subversion (SVN)。
集中式版本控制系统（CVCS）特点
- 单一中央仓库
- 依赖网络
- 权限控制
- 修订记录跟踪
- 支持多人协作
常见集中式版本控制系统（CVCS）
- CVS (Concurrent Versions System)
- Subversion (SVN)
- Perforce Helix Core
常见集中式版本控制系统（CVCS）局限
因为上面介绍的集中式版本控制系统（CVCS）特点，所以它的局限点在于
- 单点故障， 中央仓库如果出现故障，则整个系统不可用
- 使用的时候需要网络与中央仓库连接
- 多人协作解决冲突比较繁琐
分布式版本控制系统（DVCS）
**分布式版本控制系统（Distributed Version Control System, DVCS）**是一种将整个代码库，包括其完整历史记录，复制到每个开发者本地的工作副本中的版本控制系统。与集中式版本控制系统不同，DVCS 不依赖于中央服务器来管理版本库；相反，每个开发者都拥有一个完整的、独立的仓库副本。这种设计带来了许多优势，尤其是在团队协作和离线工作方面。
分布式版本控制系统（DVCS）特点
- 分布式存储
- 可以支持离线工作
- 快速操作
- 强大的合并能力
常见分布式版本控制系统（DVCS）
- Bazaar (bzr)
- Mercurial (Hg)
- Git
Git
- 由 Linus Torvalds 创建：Git 是为了帮助 Linux 内核开发而创建的，自 2005 年发布以来迅速成为最流行的 DVCS。
- 高性能：Git 的设计目标之一就是高效处理大规模项目，它使用 SHA-1 散列值来确保数据完整性和安全性。
- 社区支持广泛：拥有庞大的用户群体和活跃的开源社区，提供了丰富的文档和工具链。
- GitHub 等平台的支持：像 Gitcode、Codehub 和 Gitee以及Github 这样的平台极大地促进了 Git 的普及，为开发者提供托管服务、问题跟踪、持续集成等功能。
分布式版本控制系统（DVCS）特性
- 不依赖网络，可以提高生产力
- 更好的协作体验，git的创建分支都是非常轻量的操作
- 可靠性，因为每一个用户都有完整的仓库记录
- 可以构造多种工作流程，常见的工作流程如下
- 中心化工作流（Centralized Workflow）
- 功能分支工作流（Feature Branch Workflow）
- Gitflow 工作流
- Forking 工作流
- GitHub Flow
- Trunk-Based Development
- Branch by Abstraction
简单介绍一些工作流程
- 中心化工作流（Centralized Workflow）
这是最简单的 Git 工作流，类似于集中式版本控制系统（CVCS）的工作方式。所有开发者都从一个中央仓库拉取代码，在本地进行开发后，再推送到中央仓库。
- 优点：易于理解和实现，适合小型团队或项目。
- 缺点：单点故障风险，如果中央仓库出现问题，整个团队的开发都会受到影响。
- 功能分支工作流（Feature Branch Workflow）
在这种工作流中，开发者为每个新功能创建一个独立的分支。功能完成后，将分支合并回主分支（如 main 或 master）。这允许并行开发多个功能，同时保持主分支的稳定性。
- 优点：促进并行开发，减少主分支上的冲突。
- 缺点：需要良好的分支管理和合并策略来避免复杂的合并历史。
- Gitflow 工作流
Gitflow 是一种更结构化的分支管理模型，特别适用于发布周期明确的项目。它定义了几个长期存在的分支：
- main / master：用于稳定发布的代码。
- develop：用于集成所有正在开发的功能。
- feature/*：用于开发特定功能的短期分支。
- release/*：当准备发布时，从 develop 分支创建，用来做最后的调整和测试。
- hotfix/*：紧急修复直接应用于 main 和 develop 分支。
- 优点：清晰的角色分配，支持复杂的发布流程。
- 缺点：对于小型或快速迭代的项目来说可能过于复杂。
- Forking 工作流
Forking 模型通常用于开源项目，每个贡献者都有自己的远程仓库副本（fork）。开发者在自己的 fork 上进行开发，然后通过 Pull Request（PR）请求合并到上游的主仓库。
- 优点：确保只有经过审查的更改才能进入主仓库，保护了主仓库的完整性。
- 缺点：增加了协作成本，因为每次贡献都需要通过 PR 流程。
选择合适的工作流取决于团队规模、项目需求和技术栈等因素。对于大多数团队而言，功能分支工作流和 Gitflow 是比较流行的选择，它们提供了足够的灵活性和结构性来适应不同的开发场景。而对于开源项目或外部贡献较多的情况，Forking 模型则更为合适。就我现在的工作情况，我们目前就是采用的功能分支工作流这种工作方式。
版本控制总结
如果是初学者，你只需要了解一下版本控制的概念，以及为什么我们需要版本控制，重点了解一下Git与分布式版本控制的概念，如果感觉这些概念有些陌生，也没有关系，后续我会继续发完整的Git的入门的知识，等看完后续的文章，估计就可以对这些概念有一个比价深入的理解，请大家继续关注我。也欢迎大家评论，点赞，收藏。
