目录
一、 版本控制基础
1.1 为什么需要版本控制？
在实际开发或日常办公中，我们经常会遇到为了防止文档丢失或更改失误，不断复制副本的情况。
- 痛点现状：产生大量类似“报告-v1”、“报告-最终版”、“报告-究极进化版”的文件。
- 核心问题：随着版本数量增多，用户很难记忆每个版本具体修改了哪些内容。项目代码由于逻辑复杂、文件众多，这一问题尤为突出。
1.2 什么是版本控制器？
版本控制器是一个可以记录工程每一次改动和版本迭代的管理系统。
- 主要功能：了解文件的历史发展过程，方便多人协同作业。通过回滚的方式获取往期版本的代码。
- Git 的地位：目前最主流的版本控制器。它不仅能管理源代码，还可以控制电脑上所有格式的文件（如 doc, excel, dwg 等）。
二、 Git 简史
Git 诞生于 2005 年，由 Linux 之父 Linus Torvalds 开发。
- 背景：早期 Linux 内核维护使用商业软件 BitKeeper，后因合作结束，Linus 基于 BitKeeper 的经验教训，在极短时间内（一周）开发出了 Git。
- 设计目标：
- 极快的运行速度。
- 简单的设计逻辑。
- 强力支持非线性开发模式（成千上万个并行开发分支）。
- 完全分布式架构。
- 具备高效管理超大规模项目（如 Linux 内核）的能力。
三、 Git 环境搭建与配置
3.1 命令行安装
在 Linux 环境下，可以使用包管理器快速安装：
# CentOS / Aliyun Linux
sudo yum install git
# Ubuntu / Debian
sudo apt install -y git
# 查看安装版本
git --version
3.2 首次使用配置
安装完成后，必须配置全球唯一的用户名和邮箱，用于标识提交者身份：
git config --global user.name "你的用户名"
git config --global user.email "你的邮箱"
3.3 在 GitHub 创建项目
3.3.1 账号准备与项目新建
在使用 GitHub 托管代码前，需先完成账号注册与邮箱校验。登录成功后，进入个人主页，点击左侧或右上方的 New repository 按钮开始新建项目。
3.3.2 项目参数配置
在新建页面中，你需要填写以下关键信息：
- Repository name：项目名称（不可与已有项目重复，系统会自动校验）。
- Public / Private：选择公开项目或私有项目。
- Initialize this repository：可勾选是否自动创建 README 说明文件。
确认无误后，点击底部的 Create repository 按钮。
3.3.3 获取项目链接并克隆到本地
项目创建完成后，在项目主页复制 HTTPS 或 SSH 链接。
随后，在本地创建一个存放代码的目录，使用 clone 命令将远程仓库下载到本地：
# [url] 即为你刚才复制的项目链接
git clone [url]
3.4 Git 身份标识配置与修正
3.4.1 配置全局身份信息（设置名片）
这是 Git 的基础配置。由于 Git 每次提交（commit ）都会记录操作者身份，若未手动设置，系统会根据主机名自动生成一个临时名称，这通常不符合规范。
# 设置你的用户名
git config --global user.name "Your Name"
# 设置你的联系邮箱
git config --global user.email [email protected]
注意：这里的邮箱建议与你的 GitHub/Gitee 账号邮箱保持一致，否则云端平台可能无法正确关联你的贡献记录（如无法显示绿色的 Contributions 提交矩阵）。
3.4.2 修正已有提交记录（亡羊补牢）
如果你在完成上述设置之前已经进行了代码提交，那么该记录中的作者信息可能是错误的。此时可以使用以下命令“重写历史”：
git commit --amend --reset-author
指令含义：
--amend：执行修补式提交，将当前的更改与上一次提交合并，并覆盖上一次的提交记录。--reset-author：强制将该提交的作者信息更新为你当前在git config中设置的新身份。
执行结果：操作成功后，你会看到类似 27 files changed... 的提示。这意味着之前的旧提交已被撤销，取而代之的是打上了正确身份标签的新提交。
四、 Git 核心原理与操作
4.1 核心区域概念
Git 的操作主要涉及三个区域：
- 当前工作区 (Working Directory)：你实际操作的文件目录。
- 暂存区 (Stage/Index)：位于
.git目录（真正意义上的本地仓库）下，用于临时存放修改，准备提交。 - Git 仓库 (Repository)：最终存储版本历史的地方。
4.2 Git 操作“三板斧”
这是最常用的开发工作流：
- 第一步：
git add
将工作区的修改提交到暂存区。 - 第二步：
git commit -m "日志信息"
将暂存区的内容正式提交到本地仓库，生成版本记录。 - 第三步：
git push
将本地仓库的版本同步到远端仓库（如 GitHub/Gitee）。
4.3 辅助指令
git status：查看当前工作区和暂存区的状态。git log：查看历史提交记录。.gitignore：在该文件中列出需要忽略的特定后缀文件，Git 将不再追踪这些文件的变化。
4.4 深入理解 Git 工作原理
4.4.1 .git 文件夹：真正的仓库
在你的项目根目录下，有一个隐藏的 .git 文件夹。它是 Git 的核心，也是你“真正的仓库”。
- 存储内容：该文件夹存放了所有的提交记录（commit history）和所有以前上传过的版本。
- 重要性：只要这个文件夹还在，你就可以随时回滚到任何一个历史状态。
4.4.2 Git 更新代码的本质
Git 更新仓库代码并非简单的“文件覆盖”或“整体拷贝”，而是一种基于增量和指令的管理方式：
- 操作记录而非文件堆叠：当你修改代码（例如删除了第 99 行代码）并再次
push时，Git 并不是把整个新文件传上去。 - 命令比对：Git 会通过比较得出你执行了“删除第 99 行代码”这一指令，并在远端仓库执行同样的删除操作。
- 版本恢复的逻辑：当你需要恢复到之前的版本时，Git 实际上是执行了一次“反向命令”（例如：把刚才删除的第 99 行代码再加回去），从而实现版本的精准回溯。
4.4.3 提交规则：只提交变化
- Git 在提交（commit）时，只会提交发生变化的部分。这种机制极大地节省了存储空间并提高了同步效率。
- 通过
.gitignore文件，可以排除掉不需要管理的文件（如编译生成的二进制文件或临时日志），确保仓库的纯净。
4.5 后缀信息过滤文件：.gitignore
在项目开发过程中，并不是所有的文件都需要被 Git 管理。例如：编译生成的二进制文件（.exe, .obj）、临时日志文件（.log）或者是存放私密信息的配置文件。为了保持仓库的纯净，我们需要使用 .gitignore。
4.5.1 什么是 .gitignore？
.gitignore 是一个存放在项目根目录下的普通文本文件。它的作用是告诉 Git：哪些文件或目录应该被忽略，不需要加入到版本控制中。
4.5.2 核心过滤逻辑
- 按后缀过滤：你可以指定特定后缀的文件不被提交。
- 例如，在
.gitignore中写入*.exe，那么所有的可执行文件在执行git status时都会被自动忽略。
- 例如，在
- 按目录过滤：可以忽略整个文件夹（如存放依赖的
node_modules/或编译目录bin/）。 - 排除例外：使用
!符号可以指定某些文件即使匹配了忽略规则也要保留。
4.5.3 为什么要过滤？
- 节省空间：不上传没意义的中间编译产物（如 C++ 编译生成的巨大
.o文件）。 - 保护隐私：防止包含数据库密码或 API Key 的配置文件被推送到公开的远端仓库。
- 减少冲突：避免频繁变动的本地临时文件导致不必要的合并冲突。
4.5.4 逻辑全图示
结合我们之前的“三板斧”流程，.gitignore 就像是一个“安检口”，在 git add 之前就过滤掉了不需要的杂质：
注意：
.gitignore只能忽略那些**从未被追踪（Untracked）**的文件。如果一个文件已经加入了版本库，你需要先用git rm --cached将其移出追踪范围，忽略规则才会生效。
五、 远程仓库与协同开发
二、 分布式与去中心化布局
2.1 核心差异：Git vs SVN
与传统的集中式版本控制系统（如 SVN）不同，Git 采用的是去中心化的分布式架构。
- SVN（集中式）：必须依赖一个中央服务器（SVN Server）。开发者之间无法直接通信，如果服务器宕机，整个版本历史将面临风险，且断网时无法提交代码。
- Git（分布式）：每个人的电脑都是一个完整的版本库。这意味着你本地拥有项目的所有历史记录，安全性极高，即使在没有网络的环境下也能正常进行本地提交（commit）。
2.2 去中心化布局的两种形式
A. 多个对等仓库（P2P 互联）
这是最纯粹的去中心化形式，节点之间完全对等。
- 逻辑：任意两个节点之间可以直接进行
push（推送）或pull（拉取）。 - 特点：无需中心服务器，形成多对多互联的拓扑结构，灵活性极高。
B. 互联网协作（基于 GitHub/代码托管平台）
这是目前主流的开发模式，结合了分布式与协作的便利性。
- 逻辑：所有节点通过一个公共平台（如 GitHub、Gitee）进行中转同步。
- 特点：
- 中转同步：虽然节点间不直接通信，但每个节点仍持有完整副本。
- 跨地域协作：非常适合远程办公或开源项目，通过平台实现间接的全球协同。
总结：两种形式本质上都是去中心化的。区别在于同步方式：形式 A 是节点间直接互联，形式 B 是通过云端平台实现间接互联。
5.2 冲突处理
当多个开发者修改了同一个文件并尝试推送到远端时，可能会发生 Rejected（冲突）。
- 原因：远端仓库的代码比本地更新。
- 解决：提醒本地用户先执行
git pull同步远端代码，手动解决冲突后再重新提交。
Git冲突。实际上是为了保护前面修改这个仓库的人的修改不被后一个人的修改所覆盖 “嘿，有人在你之前动过这块地盘了，请你确认一下，别把人家的成果给弄丢了。”
5.3 协作开发框架实战
在实际的项目开发中，Git 不仅仅是个人备份工具，更是团队协作的桥梁。通过 GitHub（或公司内部代码托管平台），团队可以实现高效的并行开发。
5.3.1 多人协同推送（Push ）模型
如图所示，不同角色的开发人员在本地仓库完成工作后，通过 push 操作将代码汇总到云端：
- 开发人员 A：负责新功能 feature-a 的开发。
- 开发人员 B：负责新功能 feature-b 的开发。
- 开发人员 C：负责修复紧急 Bug（fix-bug）。
每个人的本地修改互不干扰，通过 git commit 记录本地版本，最后统一同步到 GitHub 的共享远程仓库中。
5.3.2 典型分支管理逻辑
GitHub 远程仓库通常采用分支（Branch）策略来保证代码质量和发布的稳定性：
1.main (主分支)：
- 定位：存放最稳定、可发布的代码版本。
- 原则：一般不允许开发者直接在 main 分支上修改代码，只有经过测试的代码才能合并进来。
2.develop (开发分支)：
- 定位：团队日常开发汇总的分支。
- 操作：新功能的开发分支（feature branches）通常是从 develop 分支创建出来的，并在完成后合并回 develop。
3.feature/ (功能分支)*：
- 定位：为了完成某个特定功能（如 feature-a）而从 develop 拉出来的临时分支。
- 意义：保证了不同功能之间的开发完全隔离，不会因为 A 的代码写了一半导致整个项目无法运行。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2501_93641778/article/details/167126053
