版本控制

版本控制（Version Control）是一种记录文件或一组文件随时间变化的方式，以便将来能够检索特定版本的方法。在软件开发中，版本控制是至关重要的，因为它允许开发团队有效地跟踪和管理源代码的更改，协作工作，以及管理不同版本的软件。

基本概念

仓库（Repository）：存储所有数据的地方，通常位于服务器上。
提交（Commit）：对文件进行更改并保存到仓库的操作。每次提交都会创建一个新的版本，并包含更改的描述。
版本（Version）：文件或项目历史的特定实例。每个版本都有一个唯一的标识符，通常是提交时生成的哈希值。
分支（Branch）：从主开发线上分离出来的一个独立线路，允许在不影响主代码库的情况下进行实验性的更改。
合并（Merge）：将一个分支的更改集成到另一个分支的过程。
冲突（Conflict）：当两个分支对同一个文件的同一部分进行了不同的更改时，合并这些分支可能会遇到冲突。
标签（Tag）：用于标记特定提交（通常是发布版本）的里程碑。

实现系统类型

本地版本控制系统：最早的版本控制系统是本地的，它们在单个机器上跟踪文件的更改。这种系统的缺点是不支持多人协作。
集中式版本控制系统：这类系统有一个中央服务器，所有开发者的更改都提交到这个服务器上。这种系统的优点是支持协作，但缺点是中央服务器可能成为单点故障。
分布式版本控制系统：在分布式版本控制系统中，每个开发者的机器上都有一个完整的代码库，包括所有历史记录。这意味着开发者可以在离线状态下工作，并且即使中央服务器出现问题，也不会丢失数据。

集中式版本控制系统

集中式版本控制系统（Centralized Version Control System，简称 CVCS）是一种版本控制模式，其中有一个中央服务器存储所有文件的版本历史，而开发者通过客户端连接到这台服务器来工作。在集中式系统中，所有版本信息、变更历史和元数据都保存在中央服务器上，开发者通常只能看到他们自己的工作副本和中央服务器的状态。

关键特点

单一真相来源：中央服务器是所有数据唯一的真实来源，所有开发者的提交和变更都直接与这个中央仓库交互。
网络依赖：因为所有操作都需要与中央服务器通信，所以开发者在没有网络连接的情况下无法提交变更或查看历史记录。
性能瓶颈：由于所有操作都通过中央服务器进行，当项目规模扩大或开发者数量增多时，服务器可能会成为性能瓶颈。
单点故障：如果中央服务器出现故障，所有开发者都将无法进行提交或更新操作，直到服务器恢复正常。

常见的集中式版本控制系统

CVS (Concurrent Versions System)：是最早的集中式版本控制系统之一，但因其设计上的局限性和缺陷，现在已很少使用。
Subversion (SVN)：是CVS的后继者，它解决了CVS的一些问题，并提供了更友好的使用界面和更好的性能。Subversion至今仍然在一些项目中使用，尤其是在一些传统企业和项目中。
Perforce (P4)：是一种高性能的版本控制系统，特别适用于大型项目和大型团队。它提供了精细的权限控制和文件存储机制。

分布式版本控制系统

分布式版本控制系统（Distributed Version Control System，简称 DVCS）是一种版本控制模式，其中每个开发者的工作副本都是一个完整的版本库，包含所有的历史记录和版本信息。这意味着开发者可以在本地执行提交、分支、合并等操作，而不需要与中央服务器进行交互。分布式系统的设计允许开发者在不联网的情况下进行大部分工作，只有在与其他开发者共享变更时才需要联网。

关键特点

本地完整副本：每个开发者的机器上都有一个完整的版本库，包括所有历史记录和元数据。
离线工作：开发者可以在没有网络连接的情况下进行提交、创建分支、查看历史记录等操作。
性能优势：由于大多数操作都是在本地执行，分布式版本控制系统通常比集中式系统更快。
数据安全性：每个开发者都有完整的历史记录，这意味着即使中央服务器发生故障，数据也不会丢失。
自定义工作流：分布式系统的灵活性允许团队根据项目需求自定义开发流程。

常见的分布式版本控制系统

