【Git】版本控制器的方式：SVN集中式版本控制工具和Git分布式版本控制工具

一、应用场景
二、版本控制器的方式
三、SVN 集中式版本控制工具
四、Git 分布式版本控制工具
五、Git工作流程

一、应用场景

Git 在开发过程中提供了多种应用场景，帮助开发团队高效地管理代码、协同工作，并保证代码质量。以下是一些具体应用场景和相应的操作方法：

1. 备份

场景

定期备份代码库，以防止数据丢失。

操作

定期推送（Push）代码到远程仓库：确保本地代码的更改及时同步到远程仓库。
```
git push origin <branch-name>
```

2. 代码还原

场景

需要恢复到之前的某个稳定版本，或者撤销某次错误的提交。

操作

查看提交历史：找到需要还原的提交。
```
git log
```
回退到某个提交：使用 reset 或 revert 命令。
- 硬回退（删除回退后的更改）：
```
git reset --hard <commit-hash>
```
- 软回退（保留回退后的更改在暂存区）：
```
git reset --soft <commit-hash>
```
- 创建回滚提交（不删除历史）：
```
git revert <commit-hash>
```

3. 协同开发

场景

多个开发人员同时在不同的功能或模块上工作，需要合并代码并解决冲突。

操作

创建和切换分支：每个开发人员在自己的分支上工作。
```
git checkout -b <feature-branch>
```
推送分支到远程仓库：
```
git push origin <feature-branch>
```
合并分支：将功能分支合并到主分支（如main或develop）。
```
git checkout <main-branch>
git merge <feature-branch>
```

解决冲突：如果有合并冲突，手动解决后继续提交。

git add <resolved-files>
git commit -m "Resolved merge conflict"

4. 追溯问题代码的编写人和编写时间

场景

需要查明某段代码的具体编写人及其时间，以便进行代码审查或问题追踪。

操作

查看文件的详细修改历史：
```
git blame <file>
```
这会显示文件每行的最后一次提交信息，包括提交者和提交时间。
查看某个文件的历史记录：
```
git log -p <file>
```
这会显示该文件的所有提交历史及每次提交的具体变更。

使用 IntelliJ IDEA 进行这些操作

备份和推送：
- 提交更改后，选择 VCS > Git > Push。
代码还原：
- 查看提交历史：VCS > Git > Show History。
- 右键选择特定提交，可以选择 Reset Current Branch to Here 或 Revert Commit。
协同开发：
- 创建和切换分支：点击右下角当前分支，选择 New Branch 或 Checkout.
- 合并分支：点击右下角当前分支，选择 Merge into Current。
- 解决冲突：在冲突解决界面手动选择保留的代码，完成后提交。
追溯问题代码：
- 右键点击文件，选择 Git > Annotate，这相当于 git blame。

通过掌握这些应用场景和操作方法，你可以更好地利用Git进行代码管理和协作，提高开发效率和代码质量。

二、版本控制器的方式

版本控制工具可以大致分为集中式版本控制工具和分布式版本控制工具。两者在工作方式和操作流程上有明显的区别。

1. 集中式版本控制工具

工作方式

中央服务器：所有的代码版本库集中存放在中央服务器上。
工作流程：团队成员工作时从中央服务器下载代码，在本地进行开发和修改。修改完成后，再提交到中央服务器。
联网要求：必须联网才能从中央服务器下载和提交代码，适用于局域网或互联网。

优点

简单管理：所有版本数据集中存放，便于管理和备份。
权限控制：可以通过服务器端进行严格的权限管理。

缺点

单点故障：中央服务器若出现故障，整个团队将无法继续工作。
联网依赖：必须联网才能进行代码的提交和获取更新。

举例

SVN (Subversion)：一个广泛使用的集中式版本控制工具，提供了强大的版本管理功能。
CVS (Concurrent Versions System)：一种老牌的集中式版本控制工具，在早期被广泛使用。

操作流程示例（以SVN为例）

# 检出代码
svn checkout <repository-url># 更新代码
svn update# 添加文件
svn add <file># 提交更改
svn commit -m "Commit message"# 查看日志
svn log

2. 分布式版本控制工具

工作方式

分布式存储：没有中央服务器，每个开发者的电脑上都有完整的版本库。
工作流程：开发者可以在本地进行提交和管理版本，无需联网。多人协作时，通过推送和拉取来共享代码修改。

优点

离线工作：可以在本地进行完整的版本控制操作，无需依赖网络。
高容错性：每个开发者都有完整的版本库，不会因为某个节点的故障而丢失数据。
快速分支和合并：分支和合并操作非常快速和高效。

缺点

初期复杂性：对新手来说，理解和使用分布式版本控制工具的复杂性较高。
同步复杂性：多人协作时，可能会遇到更多的合并冲突和同步问题。

举例

Git：最流行的分布式版本控制工具，由Linus Torvalds开发，广泛用于开源和商业项目。
Mercurial：另一个流行的分布式版本控制工具，设计简洁且易于使用。

操作流程示例（以Git为例）

