【Git：综合复盘】Git 原理与使用

🎬 个人主页 ：艾莉丝努力练剑
❄专栏传送门 ：《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》
《Linux操作系统编程详解》《笔试/面试常见算法：从基础到进阶》《Python干货分享》

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

---

🎬 艾莉丝的简介：

---

文章目录

• [1 ~> 学习目标](#1 ~> 学习目标)
• • [1.1 技术目标](#1.1 技术目标)
  • [1.2 协作目标](#1.2 协作目标)
• [2 ~> Git 初识](#2 ~> Git 初识)
• • [2.1 版本控制器的作用](#2.1 版本控制器的作用)
  • [2.2 核心注意事项](#2.2 核心注意事项)
• [3 ~> Git 安装](#3 ~> Git 安装)
• • [3.1 Linux-centos 系统](#3.1 Linux-centos 系统)
  • [3.2 Linux-ubuntu 系统](#3.2 Linux-ubuntu 系统)
  • [3.3 Windows 系统](#3.3 Windows 系统)
• [4 ~> Git 基本操作](#4 ~> Git 基本操作)
• • [4.1 创建本地仓库](#4.1 创建本地仓库)
  • [4.2 配置 Git](#4.2 配置 Git)
  • [4.3 核心概念：工作区、暂存区、版本库](#4.3 核心概念：工作区、暂存区、版本库)
  • [4.4 文件添加与提交](#4.4 文件添加与提交)
  • • [4.4.1 添加到暂存区](#4.4.1 添加到暂存区)
    • [4.4.2 提交到版本库](#4.4.2 提交到版本库)
  • [4.5 查看提交历史](#4.5 查看提交历史)
  • [4.6 修改文件与差异查看](#4.6 修改文件与差异查看)
  • • [4.6.1 查看仓库状态](#4.6.1 查看仓库状态)
    • • [4.6.2 查看具体修改差异](#4.6.2 查看具体修改差异)
  • [4.7 版本回退](#4.7 版本回退)
  • • [4.7.1 常用写法](#4.7.1 常用写法)
    • [4.7.2 操作记录追溯](#4.7.2 操作记录追溯)
  • [4.8 撤销修改的三种场景](#4.8 撤销修改的三种场景)
  • • [4.8.1 场景1：修改仅在工作区，未 add](#4.8.1 场景1：修改仅在工作区，未 add)
    • [4.8.2 场景2：已 add 到暂存区，未 commit](#4.8.2 场景2：已 add 到暂存区，未 commit)
    • [4.8.3 场景3：已 commit 提交，未推送到远程](#4.8.3 场景3：已 commit 提交，未推送到远程)
  • [4.9 删除文件](#4.9 删除文件)
  • • [4.9.1 误删恢复](#4.9.1 误删恢复)
    • [4.9.2 确认删除文件](#4.9.2 确认删除文件)
• [5 ~> 分支管理](#5 ~> 分支管理)
• • [5.1 分支的概念](#5.1 分支的概念)
  • [5.2 分支基础操作](#5.2 分支基础操作)
  • [5.3 合并冲突与解决](#5.3 合并冲突与解决)
  • • [5.3.1 冲突现象](#5.3.1 冲突现象)
    • [5.3.2 解决步骤](#5.3.2 解决步骤)
  • [5.4 两种合并模式](#5.4 两种合并模式)
  • • [5.4.1 Fast-forward（快进模式）](#5.4.1 Fast-forward（快进模式）)
    • [5.4.2 普通合并（禁用快进）](#5.4.2 普通合并（禁用快进）)
  • [5.5 工作区临时储藏 git stash](#5.5 工作区临时储藏 git stash)
  • [5.6 分支管理最佳实践](#5.6 分支管理最佳实践)
• [6 ~> 远程操作](#6 ~> 远程操作)
• • [6.1 分布式版本控制系统原理](#6.1 分布式版本控制系统原理)
  • [6.2 远程仓库准备](#6.2 远程仓库准备)
  • • [6.2.1 SSH 公钥配置](#6.2.1 SSH 公钥配置)
  • [6.3 克隆远程仓库](#6.3 克隆远程仓库)
  • • [6.3.1 查看远程仓库信息](#6.3.1 查看远程仓库信息)
  • [6.4 推送与拉取](#6.4 推送与拉取)
  • • [6.4.1 推送到远程](#6.4.1 推送到远程)
    • [6.4.2 拉取远程更新](#6.4.2 拉取远程更新)
  • [6.5 .gitignore 忽略文件](#6.5 .gitignore 忽略文件)
  • • [6.5.1 常用规则](#6.5.1 常用规则)
    • [6.5.2 相关命令](#6.5.2 相关命令)
  • [6.6 命令别名配置](#6.6 命令别名配置)
• [7 ~> 标签管理](#7 ~> 标签管理)
• • [7.1 标签的作用](#7.1 标签的作用)
  • [7.2 标签基础操作](#7.2 标签基础操作)
• [8 ~> 多人协作开发](#8 ~> 多人协作开发)
• • [8.1 单分支协作流程](#8.1 单分支协作流程)
  • [8.2 多分支（Feature）协作流程](#8.2 多分支（Feature）协作流程)
  • • [8.2.1 协作注意事项](#8.2.1 协作注意事项)
  • [8.3 远程分支清理](#8.3 远程分支清理)
• [9 ~> 企业级开发模型](#9 ~> 企业级开发模型)
• • [9.1 DevOps 与系统环境](#9.1 DevOps 与系统环境)
  • • [9.1.1 DevOps 理念](#9.1.1 DevOps 理念)
    • [9.1.2 系统开发环境](#9.1.2 系统开发环境)
  • [9.2 Git Flow 分支设计规范](#9.2 Git Flow 分支设计规范)
  • [9.3 企业级项目开发流程](#9.3 企业级项目开发流程)
  • • [9.3.1 新需求开发](#9.3.1 新需求开发)
    • [9.3.2 线上 Bug 紧急修复](#9.3.2 线上 Bug 紧急修复)
    • [9.3.3 测试/预发布环境 Bug 修复](#9.3.3 测试/预发布环境 Bug 修复)
• 结尾

---

---

1 ~> 学习目标

1.1 技术目标

• 掌握 Git 企业级应用，深刻理解工作区、暂存区、版本库的含义与操作原理
• 掌握 Git 版本管理，可自由完成版本回退、撤销、修改等全流程操作
• 掌握 Git 分支管理，覆盖分支创建、切换、合并、删除全生命周期，适配多场景分支管理
• 掌握本地仓库与远程仓库的交互，实现基于分支的个人开发与多人协作
• 理解分布式版本控制系统原理，掌握标准化多人协作开发模式

1.2 协作目标

• 掌握企业级常见分支策略（master/release/develop/feature/hotfix）
• 理解不同团队、不同环境下的分支模型，结合开发、测试、技术经理等角色，理解项目开发全流程

---

2 ~> Git 初识

2.1 版本控制器的作用

版本控制器是记录文件每一次改动与版本迭代的管理系统，核心解决两类问题：

• 单文件多版本管理，避免"报告-v1/最终版/究极版"这类手动副本混乱
• 支持多人协同作业，统一管理代码修改，追溯变更历史

Git 是当前最主流的分布式版本控制系统，可管理所有格式文件，核心价值是管理软件开发的源代码。

2.2 核心注意事项

• 所有版本控制系统（包括 Git）只能跟踪文本文件的改动（代码、TXT、网页等），可以精确到行级修改。
• 二进制文件（图片、视频等）仅能被版本管理，无法跟踪具体内容变化，仅能记录文件大小变动。

---

3 ~> Git 安装

Git 是开源工具，支持 Linux、Unix、Mac、Windows 全平台。

3.1 Linux-centos 系统

# 安装 Git
sudo yum -y install git

# 查看安装版本
git --version

3.2 Linux-ubuntu 系统

# 安装 Git
sudo apt-get install git -y

# 查看安装版本
git --version

3.3 Windows 系统

通过官方安装包安装，安装后在 Git Bash 终端中执行命令。

---

4 ~> Git 基本操作

4.1 创建本地仓库

仓库（Repository）是进行版本控制的文件目录，创建命令需在目标目录下执行：

git init

执行后目录下会生成隐藏的 .git 文件夹，这是 Git 的版本库目录，禁止手动修改其中内容，否则会破坏仓库完整性。

4.2 配置 Git

安装后第一步必须配置用户名与邮箱，用于标识提交者身份：

# 全局配置（本机所有仓库生效）
git config --global user.name "你的昵称"
git config --global user.email "你的邮箱"

# 查看所有配置
git config -l

# 删除指定全局配置
git config --global --unset user.name

• 不加 --global 则仅对当前仓库生效，需在仓库目录下执行。

4.3 核心概念：工作区、暂存区、版本库

区域	英文名	说明
工作区	Working Directory	电脑上直接编写代码/文件的目录，即我们操作的文件夹
暂存区	Stage / Index	临时存储修改的区域，对应 .git/index 文件
版本库	Repository	即 .git 隐藏目录，存储所有版本记录、元数据与对象

三者流转关系：

1. git add：工作区的修改 → 暂存区
2. git commit：暂存区的修改 → 版本库（当前分支）

补充： Git 初始化会自动创建 master 主分支，以及指向当前分支的指针 HEAD。

4.4 文件添加与提交

4.4.1 添加到暂存区

# 添加指定文件
git add 文件名1 文件名2

# 添加指定目录（含子目录）
git add 目录名

# 添加当前目录所有修改
git add .

4.4.2 提交到版本库

# 提交暂存区全部内容，必须填写提交说明
git commit -m "提交描述信息"

# 提交暂存区指定文件
git commit 文件名 -m "提交描述"

• 提交说明用于记录本次修改内容，是版本追溯的关键，禁止省略。
• 可多次 git add 不同文件，最后一次 git commit 一次性提交所有暂存修改。

4.5 查看提交历史

# 完整展示提交记录
git log

# 精简单行显示
git log --pretty=oneline

# 图形化展示分支合并历史
git log --graph --pretty=oneline --abbrev-commit

• 每次提交的唯一标识是 commit id，由 SHA1 算法生成的十六进制字符串，而非递增数字。

4.6 修改文件与差异查看

4.6.1 查看仓库状态

git status

可查看文件是否被修改、是否暂存、是否提交，以及当前分支状态。

4.6.2 查看具体修改差异

# 查看工作区 与 暂存区 的差异
git diff 文件名

# 查看工作区 与 版本库（最新提交）的差异
git diff HEAD -- 文件名

4.7 版本回退

使用 git reset 命令回退版本，核心是移动分支指针，三个参数区别如下：

参数	版本库	暂存区	工作区	适用场景
--soft	回退	不变	不变	仅撤销提交，修改保留在暂存区
--mixed（默认）	回退	回退	不变	撤销提交与暂存，修改保留在工作区
--hard	回退	回退	回退	彻底回退，工作区所有未提交修改会丢失

4.7.1 常用写法

# 回退到上一个版本
git reset --hard HEAD^

# 回退到上上一个版本
git reset --hard HEAD^^

# 回退到指定 commit id 版本（可写前几位）
git reset --hard commit_id

4.7.2 操作记录追溯

如果误回退想恢复，可通过 git reflog 查看所有操作记录（包括回退、提交等），找到目标 commit id 再回退：

git reflog

4.8 撤销修改的三种场景

4.8.1 场景1：修改仅在工作区，未 add

# 恢复文件到最近一次 add/commit 的状态
git checkout -- 文件名

注意： -- 不能省略，否则命令含义变为切换分支。

4.8.2 场景2：已 add 到暂存区，未 commit

# 先撤销暂存，回到工作区修改状态
git reset HEAD 文件名
# 再撤销工作区修改
git checkout -- 文件名

4.8.3 场景3：已 commit 提交，未推送到远程

使用 git reset --hard HEAD^ 回退到上一个版本即可。

若已推送到远程仓库，无法仅通过本地操作撤销远程记录。

4.9 删除文件

4.9.1 误删恢复

如果手动删除了工作区文件，可从版本库恢复：

git checkout -- 文件名

4.9.2 确认删除文件

从版本库中删除文件需执行：

# 从工作区和暂存区同时删除
git rm 文件名
# 提交删除操作
git commit -m "删除文件说明"

---

5 ~> 分支管理

5.1 分支的概念

分支可以理解为"平行时间线"，不同分支上的开发互不干扰，功能完成后再合并。

• master：主分支，默认创建，是稳定的代码主线
• HEAD：指针，指向当前所在的分支
• 分支本质是一个指向 commit 的指针，创建、切换、删除都极快，因为只是指针变动。

5.2 分支基础操作

# 查看所有本地分支
git branch

# 创建分支
git branch 分支名

# 切换分支
git checkout 分支名

# 创建并切换分支（一步完成）
git checkout -b 分支名

# 合并指定分支到当前分支
git merge 分支名

# 删除已合并的分支
git branch -d 分支名

# 强制删除未合并的分支
git branch -D 分支名

注意： 不能删除当前所在的分支，需切换到其他分支再删除。

5.3 合并冲突与解决

当两个分支对同一文件的同一位置做了不同修改，合并时会产生冲突，Git 无法自动合并，需手动处理。

5.3.1 冲突现象

合并失败后，冲突文件会被特殊标记：

<<<<<<< HEAD
当前分支的内容
=======
待合并分支的内容
>>>>>>> 分支名

5.3.2 解决步骤

1. 手动编辑文件，保留正确内容，删除 <<<<<<< ======= >>>>>>> 标记
2. git add 文件名 标记冲突已解决
3. git commit -m "合并说明" 提交合并结果

5.4 两种合并模式

5.4.1 Fast-forward（快进模式）

当待合并分支是当前分支的直接后继时，Git 直接移动当前分支指针，不生成新的 commit。

• 优点：速度快
• 缺点：删除分支后，分支历史会丢失，看不出曾经合并过

5.4.2 普通合并（禁用快进）

git merge --no-ff -m "合并说明" 分支名

• 强制生成一个新的合并 commit
• 优点：分支历史完整，可追溯合并记录
• 企业开发中推荐使用，保留分支演化轨迹

5.5 工作区临时储藏 git stash

开发到一半需要切换分支处理其他任务时，可将未提交的工作现场储藏起来：

# 储藏当前工作区与暂存区
git stash

# 查看储藏列表
git stash list

# 恢复最近一次储藏，并删除储藏记录
git stash pop

# 恢复指定储藏，不删除记录
git stash apply stash@{0}
# 删除指定储藏
git stash drop stash@{0}

5.6 分支管理最佳实践

1. master 分支保持稳定，仅用于发布版本，不直接在上面开发
2. 日常开发在 develop 分支进行，版本发布时再合并到 master
3. 每个新功能建一个 feature 分支，开发完合并回 develop，用完删除
4. 线上紧急 bug 建 hotfix 分支，基于 master 创建，修复后合并回 master 和 develop
5. 合并分支时，先在自己的分支合并 master/develop，解决冲突后再合并到主分支，避免污染主分支

---

6 ~> 远程操作

6.1 分布式版本控制系统原理

• 每个人的电脑上都有完整的版本库，开发无需联网
• 通过"中央服务器"（如 Gitee、GitHub）交换修改，服务器仅起中转作用
• 任意一台电脑损坏，都可从其他机器复制完整版本库，安全性高

6.2 远程仓库准备

以 Gitee（码云）为例，注册账号后可创建免费远程仓库。

• 两种传输协议：
  • HTTPS：无需配置，每次推送需输入账号密码
  • SSH：需配置 SSH 公钥，配置后免密推送，推荐使用

6.2.1 SSH 公钥配置

1. 生成密钥对：

ssh-keygen -t rsa -C "你的邮箱"

一路回车，生成 ~/.ssh/id_rsa（私钥，不可泄露）和 ~/.ssh/id_rsa.pub（公钥）。

1. 将公钥内容添加到 Gitee 账号的 SSH 公钥设置中。

6.3 克隆远程仓库

# HTTPS 方式
git clone shturl.cc/m5iULlrG用户名/仓库名.git

# SSH 方式
git clone git@shturl.cc:用户名/仓库名.git

• 克隆后本地会自动关联远程仓库，默认远程仓库名为 origin
• 本地 master 分支自动对应远程 origin/master 分支

6.3.1 查看远程仓库信息

# 查看远程仓库名
git remote

# 查看详细地址
git remote -v

6.4 推送与拉取

6.4.1 推送到远程

# 将本地分支推送到远程同名分支
git push origin 本地分支名

# 完整格式：本地分支映射到远程分支
git push origin 本地分支名:远程分支名

6.4.2 拉取远程更新

# 拉取远程分支并合并到当前本地分支
git pull origin 远程分支名

• 推送失败时，通常是远程版本比本地新，需先 git pull 合并远程修改，解决冲突后再推送。

6.5 .gitignore 忽略文件

在仓库根目录创建 .gitignore 文件，写入规则可让 Git 自动忽略指定文件/目录。

6.5.1 常用规则

# 忽略所有 .ini 后缀文件
*.ini
# 忽略所有 .so 后缀文件
*.so

# 忽略所有 .开头的隐藏文件
.*
# 但不忽略 .gitignore 文件
!.gitignore

6.5.2 相关命令

# 强制添加被忽略的文件
git add -f 文件名

# 检查哪个规则忽略了文件
git check-ignore -v 文件名

6.6 命令别名配置

简化长命令，提升操作效率：

# 示例：git st 代替 git status
git config --global alias.st status

# 示例：git last 查看最近一次提交
git config --global alias.last 'log -1'

---

7 ~> 标签管理

7.1 标签的作用

标签（Tag）是对某次提交的命名标识，相当于版本别名，用于里程碑版本标记（如 v1.0）。

• 相比难记的 commit id，标签名直观易记，方便版本定位与回退。

7.2 标签基础操作

# 查看所有标签
git tag

# 在最新提交打标签
git tag v1.0

# 在指定 commit 打标签
git tag v0.9 commit_id

# 创建带说明的标签
git tag -a v1.0 -m "版本说明" commit_id

# 查看标签对应提交信息
git show v1.0

# 删除本地标签
git tag -d v1.0

# 推送单个标签到远程
git push origin v1.0

# 推送所有标签到远程
git push origin --tags

# 删除远程标签
git push origin :refs/tags/v1.0

• 标签默认仅存在本地，不会自动推送到远程。

---

8 ~> 多人协作开发

8.1 单分支协作流程

同一分支（如 dev）多人协作的标准流程：

1. 编写代码，本地 commit
2. git push origin 分支名 尝试推送
3. 若推送失败，说明远程有更新，执行 git pull origin 分支名
4. 若合并有冲突，手动解决冲突并 commit
5. 再次 git push origin 分支名 推送成功

8.2 多分支（Feature）协作流程

企业中每个需求对应一个 feature 分支，互不干扰：

1. 开发者基于 develop 创建 feature/xxx 分支，本地开发
2. 开发完成后推送到远程同名分支
3. 发起代码评审（Pull Request），评审通过后合并到 develop
4. 功能上线后删除 feature 分支

8.2.1 协作注意事项

• 接手他人分支时，先 git pull 拉取远程最新内容
• 本地分支需与远程分支建立追踪关系，才能直接 git pull/push

# 创建本地分支并关联远程分支
git checkout -b 本地分支名 origin/远程分支名

# 已有本地分支，设置追踪关系
git branch --set-upstream-to=origin/远程分支名 本地分支名

8.3 远程分支清理

远程删除分支后，本地仍会残留远程分支引用，可清理：

# 查看远程分支状态
git remote show origin

# 清理已删除的远程分支引用
git remote prune origin

---

9 ~> 企业级开发模型

9.1 DevOps 与系统环境

9.1.1 DevOps 理念

打破开发（Dev）与运维（Ops）的部门墙，通过自动化工具与流程，实现软件快速、可靠的构建、测试、发布与运维。Git 是 DevOps 体系中代码管理的核心工具。

9.1.2 系统开发环境

环境	作用
开发环境	日常开发调试，开启完整错误日志
测试环境	开发到生产的过渡，功能测试验证
预发布环境	配置与生产一致，上线前最后验证
生产环境	正式对外提供服务的线上环境

9.2 Git Flow 分支设计规范

企业标准分支模型，对应不同开发环境：

分支	名称	对应环境	说明
master	主分支	生产环境	只读，唯一稳定代码库，由 release 合并而来，发布时打 tag
release	预发布分支	测试/预发布环境	基于 develop 创建，用于提测，上线后合并到 master
develop	开发分支	开发环境	只读，保持最新开发完成的代码，由 feature 合并而来
feature	功能分支	本地开发	基于 develop 创建，每个新功能一个分支，完成后合并回 develop
hotfix	紧急修复分支	本地修复	基于 master 创建，修复线上紧急 bug，完成后合并到 master 和 develop

9.3 企业级项目开发流程

9.3.1 新需求开发

1. 基于 develop 创建 feature 分支开发
2. 开发完成发起代码评审，评审通过合并到 develop
3. 基于 develop 创建 release 分支，提交测试
4. 测试通过后，release 合并到 master，打标签发布
5. 同步合并回 develop，删除 feature、release 分支

9.3.2 线上 Bug 紧急修复

1. 基于 master 创建 hotfix 分支修复
2. 修复验证后，合并到 master 发布
3. 同步合并到 develop 分支，删除 hotfix 分支

9.3.3 测试/预发布环境 Bug 修复

• 优先在对应 feature 分支修复，再重新走提测流程
• 确认 develop 分支是否存在同样问题，同步修复

---

结尾

uu们，本文的内容到这里就全部结束了，艾莉丝在这里再次感谢您的阅读！

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ### 艾莉丝努力练剑 C/C++ & Linux 底层探索者 | 一个正在努力练剑的技术博主 *** ** * ** *** 👀 【关注】 跟随我一起深耕技术领域，见证每一次成长。 ❤️ 【点赞】 让优质内容被更多人看见，让知识传递更有力量。 ⭐ 【收藏】 把核心知识点存好，在需要时随时查、随时用。 💬 【评论】 分享你的经验或疑问，评论区一起交流避坑！ 不要忘记给博主"一键四连"哦！ "今日练剑达成！" "技术之路难免有困惑，但同行的人会让前进更有方向。" |

结语：希望对学习Linux相关内容的uu有所帮助，不要忘记给博主"一键四连"哦！

往期回顾：

【Git：企业级开发模型】Git企业级Git工作流实战：基于Git Flow的分支模型与开发流程

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡 ૮₍ ˶ ˊ ᴥ ˋ˶₎ა