Git：是目前最流行的分布式版本控制系统，由Linus Torvalds为Linux内核开发而创建。Git强调速度、数据完整性以及对分布式非线性工作流的强大支持。
Mercurial (Hg)：是一个简单易用且功能强大的分布式版本控制系统，特别注重于用户体验和操作简便性。
Bazaar (Bzr)：是另一个分布式版本控制系统，它试图提供简单性和灵活性，但在功能和性能上不如Git和Mercurial流行。
Darcs：是一个基于 patches 的分布式版本控制系统，它采用了一种不同的方式来处理变更的传播和合并。

Git

Git的历史始于2005年，当时Linux内核的开发者社区正在使用一个名为BitKeeper的分布式版本控制系统。BitKeeper的作者允许可免费使用这个工具，但后来由于一些争议，BitKeeper的作者收回了免费使用的权限。这促使Linux内核的创始人Linus Torvalds决定开发一个属于自己的版本控制系统，这个系统就是Git。

Linus Torvalds在开发Git时，借鉴了BitKeeper的一些优秀特性，同时加入了自己对版本控制系统的理解和需求。Git的第一个版本在2005年4月被开发出来，并在短时间内迅速成熟。Linus Torvalds在设计Git时，特别注重性能、安全性、灵活性和可靠性。

Git的快速发展得益于开源社区的贡献。许多开发者开始使用Git，并为它贡献代码和改进。Git很快成为最流行的版本控制系统之一，特别是在开源项目中。

2008年，GitHub的成立进一步推动了Git的普及。GitHub提供了一个基于Web的Git仓库托管服务，让开发者可以更容易地共享和协作代码。GitHub的社交编码特性，如关注其他用户、对代码进行评论和点赞，使得Git不仅仅是一个版本控制系统，还成为了一个开发者社区和协作平台。

随着时间的推移，Git逐渐成为事实上的版本控制标准，不仅在开源项目中使用，也被许多企业和商业项目采用。Git的各种客户端和集成开发环境（IDE）的支持也不断完善，使得Git的使用更加便捷。

Git的成功也催生了其他基于Git的托管服务，如GitLab和Bitbucket，它们提供了与GitHub类似的功能，但可能有不同的定价模型、私有仓库支持和额外的协作特性。

Git的历史是一个开源社区合作和创新的故事，它从一个紧急需求出发，迅速发展成为一个全球范围内被广泛采用的工具，极大地影响了软件开发的方式。

配置Git

Git 的配置分为几个层次，包括系统级别、用户级别和仓库级别。每个级别的配置可能会覆盖上一级别的配置。下面是详细的配置说明：

系统级别配置
系统级别的配置会影响整个系统上的所有用户和仓库。这些配置通常存储在 Git 安装目录下的 /etc/gitconfig 文件中。可以使用 git config --system 命令来设置系统级别的配置。
例如，如果想设置一个默认的编辑器，可以使用以下命令：

bash

git config --system core.editor vim

用户级别配置
用户级别的配置会影响当前用户的所有仓库。这些配置通常存储在用户主目录下的 ~/.gitconfig 文件中。可以使用 git config --global 命令来设置用户级别的配置。
例如，设置用户信息和默认的文本编辑器：

bash

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
git config --global core.editor vim

仓库级别配置
仓库级别的配置只会影响特定的仓库。这些配置存储在仓库目录下的 .git/config 文件中。可以使用 git config 命令（不加任何选项）来设置仓库级别的配置。
例如，如果只想在某个特定仓库中使用不同的文本编辑器，可以进入该仓库的目录并执行：

bash

git config core.editor emacs

配置文件格式
Git 配置文件使用简单的 INI 格式，由多个部分组成，每个部分包含一组键值对。例如：

ini

[user]
    name = Your Name
    email = your.email@example.com
[core]
    editor = vim

查看配置
要查看当前的 Git 配置，可以使用 git config --list 命令。如果想查看特定键的配置，可以使用 git config <key> 命令。
例如，查看所有配置：

bash

git config --list

查看用户级别的编辑器配置：

bash

git config --global core.editor

配置命令别名
Git 允许为常用的命令创建别名，以简化命令的输入。这可以通过在用户或系统级别的配置文件中添加 [alias] 部分来实现。
例如，在 ~/.gitconfig 文件中添加：

ini

[alias]
    co = checkout
    ci = commit
    st = status

