【Git教程 之 版本控制】

Git教程 之 版本控制

版本控制

版本控制（Version Control），也称为修订控制（Revision Control）或源代码管理（Source Code Management, SCM），是一种用于管理对文档、计算机程序、大型网站和其它信息集合的更改的技术。它使得团队成员能够协作工作，同时跟踪每一个修改，并且可以在需要时恢复到以前的版本。

** 上面的介绍太官方** 看起来不是很清楚。
其实举个我们实际生活中的例子，如果你写过毕业论文的话。我们的毕业论文一般都要有很多次修改，而且我们是用word编辑毕设论文，那么在这个过程中，会出现什么情况呢？

而且很容易出现，我们忘记保存，或者改名字改错了把一些版本给覆盖的情况，是不是，所以在这个地方，我们需要一种管理工具，能够有效跟踪我们的每一个修订，而且可以恢复到任何一个版本，也许我们还会需要能够对比两次版本的差异等等功能，而不是我们手动去改（这样极容易出错）。

版本控制类型

由版本控制的发展历史来，我们的版本控制发展，大概分为三个类型：单用户版本控制系统（VCS）、集中式版本控制系统（CVCS）、
分布式版本控制系统（DVCS）。单用户的版本控制只能提供单机的版本控制，现代的版本控制一般是为了多人协作，所以我们就简单介绍一下单用户版本控制系统（VCS），主要大家使用的是集中式版本控制系统（CVCS）、分布式版本控制系统（DVCS）。

单用户版本控制系统（VCS）

单用户版本控制系统（VCS），也称为本地版本控制系统，是最早期的一种版本控制形式，主要用于个人项目或单一开发者的环境中。这类系统的主要目的是帮助开发者跟踪文件的修改历史，以便能够在需要时恢复到之前的版本。尽管它们的功能相对简单，但对于小型项目或者个人工作来说已经足够

单用户版本控制系统（VCS）特点

1. 本地化
2. 简单
3. 提供基础的历史记录能力
4. 缺乏分支能力
5. 多人协作能力有限

常见的单用户版本控制系统（VCS）

1. RCS (Revision Control System)
2. SCCS (Source Code Control System)
3. Pristine File System (PFS)

集中式版本控制系统（CVCS）

集中式版本控制系统通过一个中央服务器存储所有版本库的数据，开发者从服务器检出代码进行修改，然后提交回服务器。常见的 CVCS 工具包括 CVS 和 Subversion (SVN)。

集中式版本控制系统（CVCS）特点

1. 单一中央仓库
2. 依赖网络
3. 权限控制
4. 修订记录跟踪
5. 支持多人协作

常见集中式版本控制系统（CVCS）

1. CVS (Concurrent Versions System)
2. Subversion (SVN)
3. Perforce Helix Core

常见集中式版本控制系统（CVCS）局限

因为上面介绍的集中式版本控制系统（CVCS）特点，所以它的局限点在于

• 单点故障， 中央仓库如果出现故障，则整个系统不可用
• 使用的时候需要网络与中央仓库连接
• 多人协作解决冲突比较繁琐

分布式版本控制系统（DVCS）

**分布式版本控制系统（Distributed Version Control System, DVCS）**是一种将整个代码库，包括其完整历史记录，复制到每个开发者本地的工作副本中的版本控制系统。与集中式版本控制系统不同，DVCS 不依赖于中央服务器来管理版本库；相反，每个开发者都拥有一个完整的、独立的仓库副本。这种设计带来了许多优势，尤其是在团队协作和离线工作方面。

分布式版本控制系统（DVCS）特点

1. 分布式存储
2. 可以支持离线工作
3. 快速操作
4. 强大的合并能力

常见分布式版本控制系统（DVCS）

1. Bazaar (bzr)
2. Mercurial (Hg)
3. 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

简单介绍一些工作流程

1. 中心化工作流（Centralized Workflow）
   这是最简单的 Git 工作流，类似于集中式版本控制系统（CVCS）的工作方式。所有开发者都从一个中央仓库拉取代码，在本地进行开发后，再推送到中央仓库。

• 优点：易于理解和实现，适合小型团队或项目。
• 缺点：单点故障风险，如果中央仓库出现问题，整个团队的开发都会受到影响。

2. 功能分支工作流（Feature Branch Workflow）
   在这种工作流中，开发者为每个新功能创建一个独立的分支。功能完成后，将分支合并回主分支（如 main 或 master）。这允许并行开发多个功能，同时保持主分支的稳定性。

• 优点：促进并行开发，减少主分支上的冲突。
• 缺点：需要良好的分支管理和合并策略来避免复杂的合并历史。

3. Gitflow 工作流
   Gitflow 是一种更结构化的分支管理模型，特别适用于发布周期明确的项目。它定义了几个长期存在的分支：

• main / master：用于稳定发布的代码。
• develop：用于集成所有正在开发的功能。
• feature/*：用于开发特定功能的短期分支。
• release/*：当准备发布时，从 develop 分支创建，用来做最后的调整和测试。
• hotfix/*：紧急修复直接应用于 main 和 develop 分支。
• 优点：清晰的角色分配，支持复杂的发布流程。
• 缺点：对于小型或快速迭代的项目来说可能过于复杂。

4. Forking 工作流
   Forking 模型通常用于开源项目，每个贡献者都有自己的远程仓库副本（fork）。开发者在自己的 fork 上进行开发，然后通过 Pull Request（PR）请求合并到上游的主仓库。

• 优点：确保只有经过审查的更改才能进入主仓库，保护了主仓库的完整性。
• 缺点：增加了协作成本，因为每次贡献都需要通过 PR 流程。

选择合适的工作流取决于团队规模、项目需求和技术栈等因素。对于大多数团队而言，功能分支工作流和 Gitflow 是比较流行的选择，它们提供了足够的灵活性和结构性来适应不同的开发场景。而对于开源项目或外部贡献较多的情况，Forking 模型则更为合适。就我现在的工作情况，我们目前就是采用的功能分支工作流这种工作方式。

版本控制总结

如果是初学者，你只需要了解一下版本控制的概念，以及为什么我们需要版本控制，重点了解一下Git与分布式版本控制的概念，如果感觉这些概念有些陌生，也没有关系，后续我会继续发完整的Git的入门的知识，等看完后续的文章，估计就可以对这些概念有一个比价深入的理解，请大家继续关注我。也欢迎大家评论，点赞，收藏。