Linux 项目托管 `git`

摘要

1、为什么每一个 Linux 开发者都必须掌握 Git

在 Linux 的世界里，真正的开发从来不是 "写完代码就结束"。

代码只是起点，而 如何管理、协作、演进、回溯和交付代码，才决定了一个项目能走多远。

如果说 gcc / g++ 教会你如何把源代码变成可执行程序，
Makefile 教会你如何让构建过程自动化、工程化，

那么 Git，就是把 "一个人的代码" 升级为 "可持续演进的软件工程" 的关键工具。

1.1、从拷贝代码，到版本管理：开发方式的分水岭

很多 Linux 初学者都会经历这样的阶段：

• 改代码前先复制一份 main_backup.c
• 目录里出现 final.c、final_final.c、final_v3_ok.c
• 不敢改老代码，因为 "怕坏"
• 出问题时不知道改了哪一行、什么时候改的

这些现象，本质上不是 "不会写代码"，

而是 没有版本管理意识。

Git 的出现，正是为了解决这一类问题：

• 记录每一次修改
• 能随时回到任何一个历史状态
• 让多人同时修改同一项目成为可能

1.2、Git 不只是命令，而是一套思维模型

初学 Git 时，很多人会把它当成一堆命令：

git add
git commit
git push

但当项目稍微复杂一点，就会出现困惑：

• 为什么我改了文件却提交不了？
• 分支到底是什么？
• 合并冲突为什么一定会发生？
• reset 和 revert 有什么区别？

这些问题并不是 "命令没记住"，

而是 没有理解 Git 的工作模型。

Git 的核心并不是命令，而是：

• 工作区 / 暂存区 / 仓库的状态流转
• 以提交为单位的历史快照
• 基于分支的并行开发模型
• 用规则约束协作，而不是靠人记忆

这篇文章，将带你真正理解 Git 在 "做什么"，而不仅仅是 "怎么用"。

1.3、为什么说 Git 是 Linux 工程能力的必修课

在真实的 Linux 开发环境中，Git 几乎无处不在：

• C / C++ 项目源码管理
• Bash / Python 工具脚本维护
• 内核、驱动、系统组件开发
• 自动化构建、持续集成、持续交付
• 开源协作与代码评审

不会 Git，几乎无法参与任何稍具规模的 Linux 项目。

更现实的是：

• 面试中，Git 是默认技能
• 实习和工作中，Git 是基础沟通语言
• 开源社区中，Git 是参与门票

掌握 Git，意味着你具备了进入工程世界的基本能力。

1.4、这篇文章会带你学到什么

本篇博客并不是一份 "Git 命令速查表"，而是一套从新手视角出发的完整学习路径：

• 从 0 开始理解 Git 的设计思想
• 掌握 Git 的核心概念与操作逻辑
• 能独立管理一个 Linux 项目
• 能参与多人协作而不制造混乱
• 能在出错时自救，而不是推倒重来

你将不仅学会 "怎么用 Git" ，

更重要的是理解 "为什么要这样用"。

1.5、适合哪些读者？

如果你是以下任何一种情况，这篇文章都会非常适合你：

• 刚接触 Linux 开发的新手
• 学过 Git 但用得心虚、容易出错
• 想把个人项目提升为工程级结构
• 准备找工作，希望补齐 Git 能力短板
• 正在学习 gcc / Makefile / 工具链体系

这篇文章的目标只有一个：

让 Git 成为你工程能力的一部分，而不是负担。

1.6、开始之前

在接下来的章节中，我们将从最基础的 Git 概念讲起，一步步构建起完整的认知体系。

你不需要任何版本管理经验，只需要一个 Linux 环境和一点耐心。

如果你愿意认真读完并实践这篇文章的内容，

你会发现：
写代码的方式没变，但你管理代码的能力，已经发生了质变。

现在，让我们正式开始这段 Git 之旅。

2、认识 Git ------ 它解决了什么问题

在真正学习 Git 的命令之前，我们必须先回答一个根本问题：

