linux shell编程实战 10 Git工具详解与运维场景实战

一、什么是Git？为什么运维工程师必须掌握？

在开始学习操作前，我们先明确一个核心问题：Git到底是什么，它和Linux shell编程、运维工作有什么关系？

Git是一款由Linus Torvalds（Linux内核创始人）开发的分布式版本控制系统 ，它的核心作用是追踪文件的修改历史，并允许开发者（或运维工程师）在不同版本间切换、合并修改、协作开发。

对于「Linux shell编程与运维」课程来说，Git的价值体现在三个核心场景：

脚本版本管理：运维中编写的自动化脚本（如服务监控、日志清理、备份脚本）会不断迭代（修复bug、增加功能），Git能记录每一次修改的细节，避免"改坏了回不去"的尴尬。
配置文件追踪 ：服务器的核心配置（如/etc/nginx/nginx.conf、/etc/sysconfig/firewalld）一旦误改可能导致服务崩溃，Git可追踪配置变更，快速回滚到正常版本。
团队协作：实际运维中多人间会共同维护脚本或配置，Git能解决"多人同时修改同一文件"的冲突问题，明确每个人的修改内容。

二、Git安装与核心概念铺垫

1. 安装Git（Linux环境）

在主流Linux发行版中，Git可通过包管理器直接安装：

Ubuntu/Debian系统：

bash 复制代码

sudo apt update && sudo apt install git -y

CentOS/RHEL系统：

bash 复制代码

sudo yum install git -y

安装后验证：

bash 复制代码

git --version  # 输出类似：git version 2.34.1

2. 必须理解的3个核心区域

Git管理文件的过程涉及三个关键区域，这是后续所有操作的基础，务必吃透：

区域名称	含义	运维场景类比
工作区（Working Directory）	就是你正在编辑文件的目录（比如`/opt/scripts/`），文件在这里被修改。	相当于"正在编辑的nginx配置文件"，还没保存到服务器生效
暂存区（Staging Area）	临时存放"准备提交的修改"的区域，可理解为"待确认的变更清单"。	相当于"把修改后的配置文件放到`/tmp`临时目录，准备下一步替换正式配置"
本地仓库（Local Repository）	存放所有版本记录的数据库（隐藏目录`.git`），一旦提交，修改会被永久保存。	相当于"把每次生效的配置文件备份到`/backup/config_history/`，带时间戳和说明"

简单说：工作区修改 → 暂存区确认 → 本地仓库保存，这是Git管理文件的基本流程。

三、Git基础操作：从初始化到第一次提交

我们以"编写一个Nginx服务监控脚本"为例，全程演示Git的使用（运维场景中，监控脚本是高频需求，且需要不断优化）。

1. 初始化仓库：创建"脚本管理目录"

首先，我们需要一个专门存放运维脚本的目录，并让Git接管这个目录的版本管理：

bash 复制代码

# 1. 创建脚本目录（运维中通常集中管理脚本，方便维护）
mkdir -p /opt/ops_scripts/nginx_monitor && cd /opt/ops_scripts/nginx_monitor

# 2. 初始化Git仓库（仅第一次执行，会生成隐藏目录.git，存储版本数据）
git init

执行后会显示：Initialized empty Git repository in /opt/ops_scripts/nginx_monitor/.git/，表示仓库创建成功。此时目录下会多一个.git隐藏目录（可用ls -la查看），千万不要删除它，否则所有版本记录会丢失。

2. 编写初始脚本（工作区操作）

假设我们的第一个任务是：编写nginx_monitor.sh，实现最基础的"检查Nginx进程是否存活"功能。

用vim创建并编辑脚本：

bash 复制代码

vim nginx_monitor.sh

写入以下内容（基础版本）：

bash 复制代码

#!/bin/bash
# 功能：监控Nginx进程是否存活
# 作者：你的名字
# 日期：$(date +%F)

# 检查Nginx进程
nginx_pid=$(pgrep nginx)

if [ -z "$nginx_pid" ]; then
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] 警告：Nginx进程未运行！"
else
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] Nginx运行正常，PID：$nginx_pid"
fi

保存退出（vim中按ESC，输入:wq）。此时脚本在工作区，Git还未追踪它。

3. 暂存文件：告诉Git"我要保存这个修改"

刚创建的脚本在工作区，需要先加入暂存区，告诉Git"这些修改是我确认要保存的"：

bash 复制代码

# 查看当前工作区状态（哪些文件未被追踪、哪些被修改）
git status

执行后会显示：

plain 复制代码

On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        nginx_monitor.sh

nothing added to commit but untracked files present (use "git add" to track)

提示nginx_monitor.sh是"未追踪文件"（Untracked），需要用git add加入暂存区：

bash 复制代码

# 将脚本加入暂存区
git add nginx_monitor.sh

再次执行git status，会显示：

plain 复制代码

On branch master
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   nginx_monitor.sh

此时脚本已进入暂存区，等待被提交到本地仓库。

4. 提交到本地仓库：永久保存第一个版本