# 初始化仓库
git init# 克隆仓库
git clone <repository-url># 创建分支
git checkout -b <branch-name># 添加文件到暂存区
git add <file># 提交更改
git commit -m "Commit message"# 推送到远程仓库
git push origin <branch-name># 从远程仓库拉取更新
git pull origin <branch-name># 合并分支
git checkout <main-branch>
git merge <feature-branch># 查看历史记录
git log

总结

集中式版本控制工具（如SVN和CVS）依赖中央服务器，适合小型团队或局域网环境，管理和操作相对简单，但存在单点故障和联网依赖问题。
分布式版本控制工具（如Git和Mercurial）不依赖中央服务器，适合大中型团队和开源项目，提供更高的灵活性和容错性，但需要一定的学习成本和管理复杂性。

三、SVN 集中式版本控制工具

在这里插入图片描述

SVN（Subversion）是一个广泛使用的集中式版本控制系统，用于管理和跟踪文件及目录的历史记录。SVN最初由CollabNet公司开发，目前由Apache基金会维护和管理。SVN被广泛应用于软件开发项目中，以管理源代码、文档和其他文件的版本控制。

核心概念

仓库（Repository）：
- 存储项目的文件和目录，以及这些文件和目录的所有历史版本。仓库通常托管在中央服务器上，团队成员通过网络与仓库交互。
工作拷贝（Working Copy）：
- 开发人员从仓库检出的项目的本地副本。在工作拷贝上进行修改，然后提交回仓库。
修订（Revision）：
- 每次提交到仓库的更改都会生成一个新的修订号。每个修订号代表仓库的一个状态快照，可以通过修订号来查看或恢复到某个特定状态。
提交（Commit）：
- 将本地工作拷贝中的修改提交到仓库中，生成一个新的修订号。
更新（Update）：
- 将仓库中的最新更改合并到本地工作拷贝中。
添加（Add）和删除（Delete）：
- 将新文件或目录添加到版本控制中，或从版本控制中删除文件或目录。
分支（Branch）和标签（Tag）：
- 分支用于并行开发不同的功能或版本。标签用于标记特定的修订，通常用于发布版本。

SVN 的优点

集中式管理：所有代码和版本数据集中存储在中央服务器上，便于集中管理和备份。
简单易用：操作命令相对简单，适合小型团队和初学者。
历史记录和版本控制：能够详细跟踪每次提交的修改记录，方便版本追溯和管理。

SVN 的缺点

单点故障：中央服务器一旦发生故障，整个团队将无法继续工作，导致高风险。
联网依赖：必须联网才能进行提交和更新操作，不适合需要离线工作的场景。
性能问题：对于大型项目和团队，集中式管理方式可能导致性能瓶颈。

基本操作命令

检出仓库：
```
svn checkout <repository-url>
```
更新工作拷贝：
```
svn update
```
添加文件：
```
svn add <file>
```
删除文件：
```
svn delete <file>
```
提交更改：
```
svn commit -m "Commit message"
```
查看日志：
```
svn log
```

创建分支：

svn copy <repository-url>/trunk <repository-url>/branches/<branch-name> -m "Create branch"

合并分支：

svn merge <repository-url>/branches/<branch-name>

SVN 与 Git 的比较

架构：SVN是集中式版本控制系统，而Git是分布式版本控制系统。
工作方式：SVN依赖中央服务器，Git每个开发者都有完整的版本库。
性能：Git在分支和合并操作上更加高效，适合大型项目和团队。
灵活性：Git提供更多的功能和灵活性，但操作相对复杂。

典型应用场景

小型团队和项目：适合需要集中管理的项目，团队规模较小，版本控制需求简单的项目。
文档管理：除了代码，SVN也适用于版本化管理文档、配置文件等。

SVN 作为一个成熟的集中式版本控制工具，仍然在许多项目中得到广泛应用。了解SVN的基本概念和操作，可以帮助开发人员更好地进行代码管理和协作。

四、Git 分布式版本控制工具

在这里插入图片描述

Git是一个开源的分布式版本控制系统，由Linus Torvalds在2005年开发，用于高效地管理和追踪项目的版本控制，尤其适合处理大型项目如Linux内核的开发。

Git 的特点

分布式架构：
- 每个开发者的电脑上都有一个完整的版本库，包括项目的所有历史版本。
- 不需要依赖中央服务器，开发者可以在本地进行提交、查看历史记录等操作。
- 中央服务器主要用于方便团队之间交换代码，但它与每个开发者的PC地位相同，不是必须的。
高效处理：
- 可以快速处理从小型到大型项目的版本控制需求。
- 提供快速的分支和合并操作，支持非线性开发模式，允许同时进行成千上万个并行分支。
开源和跨平台：
- Git是开源软件，免费使用和分发。
- 支持跨平台使用，可以在Windows、MacOS和Linux等操作系统上运行。
可靠性和数据完整性：
- 使用SHA-1哈希值确保数据完整性，防止数据被篡改。
- 采用快照存储数据，而非差异存储，确保历史版本的准确性。

Git 的诞生背景

