能从冰封的土地里
培育出十万朵怒放的蔷薇
Linux 系统篇(十一) —— 版本控制器 Git
文章目录
一、版本控制器是什么
版本控制器，就是一个能让你了解一个文件完整历史和发展过程的系统。通俗地说，它是一个能够记录工程的每一次改动和版本迭代的管理系统，同时还能方便多人协同工作，而不是互相覆盖代码。
目前市面上最主流、最强大的版本控制器就是 Git。Git 可以控制电脑上几乎所有格式的文件，比如 .doc、.excel、.dwg 等。
二、Git 的诞生
和生活中许多伟大的事物一样，Git 诞生于一个极富纷争和大胆创新的年代。
Linux 内核开源项目有着数量庞大的参与者。在 1991 年到 2002 年间，绝大多数的 Linux 内核维护工作都耗费在手动提交补丁和保存归档的繁琐事务上。到了 2002 年，整个项目组开始使用一个叫做 BitKeeper 的专有分布式版本控制系统来管理和维护代码。
然而到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系破裂，他们收回了 Linux 内核社区免费使用 BitKeeper 的权利。这就迫使 Linux 开源社区（特别是 Linux 的缔造者Linus Torvalds）基于使用 BitKeeper 时的经验和教训，自己动手开发一个新的版本系统。
Linus 对这个新系统制定了几条很明确的目标：
- 速度要快
- 设计要简单
- 要能强力支持非线性开发模式（也就是允许成百上千个并行开发的分支）
- 完全分布式
- 有能力高效管理像 Linux 内核那样的超大规模项目（不管是速度还是数据量）
2005 年，Git 就这样诞生了。此后它日益成熟完善，在保持简单易用的同时，依然坚守着当初设定的目标。
三、Git 的本质与核心价值
我们通过 Git 究竟解决什么问题？核心目的就两个：
- 数据安全：防止代码丢失、误改造成不可逆的损失。每一次提交都会形成一个快照，你可以随时回到过去的任何版本。
- 协同开发：支持多人共同维护和开发一套代码，且每个人都能独立工作，不会互相干扰。
Git 是一个底层的版本控制软件，它很特别的一点是，同时兼具客户端和服务端的特征。这使得 Git 的架构与老式的集中式版本控制完全不同——它是分布式去中心化的。
在集中式版本控制系统里，所有代码历史都只存放在一台中心服务器上，开发者本地只保留某一个版本的文件，一旦中心服务器宕机或损坏，整个历史可能都会丢失。而 Git 是分布式的，每一个开发者的电脑上，都有一个完整的本地仓库，里面包含了项目的全部历史记录。
在一个实际的项目架构中，通常会包含下面几个部分：
- 本地仓库：你电脑硬盘上的某个目录（比如 D 盘里的 project 文件夹），里面有个隐藏的
.git文件夹，它保存着所有版本信息。- 远程仓库：部署在云端服务器上的中央存储库，用于汇总大家的代码，也叫远端仓库。
- 云端托管平台：比如 GitHub、Gitee（码云） 等，它们基于 Git 协议，提供了可视化的网页操作界面以及权限管理等附加功能。
在一个公司或团队项目中，一般会建立一个“项目组织”，团队成员各自在自己的电脑上拥有本地仓库，通过推送（push）、拉取（pull）、合并（merge）等操作，与远程仓库进行同步，从而实现代码的集中管理。
四、安装 Git
在 Linux 下安装 Git 非常简单，以 CentOS 为例：
sudo yum install git
如果是 Ubuntu 系统：
sudo apt install git
安装完成后，可以查看版本验证一下：
git --version
五、Git 的三个核心区域：工作区、暂存区、本地仓库
要想彻底理解 Git 的操作逻辑，一定要先弄懂三个区域的概念。
- 工作区（Working Directory）：就是你在电脑上能直接看到的项目目录，里面是实实在在的文件。
- 暂存区（Stage / Index）：一个虚拟的、临时存放改动的地方。
- 本地仓库（Local Repository）：真正存放版本历史的地方。当你把暂存区的修改提交以后，就会形成一个永久的历史版本，保存在
.git目录中。
下面这张流程图展示了三个区域之间的基本关系：
工作区 —— git add ——> 暂存区 —— git commit ——> 本地仓库
对应最基本的三个命令：
git add <文件名>：将工作区的文件添加到暂存区，告诉 Git “这些文件我要纳入版本管理” 或者 “这一次的修改我准备提交了”。git commit -m "提交说明"：将暂存区的所有内容提交到本地仓库，并附上一段说明文字，形成一个永久的版本记录。git push：将本地仓库的最新提交推送到远程仓库，与团队共享。
另外还有一个重要原则：Git 每次提交只会保存发生变化的那部分内容，不会把整个文件再存一份！
六、首次使用必须配置的身份信息
在正式使用 Git 之前，我们还需要先配置一下自己的身份信息，因为每当你提交代码时，Git 都会记录是谁提交的。
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
这里的 --global 表示这个配置对当前系统用户下的所有 Git 仓库都生效。
七、在 GitHub 上创建远程仓库
GitHub 是目前全球最流行的代码托管平台。下面我们一步步来看看如何创建一个远程仓库，并将代码推送上去。
7.1 注册账号
在 GitHub 官网注册一个账号，过程比较简单，根据提示操作即可。需要注意的是，注册完通常需要进行邮箱验证。
7.2 创建一个新项目仓库
登录成功后，进入你的个人主页，点击左下角绿色的 “New repository” 按钮。页面会跳转到一个新建项目的表单：
- Repository name：项目名称。不能与你已有的仓库重名，系统会自动校验。
- 可以填写一段描述，并选择公开（Public）还是私有（Private）。
- 其它选项可以先不管，直接点击下方的 “Create repository” 按钮确认创建。
- Repository name：项目名称。不能与你已有的仓库重名，系统会自动校验。
- 可以填写一段描述，并选择公开（Public）还是私有（Private）。
- 其它选项可以先不管，直接点击下方的 “Create repository” 按钮确认创建。
创建成功后，你会进入该仓库的页面，上面会显示仓库的地址：
复制这个地址，我们后面会用到。
7.3 把远程仓库下载到本地
在你的电脑上找一个合适的地方，打开终端，执行(链接是刚才复制的链接)：
git clone https://github.com/你的用户名/仓库名.git
执行完毕后，当前目录下会多出一个与仓库同名的文件夹，这个文件夹就是一个完整的本地仓库，里面除了你远程仓库中的文件，还会包含一个 .git 隐藏目录，它就是本地仓库的“数据库”。
八、Git 基本操作三板斧：add、commit、push
现在我们已经有了一个本地仓库，接下来看看日常开发中最常用的三个步骤，俗称“三板斧”。
8.1 git add：将修改加入暂存区
假设我们在项目里新建了一个文件 test.c 并写了一些代码，或者修改了一个已有文件，接下来就要告诉 Git：“请追踪这个文件的变化”。
git add test.c
如果想一次性添加当前目录下的所有变化，可以使用：
git add .
注意，后面的 . 就代表当前目录。
此时文件就被放入了暂存区。可以用 git status 查看状态，你会看到 test.c 在 “Changes to be committed” 下面，表示它正等待被提交。
8.2 git commit：将暂存区内容提交到本地仓库
暂存区里的修改还只是“临时放置”，我们需要执行提交，将它们永久记录到仓库的历史中。
git commit -m "添加test.c文件，实现基本功能"
-m 后面跟的就是本次提交的说明信息。写提交信息是一个很重要的习惯，它应该简明扼要地描述这次提交到底做了什么，方便以后回顾。
提交成功后，本次修改就在本地仓库里有了一个唯一的版本号，以后可以随时回溯到这个版本。
8.3 git push：将本地仓库推送到远程仓库
现在修改还只存在于你的本地电脑上，为了让团队其他人也能看到你的最新代码，需要推送到远程仓库：
git push
执行后会提示你输入 GitHub 的用户名和密码。推送成功后，刷新 GitHub 页面，就能看到最新提交的代码了。
九、查看状态和历史：git status 与 git log
9.1 git status
任何时候在项目目录下执行 git status，Git 都会告诉你：
- 当前在哪个分支上。
- 工作区有哪些文件被修改了但还没放入暂存区。
- 暂存区有哪些文件正等待提交。
- 有没有未跟踪的新文件。
9.2 git log
git log 用来查看提交历史，它会按时间倒序列出每一次提交的版本号、作者、日期和提交说明。
$ git log
commit a1b2c3d4e5... (HEAD -> master)
Author: 张三 <[email protected]>
Date: Mon Jul 30 10:00:00 2026 +0800
添加test.c文件，实现基本功能
十、.gitignore：忽略不该提交的文件
在一个真实项目中，我们并不希望把所有文件都交给 Git 管理。比如编译产生的 .o、.exe 文件，本地编辑器生成的临时文件，包含密码的配置文件等等，它们要么没有版本价值，要么会泄露敏感信息。这时候就要靠 .gitignore 文件了。
做法是在项目根目录下创建一个名为 .gitignore 的文件，在里面写上需要忽略的规则，每一行一个。
一旦这些规则被写进 .gitignore 并且该文件也被提交到仓库后，Git 就会自动忽略匹配的文件，不再提示它们未被跟踪，也不会将它们添加到版本管理中。常见语言的官方 .gitignore 模板可以在 GitHub 上找到。
十一、推送时遇到冲突怎么办？
当你高高兴兴写完代码，执行 git push 准备下班时，终端突然甩过来一段报错：
Updates were rejected because the remote contains work that you do not have locally.
这段话直译过来就是：“推送被拒绝，因为远程仓库包含你没有的最新工作成果。” 核心原因很简单：远程仓库的代码比你的本地仓库更新。这说明，在你上一次拉取代码之后，有其他同事已经向远程仓库推送了新代码。你的本地仓库落后了，如果直接覆盖推送，别人的修改就会丢失，所以 Git 拒绝了你的操作。
这时候千万不要慌张，更不要使用 git push -f（强制推送），因为那会直接抹掉远程仓库中别人的新提交，造成严重事故。正确的做法是遵循以下流程：
第一步：拉取远程最新代码，同步本地仓库
先把远程仓库的最新代码同步到本地，让本地代码和远程代码版本对齐，为后续合并自己的修改做铺垫：
git pull
如果想要更干净的提交记录，推荐使用变基拉取（企业开发常用）：
git pull --rebase
第二步：手动处理代码冲突
如果仅新增/修改不同文件，git pull 会自动合并代码，不会产生冲突。
如果你和同事修改了同一个文件的同一行/同一区域，Git 无法自动判断保留哪部分代码，就会触发 CONFLICT（代码冲突）。
此时打开冲突文件，会看到 Git 自动生成的冲突标记，格式如下：
<<<<<< HEAD
远程仓库（同事）的最新代码
=======
你本地修改的代码
>>>>>>> 你的提交备注
冲突解决规范：
- 优先和对应同事沟通，确认业务代码需求；
- 按需保留代码：可以只保留远程代码、只保留自己的代码，或整合双方代码；
- 必须删除所有冲突标记（
<<<、=====、>>>），保证代码语法无误；- 保存文件，完成冲突修复。
第三步：提交合并代码，完成推送
所有冲突文件修改完毕后，执行以下命令完成合并、提交和推送（修正原指令错误）：
# 1. 暂存所有修复后的文件
git add .
# 2. 完成变基合并（对应 git pull --rebase 场景）
git rebase --continue
# 3. 正常推送到远程仓库
git push
如果是普通 pull 合并场景，直接提交即可：
git add .
git commit -m "合并远程代码，解决版本冲突"
git push
结语：
今天的内容到这里就结束了，希望你能有所收获~
干货整理到手抖，觉得有用的话，赏个三连回回血？__(:ᗤ」ㄥ)_ _
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/Huang_jin007/article/details/163341078