暂存区的修改需要"提交"到本地仓库，才算完成一次版本记录。提交时必须填写"提交注释"，说明本次修改的内容（这是运维中追溯历史的关键）。

bash 复制代码

# 提交到本地仓库，-m后面是注释（必须具体，说明本次做了什么）
git commit -m "v1.0: 完成Nginx基础监控功能，检查进程是否存活并输出状态"

执行后会显示提交成功的信息，包含：

[master (root-commit) a1b2c3d]：a1b2c3d是本次提交的唯一ID（版本号），用于后续定位版本
1 file changed, 12 insertions(+)：表示新增了1个文件，12行内容

5. 查看提交历史：追踪版本记录

提交后，可用git log查看所有版本记录，这是运维中"回溯修改"的核心命令：

bash 复制代码

git log

输出示例（关键信息已标注）：

plain 复制代码

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0  # 版本ID（唯一标识）
Author: 你的名字 <你的邮箱>  # 提交人（多人协作时明确责任人）
Date:   Wed Oct 22 10:30:00 2025 +0800  # 提交时间（运维中可定位"何时改了配置"）

    v1.0: 完成Nginx基础监控功能，检查进程是否存活并输出状态  # 提交注释（核心：说明改了什么）

如果提交记录多，可用git log --oneline简化输出（只显示版本ID前7位和注释）：

bash 复制代码

git log --oneline  # 输出：a1b2c3d v1.0: 完成Nginx基础监控功能...

四、运维场景实战：脚本迭代与版本管理

在实际运维中，脚本不会一成不变。比如用户反馈"监控脚本只输出状态，没有告警功能"，我们需要迭代脚本，此时Git的价值会充分体现。

1. 第二次迭代：给脚本增加"邮件告警"功能

修改nginx_monitor.sh，在Nginx进程未运行时发送邮件告警（需要服务器配置邮件服务，这里简化逻辑）：

bash 复制代码

vim nginx_monitor.sh  # 编辑脚本

修改后的内容（新增告警部分）：

bash 复制代码

#!/bin/bash
# 功能：监控Nginx进程是否存活，异常时发送邮件告警
# 作者：你的名字
# 日期：2025-10-22
# 版本：v2.0（新增邮件告警）

# 配置参数
ALERT_EMAIL="admin@example.com"  # 告警接收邮箱

# 检查Nginx进程
nginx_pid=$(pgrep nginx)

if [ -z "$nginx_pid" ]; then
    # 异常：输出警告并发送邮件
    msg="[$(date +'%Y-%m-%d %H:%M:%S')] 警告：Nginx进程未运行！"
    echo "$msg"
    echo "$msg" | mail -s "Nginx监控告警" $ALERT_EMAIL  # 发送邮件（需提前配置mail命令）
else
    # 正常：输出状态
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] Nginx运行正常，PID：$nginx_pid"
fi

保存退出后，工作区的脚本已被修改，再次用git status查看：

plain 复制代码

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   nginx_monitor.sh

提示nginx_monitor.sh被修改（modified），但未进入暂存区。

2. 暂存并提交第二次修改

按流程将修改加入暂存区并提交，注意注释要说明"新增了什么功能"：

bash 复制代码

# 暂存修改
git add nginx_monitor.sh

# 提交到仓库（注释明确说明迭代内容）
git commit -m "v2.0: 新增邮件告警功能，Nginx异常时向admin@example.com发送邮件"

此时git log --oneline会显示两条记录：

plain 复制代码

c3d4e5f v2.0: 新增邮件告警功能，Nginx异常时向admin@example.com发送邮件
a1b2c3d v1.0: 完成Nginx基础监控功能，检查进程是否存活并输出状态

3. 查看版本差异：明确两次修改的具体内容

如果想知道v2.0比v1.0具体改了哪些代码（比如排查"新增功能导致脚本出错"），可用git diff命令：

bash 复制代码

# 比较两个版本的差异（版本ID用git log --oneline获取的前7位）
git diff a1b2c3d c3d4e5f

输出会显示具体的代码变更（+表示新增行，-表示删除行）：

diff 复制代码

diff --git a/nginx_monitor.sh b/nginx_monitor.sh
index 8f3d2e1..7a9b0c1 100755
--- a/nginx_monitor.sh
+++ b/nginx_monitor.sh
@@ -1,7 +1,9 @@
 #!/bin/bash
-# 功能：监控Nginx进程是否存活
+# 功能：监控Nginx进程是否存活，异常时发送邮件告警
 # 作者：你的名字
-# 日期：$(date +%F)
+# 日期：2025-10-22
+# 版本：v2.0（新增邮件告警）
+
+# 配置参数
+ALERT_EMAIL="admin@example.com"  # 告警接收邮箱
 
 # 检查Nginx进程
 nginx_pid=$(pgrep nginx)
@@ -9,7 +11,10 @@ nginx_pid=$(pgrep nginx)
 if [ -z "$nginx_pid" ]; then