这样，就可以使用 git co 代替 git checkout，git ci 代替 git commit，以及 git st 代替 git status。

高级配置
Git 还支持更多高级配置选项，如颜色设置、差异工具、合并工具等。这些配置通常用于自定义 Git 的行为以适应个人的工作习惯。
例如，设置 Git 命令输出的颜色：

bash

git config --global color.ui true

配置 Git 使用特定的合并工具：

bash

git config --global merge.tool vimdiff

Git 基本概念

工作区、暂存区和仓库
- 工作区（Working Directory）：这是直接操作文件的地方，即电脑上的文件目录。可以在工作区中编辑文件、添加新文件或删除文件。
- 暂存区（Staging Area）：暂存区是一个中间区域，用于暂存即将进行提交的更改。可以使用 git add 命令将工作区的更改添加到暂存区。暂存区有时也被称为索引（Index）。
- 仓库（Repository）：仓库是 Git 存储所有历史提交记录的地方。每个仓库都有一个 .git 目录，其中包含了所有的提交历史、分支、标签等信息。仓库可以是本地的，也可以是远程的。
分支和标签
- 分支（Branch）：分支是 Git 中的一个轻量级概念，它允许在仓库中创建一个独立的开发线。默认情况下，Git 会为创建一个名为 master 或 main 的主分支。可以根据需要创建、切换和删除分支。分支通常用于开发新功能、修复 bug 或尝试实验性的更改，而不会影响主分支。
- 标签（Tag）：标签是用于标记特定提交的引用。通常用于标记发布版本或其他重要的里程碑。标签可以是轻量级的，也可以是附注的。轻量级标签仅指向一个特定的提交，而附注标签则包含了额外的元数据，如标签创建者的信息、日期和标签消息。
提交和版本号
- 提交（Commit）：提交是 Git 中的核心概念，它代表了一次对仓库的更改。每次提交都会生成一个唯一的版本号（SHA-1 校验和），并记录下提交者的信息、提交日期和提交消息。提交是不可变的，一旦创建就无法更改。
- 版本号（SHA-1）：每次提交都会生成一个版本号，这是一个由 SHA-1 校验和算法生成的唯一字符串。这个版本号可以用来引用特定的提交，确保数据的一致性和完整性。

Git 基本操作

创建仓库（Repository） 创建一个新的Git仓库，我们可以通过Git命令行在本地创建一个空仓库，或者在远程服务器如GitHub、GitLab上创建一个新的仓库。
- 本地创建仓库:
  bash
```
git init [仓库目录名称]
```
  这将在当前目录或指定目录下创建一个新的Git仓库。
- 远程创建仓库:
  在GitHub或GitLab等平台上操作，通常需要登录并按照网站指示创建新的仓库。
克隆仓库（Clone） 克隆一个远程仓库到本地，这样就可以在本地进行修改和提交。
bash
```
git clone [仓库URL]
```
这会将远程仓库克隆到当前目录下。
提交更改
- 添加文件到暂存区（Stage）:
  bash
```
git add [文件名或路径]
```
  这会将更改添加到暂存区，为提交做准备。
- 提交文件到仓库（Commit）:
  bash
```
git commit -m "提交信息"
```
  这会提交暂存区的更改到仓库，并附上提交信息。
推送和拉取
- 推送到远程仓库（Push）:
  bash
```
git push [远程仓库名称] [分支名称]
```
  这会将本地的提交推送到远程仓库。
- 从远程仓库拉取（Pull）:
  bash
```
git pull [远程仓库名称] [分支名称]
```
  这会从远程仓库拉取最新的提交到本地仓库。
分支管理
- 创建分支（Branch）:
  bash
```
git branch [分支名称]
```
  这会在本地创建一个新的分支。
- 切换分支（Checkout）:
  bash
```
git checkout [分支名称]
```
  这会切换到指定的分支。
- 合并分支（Merge）:
  bash
```
git merge [要合并的分支名称]
```
  这会将指定分支的更改合并到当前分支。
- 删除分支（Delete）:
  bash
```
git branch -d [分支名称]
```
  这会删除指定的分支。
标签管理（Tags） 标签通常用于标记发布版本或其他重要的提交。
- 创建标签:
  bash
```
git tag [标签名]
```
  或者，如果我们想要为特定的提交创建标签：
  bash