如果没有 Git，开发会变成什么样？

理解 Git 的价值，比记住任何一条命令都重要。

2.1、没有版本管理，软件开发会发生什么

几乎所有新手在未接触 Git 前，都会用 "原始但熟悉" 的方式管理代码：

• 用文件夹备份不同版本

  project/
  ├── src/
  ├── src_old/
  ├── src_backup/
  ├── src_final/
  └── src_final_v2/

• 改代码前手动复制一份

• 出 bug 时只能 "凭感觉" 回滚

• 改坏了就重来

这种方式在个人、小规模、短周期项目中勉强可行，但问题非常明显：

问题	后果
无法精确定位改动	Bug 难以追溯
无法恢复任意历史状态	容易丢代码
版本混乱	不敢重构
无法多人协作	工程无法扩展

软件工程的第一道门槛，不是算法，而是 可控地修改代码。

2.2、Git 试图解决的核心问题

Git 的目标并不是 "存代码"，而是解决以下关键问题：

2.2.1、如何记录每一次修改？

• 谁在什么时候改了什么
• 改动的目的是什么
• 是否可以回到之前的状态

2.2.2、如何让多人同时开发？

• 不互相覆盖代码
• 合并不同人的修改
• 冲突可控、可解决

2.2.3、如何让项目持续演进？

• 支持重构
• 支持实验性功能
• 支持长期维护

Git 的出现，本质上是为了 降低试错成本。

2.3、Git 与传统版本管理工具的本质区别

在 Git 之前，版本管理并不存在，只是中心化版本控制：

特性	SVN / CVS	Git
架构	中心服务器	分布式
本地历史	几乎没有	完整历史
离线操作	不支持	完全支持
分支成本	高	极低
容错能力	弱	极强

Git 的关键设计思想是：

每个人本地都有一个完整的仓库。

这意味着：

• 你不依赖网络也能查看历史
• 服务器损坏不等于项目死亡
• 分支和实验变得非常廉价

2.4、Git 的设计哲学：快照，而不是补丁

这是理解 Git 的关键概念之一。

传统版本控制：

• 保存 "每次修改了什么（diff）"

Git 的做法：

• 每次提交保存 整个项目的快照
• 未变化的文件通过指针复用

这带来的直接好处：

• 历史状态恢复极快
• 分支合并逻辑清晰
• 不容易出现 "历史腐烂"

你可以把 Git 想象成：

一个为工程优化的时间机器

2.5、Git 如何改变开发者的工作方式

在没有 Git 时：

• 修改代码是危险的
• 重构是高风险操作
• 实验性尝试代价很高

引入 Git 之后：

• 所有修改都可追踪
• 回滚是常规操作
• 分支用于隔离风险
• 实验可以放心进行

这也是为什么现代软件开发中：

"敢不敢改代码"，往往取决于 Git 用得好不好。

2.6、Git 在 Linux 工程中的真实位置

在 Linux 生态中，Git 并不是 "可选工具"，而是基础设施：

• Linux 内核本身就是 Git 管理
• 几乎所有系统级项目使用 Git
• Makefile、CMake、CI 都围绕 Git 工作
• 包管理、补丁提交、代码评审都基于 Git

可以这样说：

不会 Git，就无法真正参与 Linux 工程世界。

2.7、一个直观的比喻（新手友好）

可以把 Git 类比为：

现实世界	Git 世界
拍照记录成长	提交记录项目
相册分组	分支
删除照片	reset / revert
云备份	远程仓库

Git 做的事情，其实非常直观------

它只是 把 "代码修改" 这件事管理得足够严谨。

2.8、小结

这一章你需要真正记住的不是命令，而是这几句话：

• Git 是为了解决 代码变化不可控 的问题
• Git 的核心是 记录历史 + 管理协作
• Git 改变的是开发方式，而不仅是流程
• Git 是 Linux 工程能力的基础设施

在下一章中，我们将开始真正 "动手"，从安装与配置 Git 开始，搭建一个正确、干净、工程级的 Git 开发环境。