-    echo "[$(date +'%Y-%m-%d %H:%M:%S')] 警告：Nginx进程未运行！"
+    # 异常：输出警告并发送邮件
+    msg="[$(date +'%Y-%m-%d %H:%M:%S')] 警告：Nginx进程未运行！"
+    echo "$msg"
+    echo "$msg" | mail -s "Nginx监控告警" $ALERT_EMAIL  # 发送邮件（需提前配置mail命令）
 else
     echo "[$(date +'%Y-%m-%d %H:%M:%S')] Nginx运行正常，PID：$nginx_pid"
 fi

通过差异对比，能清晰看到新增了"邮件配置""告警逻辑"等内容，这在运维中排查问题时非常重要。

4. 版本回滚：当新版本出问题时如何恢复

假设v2.0的邮件功能有bug（比如邮件发送失败导致脚本报错），需要暂时回滚到v1.0版本：

bash 复制代码

# 回滚到指定版本（版本ID是v1.0的a1b2c3d）
# --hard表示"强制覆盖工作区和暂存区"，直接回到目标版本的状态
git reset --hard a1b2c3d

执行后，工作区的nginx_monitor.sh会自动变回v1.0的内容（没有邮件告警部分）。

注意：git reset --hard是"危险操作"，会丢弃当前工作区的所有未提交修改，使用前确保不需要保留这些修改。如果只是想"查看旧版本内容"而不覆盖当前文件，可用git checkout 版本ID 文件名（如git checkout a1b2c3d nginx_monitor.sh）。

五、多人协作基础：运维团队如何共同管理脚本

在实际运维中，一个脚本可能由多人维护（比如A负责监控逻辑，B负责告警优化）。Git的分支功能可以解决"多人同时修改同一文件"的冲突问题。

1. 分支的概念：为什么需要分支？

想象一个场景：你正在基于v2.0开发"短信告警"功能（v3.0），但此时生产环境的v2.0突然发现bug需要紧急修复。如果直接在主分支修改，会导致"未完成的v3.0代码"和"紧急修复代码"混在一起，风险极高。

分支就是为解决这个问题而生：主分支（master或main）保持"可运行的稳定版本"，每个人在自己的分支开发，完成后再合并到主分支。

2. 分支操作实战：新增"短信告警"功能

bash 复制代码

# 1. 查看当前分支（默认在master分支）
git branch  # 输出：* master（*表示当前所在分支）

# 2. 创建并切换到"sms_alert"分支（专门开发短信告警功能）
git checkout -b sms_alert  # 相当于git branch sms_alert + git checkout sms_alert

# 3. 在新分支修改脚本，添加短信告警（假设用阿里云SMS API，这里简化）
vim nginx_monitor.sh

修改后的内容（新增短信部分）：

bash 复制代码

#!/bin/bash
# 功能：监控Nginx进程，支持邮件和短信告警
# 作者：你的名字
# 日期：2025-10-22
# 版本：v3.0（新增短信告警）

# 配置参数
ALERT_EMAIL="admin@example.com"
ALERT_PHONE="13800138000"  # 告警手机号

# 检查Nginx进程
nginx_pid=$(pgrep nginx)

if [ -z "$nginx_pid" ]; then
    msg="[$(date +'%Y-%m-%d %H:%M:%S')] 警告：Nginx进程未运行！"
    echo "$msg"
    echo "$msg" | mail -s "Nginx监控告警" $ALERT_EMAIL  # 邮件告警
    # 短信告警（实际需调用API，这里仅模拟）
    echo "发送短信到$ALERT_PHONE：$msg"
else
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] Nginx运行正常，PID：$nginx_pid"
fi

bash 复制代码

# 4. 提交分支修改
git add nginx_monitor.sh
git commit -m "v3.0: 新增短信告警功能，支持向13800138000发送告警"

# 5. 切换回master分支（准备合并）
git checkout master

# 6. 合并sms_alert分支到master（将短信告警功能合并到主分支）
git merge sms_alert -m "合并v3.0：新增短信告警功能"

如果合并时出现冲突（比如多人同时修改了同一行代码），Git会提示Automatic merge failed，此时需要手动编辑冲突文件（文件中会用<<<<<<<标记冲突区域），解决后再git add和git commit完成合并。

六、总结：Git在运维与教学中的核心价值

对运维工作：

版本追踪：任何脚本/配置的修改都有记录，出问题时可快速定位"谁在何时改了什么"。
风险控制：通过分支隔离开发与生产，避免未完成的代码影响线上环境；通过回滚功能快速修复错误。
协作效率：多人可并行开发，通过合并功能整合代码，解决冲突。

对教学场景（结合你的需求）：

学生提交的脚本不再是"最终版本"，而是包含git log记录的"完整开发轨迹"，可通过提交次数（至少3-5次）、时间间隔（符合正常编写节奏）、注释详情（具体到每步功能）判断是否"真实编写"，而非从截图提取后一次性提交。
强制学生用git diff查看自己的修改，能加深对"代码变更"的理解，培养良好的开发习惯。

通过以上内容，你应该已经掌握了Git的核心操作及在运维场景中的应用。记住：Git的本质是"记录变更"，而运维的核心是"控制变更风险"，两者结合能极大提升脚本管理的可靠性。