```
git tag [标签名] [提交的哈希值]
```
  我们也可以添加附注信息：
  bash
```
git tag -a [标签名] -m "标签信息"
```
- 删除标签:
  bash
```
git tag -d [标签名]
```
  如果要删除远程的标签，需要先删除本地的标签，然后推送删除操作到远程：
  bash
```
git push --delete origin [标签名]
```
查看历史记录
- 查看提交历史:
  bash
```
git log
```
  我们可以使用各种参数来格式化和过滤输出，例如：
  bash
```
git log --oneline --graph --decorate
```
- 查看分支历史:
  bash
```
git log --oneline [分支名称]
```
  git log 日志导出以及参数配置，及乱码解决
  bash
```
git log --encoding="GBK" > D:\commit-log.txt
```
- 查看引用日志：
  sh
```
git reflog
```
  输出格式：
  git reflog 的输出通常具有以下格式：
```
<refname>@{<n>}: <commit-hash> <commit-message>
```
  - <refname> 是引用的名称，通常是 HEAD 或者分支名。
  - <n> 是一个可选的数字，表示这是引用的第几次变化，从当前状态回溯到过去。
  - <commit-hash> 是提交的哈希值。
  - <commit-message> 是提交时提供的简短描述。
  常见用途：
  1. 恢复丢失的提交：如果我们执行了 git reset --hard 或 git branch -D 等操作，导致一些提交丢失，git reflog 可以帮助我们找到这些提交的哈希值，然后我们可以通过 git checkout 或 git reset 来恢复它们。
  2. 查看历史操作： git reflog 可以显示所有分支切换、提交、重置等操作的历史。
  选项：
  git reflog 接受一些选项来过滤或修改输出：
  - --all：显示所有引用的日志，而不仅仅是 HEAD。
  - --expire=<time>：设置日志记录的过期时间。
  - --expire-unreachable=<time>：设置不可达提交的过期时间。
  - --max-age=<time>：只显示在指定时间内修改的引用。
  - --grep=<pattern>：只显示提交消息中包含指定模式的记录。
  - --inverse-grep=<pattern>：只显示提交消息中不包含指定模式的记录。
撤销更改
- 撤销暂存区文件:
  bash
```
git reset HEAD [文件名或路径]
```
  这会将文件从暂存区撤回到工作目录。
- 撤销提交:
  bash
```
git commit --amend
```
  这会编辑最近的提交，允许我们更改提交信息或添加更多的更改。
在Git版本控制中，合并Commit是一个常见的操作。合并Commit可以帮助我们整理混乱的提交历史，使之更加清晰易懂。本文将介绍一种合并Commit的方法：使用 git reset --soft 回退版本库和暂存区的版本，同时保留工作区的变动，然后重新提交工作区的内容。一、查看提交历史首先，我们可以查看前10个Commit，以便确定要合并的Commit范围。
bash
```
git log -10
```
二、回退版本库和暂存区使用 git reset --soft 命令回退版本库和暂存区的版本，同时保留工作区的变动。以下命令中的 295ac3b842b4ecb6eff1c9954a281a4606a8bc84 是要回退到的CommitID。
bash
```
git reset --soft 295ac3b842b4ecb6eff1c9954a281a4606a8bc84
```
三、添加已跟踪的文件执行以下命令，将工作区的变动添加到暂存区。
bash
```
git add -u
```
四、重新提交接下来，我们需要重新提交工作区的内容，并填写新的提交信息。
bash
```
git commit -m "修改信息"
```
子模块（Submodules） 子模块允许我们将一个Git仓库作为另一个Git仓库的子目录。

添加子模块:

bash

git submodule add [子模块仓库URL] [子模块路径]

更新子模块:
bash
```
git submodule update --init --recursive
```
删除子模块: 删除子模块涉及多个步骤，包括从.gitmodules文件中移除条目、从.git/config中移除条目、从文件系统中移除子模块目录，以及提交这些更改。

Git Hooks Git Hooks是特定事件触发的脚本，可以在Git仓库的.git/hooks目录中找到。