理解 Git 之前，不要急着敲命令。

3、准备 Git 开发环境（Linux 新手必读）

在真正开始使用 Git 之前，最重要的一件事不是敲命令，而是把环境准备对 。

一个配置合理的 Git 环境，能避免 80% 的新手困惑和后期问题。

这一章将从 安装 → 基础配置 → 常见坑位 → 最佳实践 ，一步步带你搭建一个干净、稳定、工程级的 Git 开发环境。

3.1、在 Linux 上安装 Git

在大多数 Linux 发行版中，Git 都可以通过官方包管理器直接安装。

3.1.1、Ubuntu / Debian 系

sudo apt update
sudo apt install git

3.1.2、CentOS / Rocky / Alma

sudo yum install git
# 或
sudo dnf install git

3.1.3、Arch Linux

sudo pacman -S git

安装完成后，验证：

git --version

看到版本号即表示安装成功。

💡 建议 Git 版本不低于 2.x，过旧版本可能在分支、合并等行为上存在差异。

3.2、为什么 "安装成功" 还不够

很多新手安装完 Git 后直接开始使用，但会很快遇到问题：

• 提交时报错：Please tell me who you are
• 提交记录中用户名混乱
• 中文路径或提交信息乱码
• 在不同项目中使用不同身份困难

这些问题，都源于未正确配置 Git。

3.3、Git 的最基本配置（必须完成）

Git 的配置分为三级：

• 系统级（system）
• 用户级（global）
• 仓库级（local）

新手只需关注 用户级配置。

设置用户名和邮箱

git config --global user.name "YourName"
git config --global user.email "you@example.com"

这两项信息会写入你的每一次提交记录，是代码历史的一部分。

查看配置：

git config --global --list

3.4、编码与语言环境（Linux 新手常见坑）

确保终端使用 UTF-8

echo $LANG

推荐结果：

en_US.UTF-8

如果你的系统是中文环境，建议：

export LANG=en_US.UTF-8

防止 Git 显示乱码

git config --global core.quotepath false

否则中文文件名可能显示为转义字符。

3.5、配置默认编辑器（非常重要）

Git 在以下场景会调用编辑器：

• 编写提交信息
• 处理合并冲突
• 修改 rebase 记录

默认编辑器可能是 vi，这对新手非常不友好。

推荐设置为 vim / nano / code

git config --global core.editor "vim"
# 或
git config --global core.editor "nano"

如果你使用 VS Code：

git config --global core.editor "code --wait"

⚠️ 不设置编辑器，是新手 "卡死在终端" 的主要原因之一。

3.6、行尾符问题（跨平台隐患）

不同系统对换行符的处理不同：

系统	行尾
Linux / macOS	LF
Windows	CRLF

推荐配置：

git config --global core.autocrlf input

含义：

• 提交时统一为 LF
• 检出时保持系统风格

这一步对多人协作非常重要。

3.7、Git 配置文件结构简介

Git 的配置本质是文本文件：

• ~/.gitconfig（用户级）
• /etc/gitconfig（系统级）
• .git/config（仓库级）

你可以直接查看：

cat ~/.gitconfig

理解这一点有助于后期排错。

3.8、推荐的新手友好配置（工程实践）

git config --global init.defaultBranch main
git config --global pull.rebase false
git config --global color.ui auto
git config --global fetch.prune true

作用简述：

• 统一默认主分支名
• 避免 pull 时产生困惑
• 增强终端可读性
• 自动清理已删除远程分支

3.9、验证你的 Git 环境是否 "合格"

执行以下操作自检：

mkdir git_test && cd git_test
git init
touch test.txt
git add test.txt
git commit -m "Initial commit"

如果：

• 没有报错
• 提交信息正常
• 显示用户名与邮箱正确

说明你的 Git 环境已经准备就绪。

3.10、小结

在这一章中，你完成了三件非常重要的事情：

• 正确安装 Git
• 理解并完成关键配置
• 避开新手最容易踩的环境坑

请记住一句话：