Linux 内核的管理需求：最初用于管理Linux内核开发，以解决提交补丁和保存归档的繁琐事务。
BitKeeper 的使用和替代：2002年起，Linux内核项目使用专有的BitKeeper版本控制系统。2005年，因与BitKeeper开发公司的合作终止，迫使Linux社区开发了Git。
设计目标：
- 速度：高效处理大规模项目。
- 简单：简化的设计和操作。
- 强力支持非线性开发：支持多个并行开发的分支。
- 完全分布式：每个开发者拥有完整的版本库，无需中央服务器。
- 高效管理大规模项目：适用于类似Linux内核的超大规模项目。

Git 的工作原理

仓库（Repository）：
- 存储项目的目录，包含所有文件的当前版本和历史版本，以及管理这些版本的元数据。
工作目录（Working Directory）：
- 当前检出的项目副本，开发者在这里进行开发和修改。
暂存区（Staging Area）：
- 临时区域，用于存放即将提交的修改。开发者需要先将修改添加到暂存区，然后才能提交到仓库。
提交（Commit）：
- 将暂存区的修改保存到仓库中，生成一个新的快照，每次提交都有一个唯一的SHA-1哈希值标识。
分支（Branch）：
- 项目的并行版本，允许开发者同时开发多个功能或修复。可以轻松创建和切换分支。
合并（Merge）：
- 将一个分支的修改合并到另一个分支中，常用于将功能分支合并到主分支。
推送（Push）和拉取（Pull）：
- 推送将本地提交的更改发送到远程仓库，拉取从远程仓库获取更新。

Git 的基本操作

# 初始化仓库
git init# 克隆仓库
git clone <repository-url># 创建新分支
git checkout -b <branch-name># 添加文件到暂存区
git add <file># 提交更改
git commit -m "Commit message"# 推送到远程仓库
git push origin <branch-name># 从远程仓库拉取更新
git pull origin <branch-name># 合并分支
git checkout <main-branch>
git merge <feature-branch># 查看历史记录
git log

Git 的使用场景

备份：定期推送代码到远程仓库以进行备份，防止数据丢失。
代码还原：通过查看历史记录和提交记录，恢复到之前的版本或撤销错误的提交。
协同开发：通过创建和合并分支，多个开发者可以同时开发不同的功能或修复错误。
追溯问题：使用git blame等命令查看每行代码的具体编写人和时间，方便问题追溯和代码审查。

通过以上特性和操作，Git提供了强大而灵活的版本控制功能，使得开发团队能够高效地协作和管理项目。

五、Git工作流程

在这里插入图片描述

Git 工作流程

Git 的工作流程包括从远程仓库获取代码、在本地进行修改和提交、更改同步到远程仓库等步骤。以下是详细的工作流程和对应的命令说明：

1. 克隆（clone）

从远程仓库克隆代码到本地仓库。这一步通常是开发者第一次获取项目代码时进行的操作。

git clone <repository-url>

2. 检出（checkout）

从本地仓库检出一个分支，然后在该分支上进行开发和修改。

# 检出现有分支
git checkout <branch-name># 创建并检出新分支
git checkout -b <new-branch-name>

3. 添加（add）

在提交更改之前，需要将修改的文件添加到暂存区。这一步允许你选择哪些修改会包含在下一次提交中。

# 添加单个文件
git add <file># 添加所有修改的文件
git add .

4. 提交（commit）

将暂存区的修改提交到本地仓库。这一步生成一个新的提交记录，包含了你的更改。

git commit -m "Commit message"

5. 抓取（fetch）

从远程仓库获取更新到本地仓库，但不进行合并操作。这通常用于检查远程仓库的状态而不影响当前工作。

git fetch

6. 拉取（pull）

从远程仓库拉取更新并自动合并到本地分支。这一步相当于git fetch加上git merge，通常用于同步远程仓库的最新更改。

git pull origin <branch-name>

7. 推送（push）

将本地仓库的更改推送到远程仓库，以便与团队成员共享代码。这一步需要有权限访问远程仓库。

git push origin <branch-name>

Git 工作流程示例

以下是一个典型的Git工作流程，结合上述命令进行解释：

克隆远程仓库：
```
git clone https://github.com/user/repository.git
```
开发者第一次获取项目代码。
创建新分支并检出：
```
git checkout -b feature-branch
```
创建并切换到一个新的功能分支，进行独立的开发。
在工作区进行修改：
编辑项目中的文件。
将修改添加到暂存区：
```
git add .
```
将所有修改的文件添加到暂存区。
提交修改到本地仓库：
```
git commit -m "Added new feature"
```
提交更改，生成新的提交记录。
同步远程仓库的更改（如果其他人可能已经提交了新代码）：
```
git pull origin main
```
拉取远程主分支的最新更改，并自动合并到当前分支。
解决合并冲突（如果有的话）：
手动解决代码冲突，然后继续提交。
```
git add <resolved-files>
git commit -m "Resolved merge conflicts"
```
将本地分支的更改推送到远程仓库：
```
git push origin feature-branch
```
将功能分支的更改推送到远程仓库。
发起合并请求（在托管服务平台如GitHub、GitLab上）：
在平台上创建一个Pull Request，将功能分支的更改合并到主分支。