使用Git Hooks: 我们可以编写脚本来响应Git事件，例如提交前（pre-commit）、提交后（post-commit）等。
常用的Git Hooks:
- pre-commit: 在提交之前运行，可以用来检查提交的信息或代码质量。
- post-commit: 在提交之后运行，通常用于通知或日志记录。
- pre-push: 在推送到远程仓库之前运行，可以用来防止错误的推送。
- pre-receive 和 post-receive: 在服务器端接收推送时运行，可以用来进行额外的检查或触发构建等操作。

打包 Git 提供了两种主要的打包方法：git archive和git bundle。这两种方法适用于不同的场景，可以根据需要选择合适的方式。
- git archive: git archive命令用于创建一个仓库的快照，通常用于发布或分发代码。它不会包含Git的历史记录，只打包当前的文件状态，没有.git文件。
  bash
```
git archive --format=zip --output=/path/to/zipfile.zip master
```
  这会创建一个ZIP格式的文件，包含了master分支的最新文件状态。可以使用--format参数指定打包格式，如zip、tar或tar.gz等。
- git bundle: git bundle命令用于创建一个包含Git历史记录的打包文件，这个文件可以在没有网络连接的情况下传输到其他地方，然后在那里解包和使用。
  bash
```
git bundle create /path/to/bundle.bundle master
```
  这会创建一个包含master分支历史的打包文件。可以使用git bundle verify来验证打包文件的完整性，使用git bundle list-heads来查看打包文件中的分支，使用git bundle unbundle来解包。
- 使用git bundle克隆仓库: 如果有一个git bundle文件，可以使用以下命令来克隆它：
  bash
```
git clone bundle.bundle ./cloned_repo -b master
```
  这会将bundle.bundle文件中的master分支克隆到cloned_repo目录中。

Git 基本使用流程

1. 初始化仓库

创建新的仓库：
- 如果是从零开始创建一个新的项目，可以先在本地创建一个新的目录，然后使用 git init 命令初始化一个新的 Git 仓库。
  bash
```
mkdir my_project
cd my_project
git init
```
  关联本地与远程仓库：使用git remote add origin <远程仓库地址>命令将本地仓库与远程仓库关联起来。这样，Git就知道从哪个远程仓库拉取数据。
克隆现有仓库：
- 如果要从现有的远程仓库克隆一个项目，可以使用 git clone 命令。
  bash
```
git clone https://github.com/username/my_project.git
cd my_project
```

2. 配置用户信息

在开始工作前，需要配置我们的用户名和电子邮件地址，以便 Git 可以记录我们的贡献。
bash
```
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
```

3. 添加文件

将新文件添加到仓库中，或者将已修改的文件添加到下次提交中。
bash
```
git add <file>
# 或者将所有修改过的文件添加到暂存区
git add .
```

4. 提交更改

提交暂存区的更改到仓库中，并附上描述性的提交消息。
bash
```
git commit -m "Add initial project structure"
```

5. 拉取远程仓库的更新

从远程仓库获取最新的更改，并将其合并到当前分支。
bash
```
git pull origin main
```

6. 推送更改到远程仓库

将本地的更改推送到远程仓库。
bash
```
git push origin main
```

7. 解决冲突

如果在拉取或合并过程中遇到冲突，需要手动解决这些冲突。
- 打开冲突文件，解决冲突后，使用 git add 添加解决冲突后的文件。
- 再次使用 git commit 创建一个新的提交。

版本控制 ​

基本概念 ​

实现系统类型 ​

集中式版本控制系统 ​

关键特点 ​

常见的集中式版本控制系统 ​

分布式版本控制系统 ​

关键特点 ​

常见的分布式版本控制系统 ​

Git ​

配置Git ​

Git 基本概念 ​

Git 基本操作 ​

Git 基本使用流程 ​

1. 初始化仓库 ​

2. 配置用户信息 ​

3. 添加文件 ​

4. 提交更改 ​

5. 拉取远程仓库的更新 ​

6. 推送更改到远程仓库 ​

7. 解决冲突 ​

版本控制

基本概念

实现系统类型

集中式版本控制系统

关键特点

常见的集中式版本控制系统

分布式版本控制系统

关键特点

常见的分布式版本控制系统

Git

配置Git

Git 基本概念

Git 基本操作

Git 基本使用流程

1. 初始化仓库

2. 配置用户信息

3. 添加文件

4. 提交更改

5. 拉取远程仓库的更新

6. 推送更改到远程仓库

7. 解决冲突