Git 用不好，往往不是命令问题，而是环境没准备好

4、Git 的核心概念模型（必须真正理解）

如果说 Git 有什么地方最容易让新手 "学不会"，那几乎一定是这一章的内容。

很多人会 Git 命令，却从未真正理解 Git 在做什么，于是：

• 不知道 git add 到底加到了哪里
• 分不清 commit、push、pull 的本质区别
• 出现问题只会 "重来"

本章的目标只有一个：

在你的脑海中，构建一个清晰、稳定、可推演的 Git 模型。

4.1、Git 不是 "文件管理工具"，而是 "状态管理系统"

一个常见误解是：

Git 管理的是文件。

更准确的说法是：

Git 管理的是项目在不同时间点的 "状态"。

每一次提交，Git 记录的不是 "改了哪一行"，而是：

• 当前所有文件组成的一个完整快照
• 并为这个快照生成一个唯一标识

这也是 Git 能够快速切换历史版本的根本原因。

4.2、三个最重要的区域：工作区、暂存区、仓库

这是 Git 的核心模型，必须彻底理解。

工作区  →  暂存区  →  本地仓库

4.2.1、工作区（Working Directory）

• 你正在编辑的文件所在的位置
• 文件真实存在于磁盘上
• 改代码，本质上就是在修改工作区

4.2.2、暂存区（Staging Area / Index）

• 位于 .git/index
• 用于 "挑选" 即将提交的修改
• 是 Git 区别于其他版本管理工具的关键设计

4.2.3、本地仓库（Repository）

• 位于 .git/objects
• 存储所有提交历史
• 不会因切换分支或回滚而丢失

👉 git add 的真正含义：

把当前文件状态放入 "暂存区"，准备提交

4.3、为什么 Git 要设计 "暂存区"

新手最常问的问题之一：

为什么不能直接 commit？

原因很简单：精确控制提交内容。

暂存区允许你：

• 只提交部分修改
• 拆分逻辑清晰的小提交
• 避免 "杂糅提交"

这是专业工程习惯的重要基础。

4.4、Git 状态的完整生命周期

一个文件在 Git 中通常经历以下状态：

状态	含义
Untracked	未被 Git 管理
Modified	已修改但未暂存
Staged	已加入暂存区
Committed	已提交到仓库

你可以通过：

git status

随时查看文件所处状态。

学会读 git status，比记命令更重要。

4.5、Git 如何保存历史：提交（Commit）是什么

每一次提交包含：

• 一个完整项目快照
• 作者信息
• 提交时间
• 提交说明
• 指向父提交的指针

提交在 Git 中形成一个有向无环图（DAG），而不是简单的线性链表。

4.6、分支的本质：指针，而不是副本

这是 Git 最强大的设计之一。

分支 ≠ 拷贝一份代码

分支本质上只是：

指向某个提交的可移动指针

main ──●──●──●
             ▲
           feature

创建分支几乎是瞬间完成的，因此：

• 分支非常轻量
• 可以频繁创建、删除

4.7、HEAD：你当前 "站在" 的位置

HEAD 是一个特殊指针，表示：

你当前所在的提交或分支

• 通常指向某个分支
• 切换分支，就是移动 HEAD
• 分离 HEAD 状态是高级操作的基础

理解 HEAD，可以解释：

• checkout 在做什么
• 为什么会 "迷路"

4.8、本地仓库与远程仓库的关系

Git 是分布式的：

• 本地仓库是完整的
• 远程仓库只是 "共享节点"

常见关系结构：

本地分支 ←→ 远程跟踪分支 ←→ 远程仓库

这意味着：

• 不 push 也可以正常工作
• pull = fetch + merge（或 rebase）

4.9、Git 模型的一个完整心智图

你应该在脑中形成如下结构：

文件 → 工作区 → 暂存区 → 本地仓库 → 远程仓库

所有 Git 命令，都只是：

在这些区域之间移动或复制 "状态"。

4.10、小结（一定要记住的几点）

如果你只记住以下几条，这一章就是成功的：

1. Git 管理的是状态快照
2. 工作区 / 暂存区 / 仓库 是 Git 的核心模型
3. 分支只是指针，非常轻量
4. HEAD 决定你当前的位置
5. 理解模型，命令自然通

从下一章开始，我们将正式进入 Git 的日常操作，学习 最基础但最重要的 Git 工作流命令，并通过大量示例帮助你把这个模型真正用起来。

理解 Git，是成为工程师的第一步。

5、第一个 Git 项目 ------ 从 0 到 1

前面的章节中，我们已经完成了三件事：

• 正确安装并配置了 Git
• 理解了 Git 的核心概念模型
• 知道了工作区、暂存区、仓库分别是什么

现在，是时候把这些抽象概念全部落地 了。

这一章我们将 从一个空目录开始，完整地走一遍 Git 项目的生命周期。

这不是演示命令，而是在建立你今后所有项目都能复用的 "标准起手式"。

5.1、创建一个真正 "干净" 的项目目录

首先，不要在杂乱的目录里初始化 Git。

mkdir git_demo
cd git_demo

建议每一个项目：

• 一个独立目录
• 不与其他项目混用
• 从一开始就干净

5.2、初始化 Git 仓库：git init

git init

执行后，当前目录发生的变化只有一个：

.git/

这个隐藏目录就是：

• Git 的全部历史
• Git 的配置
• Git 的索引

❗ 删掉 .git，项目就 "失忆" 了。

查看仓库状态：

git status

此时你会看到：

On branch main
No commits yet

5.3、第一个文件：从工作区开始

创建一个最简单的文件：

echo "Hello Git" > README.md

此时文件状态是：

git status

输出会提示：

Untracked files:
  README.md

这意味着：

• 文件存在于工作区
• Git 尚未管理它

5.4、把文件交给 Git 管理：git add

git add README.md

再查看状态：

git status

你会看到：

Changes to be committed:
  new file: README.md

此时：

• 文件已进入暂存区
• 准备进入历史

5.5、第一次提交：git commit

git commit -m "Initial commit: add README"

这一步发生了什么？

• Git 生成一个提交对象
• 保存项目的快照
• 提交记录进入历史

查看提交历史：

git log

5.6、修改文件：体验 Git 的状态变化

编辑 README.md：

echo "This is my first Git project." >> README.md

查看状态：

git status

你会看到：

modified: README.md

此时文件：

• 已修改
• 尚未暂存

5.7、拆分提交：好的工程习惯

推荐做法：

git add README.md
git commit -m "Update README with project description"

一个提交只做一件事

一个提交说明清楚做了什么

这是工程化 Git 使用的核心原则。

5.8、查看修改内容：git diff

在提交前，永远建议：

git diff

它能告诉你：

• 改了哪一行
• 是否误改了内容

这是防止 "脏提交" 的重要手段。

5.9、忽略不该进入仓库的文件：.gitignore

新建 .gitignore：

echo "*.log" > .gitignore
echo "build/" >> .gitignore

然后提交：

git add .gitignore
git commit -m "Add .gitignore"

.gitignore 的作用是：

• 防止临时文件污染仓库
• 保持项目干净

5.10、一个最小但完整的 Git 项目结构

此时你的项目可能是：

git_demo/
├── README.md
├── .gitignore
└── .git/

这已经是一个：

• 可追溯
• 可回滚
• 可扩展

的 Git 项目了。

5.11、新手最容易犯的几个错误

❌ 在已有杂乱目录直接 init

❌ 不写提交信息或乱写

❌ 一个提交包含大量不相关改动

❌ 忽视 git status 和 git diff

Git 用得好坏，往往体现在 "习惯"，而不是命令。

5.12、小结

在这一章中，你已经：

• 从 0 创建了一个 Git 仓库
• 完整经历了 add → commit 的流程
• 理解了文件状态的变化
• 建立了良好的提交习惯

从下一章开始，我们将引入 分支，学习 Git 最强大的能力之一：

在不破坏主线的前提下，自由实验与协作。