CICD（一）CI/CD概述及GitLab部署和一些Git命令

---

前言

一、CICD是什么

CICD 是 持续集成（Continuous Integration） 和 持续部署（Continuous Deployment） 的缩写，是一套自动化软件开发流程的实践方法：

• 持续集成（CI）：开发团队频繁将代码合并到共享仓库（如Git），每次合并后自动触发构建、测试（单元测试、集成测试等），快速发现并解决代码冲突或错误。
• 持续部署（CD）：通过自动化流程将通过测试的代码部署到生产环境或预生产环境，减少人工操作，实现快速、可靠的发布。

二、 为什么要使用CICD

• 减少人工错误：传统手动部署依赖人工操作，易因疏忽导致配置错误或步骤遗漏，CICD通过自动化消除人为干预。
• 加速开发迭代：频繁集成代码可及早发现问题，避免开发后期出现难以解决的冲突；自动化部署缩短从开发到上线的周期。
• 提高代码质量：每次提交自动触发测试，确保代码符合质量标准，减少生产环境bug。
• 增强团队协作：强制团队成员频繁同步代码，促进协作，避免“孤岛开发”导致的整合难题。

三、 CICD的作用

• 自动化流程：将代码提交、构建、测试、部署等环节自动化，减少重复劳动。
• 快速反馈：代码提交后立即反馈构建或测试结果，帮助开发者快速定位问题。
• 风险控制：通过自动化测试和分阶段部署（如先部署到测试环境），降低直接发布到生产环境的风险。
• 一致性保障：确保开发、测试、生产环境的配置和流程一致，避免“在我电脑上能运行”的问题。

四、 CICD的三大使用场景

在传统环境、容器环境和K8s环境中，CICD的核心目标（自动化集成、测试、部署）一致，但实现方式、工具链和复杂度存在显著差异，主要体现在环境一致性、部署效率和扩展性上。

• 传统环境：依赖手动配置，CICD聚焦“脚本自动化”，适合简单场景。
• 容器环境：以镜像为核心，解决环境一致性，CICD聚焦“镜像生命周期管理”，适合中小规模应用。
• K8s环境：基于容器和编排平台，CICD与K8s深度集成，支持声明式部署和大规模集群，适合复杂微服务架构。
  随着系统复杂度提升，CICD从“工具链拼接”向“平台化、云原生”演进，核心驱动力是降低环境差异、提升部署效率和可靠性。

1. 传统环境中的CICD

传统环境通常基于物理机或虚拟机（VM），依赖手动配置的操作系统、中间件和依赖库，CICD实践面临较多限制：

• 特点：

  • 环境差异大：开发、测试、生产环境依赖手动维护，易出现“配置漂移”（如不同环境的软件版本不一致）。
  • 部署流程重：部署需手动登录服务器执行脚本（如scp传包、systemctl启动服务），或依赖简单的自动化工具（如Ansible、Jenkins Pipeline调用Shell命令）。
  • 扩展性差：新增节点需手动配置环境，难以快速扩容。

• 典型工具链：

  • 代码管理：Git/SVN
  • 构建工具：Maven/Gradle（Java）、Make（C/C++）
  • 自动化服务器：Jenkins（核心）
  • 部署工具：Ansible（批量执行命令）、Shell脚本
  • 测试工具：Junit、Selenium

• 优势与局限：

  • 优势：适合简单应用（如单体服务），初期搭建成本低。
  • 局限：环境一致性差、部署效率低、难以支持高频发布，人工干预环节多。

2. 容器环境中的CICD

容器环境（如Docker）通过镜像封装应用及依赖，解决了传统环境的“环境一致性”问题，CICD流程更聚焦于镜像生命周期管理：

• 特点：

  • 环境标准化：应用及其依赖（如Python版本、库文件）被打包成镜像，确保开发到生产环境一致（“一次构建，到处运行”）。
  • 部署轻量化工：部署流程简化为“拉取镜像→启动容器”，可通过脚本或工具自动化。
  • 镜像为核心：CICD流程新增“构建镜像”“推送镜像到仓库（如Docker Hub、Harbor）”环节。

• 典型工具链：

  • 在传统工具链基础上新增：
    • 镜像构建：Dockerfile、Buildah
    • 镜像仓库：Docker Hub、Harbor、阿里云容器镜像服务
    • 容器管理：Docker Compose（单机多容器编排）

• 流程示例：

  1. 开发者提交代码到Git仓库；
  2. Jenkins触发自动构建：编译代码→运行测试→通过Dockerfile构建镜像；
  3. 镜像推送到私有仓库；
  4. 部署脚本从仓库拉取镜像，在目标服务器上启动容器。

• 优势与局限：

  • 优势：环境一致性大幅提升，部署速度加快，适合中小规模应用（如微服务初期）。
  • 局限：多容器协调、跨主机部署需手动管理，难以应对大规模集群。

3. K8s环境中的CICD

Kubernetes（K8s）是容器编排平台，提供自动扩缩容、自愈、滚动更新等能力，CICD流程与K8s的API深度集成，实现全链路自动化：

• 特点：

  • 声明式部署：通过K8s资源清单（YAML/JSON）定义应用状态（如Deployment、Service），CICD工具直接调用K8s API提交清单，由K8s自动维护状态。
  • 自动化运维能力：结合K8s的滚动更新、灰度发布（如Canary）、回滚功能，部署风险更低。
  • 集群级扩展：支持跨节点、跨集群部署，可通过CICD自动扩缩容应对流量变化。

• 典型工具链：

  • 基础工具：Git、Jenkins/GitLab CI、Docker
  • K8s专属工具：
    • 镜像扫描：Trivy（检查镜像漏洞）
    • 清单管理：Kustomize、Helm（打包YAML清单，支持多环境配置）
    • 高级CI/CD平台：ArgoCD（GitOps模式）、Tekton（云原生Pipeline）

• 流程示例（GitOps模式）：

  1. 开发者提交代码到业务代码仓库，同时提交K8s部署清单到配置仓库（如Git）；
  2. CI工具（如GitLab CI）自动构建镜像→测试→推送到仓库→更新配置仓库中的镜像版本；
  3. ArgoCD监控配置仓库变化，自动同步到K8s集群，触发滚动更新；
  4. K8s自动完成新容器启动、旧容器销毁，确保服务不中断。

• 优势与局限：

  • 优势：全自动化程度最高，支持大规模集群和复杂微服务架构，部署可靠性和可观测性强。
  • 局限：学习成本高，需掌握K8s概念（如Pod、Deployment）和GitOps理念，适合中大型团队或复杂系统。

-------------------------------------------------------------------------------------------------------------------

一、使用Docker部署本地GitLab服务

GitLab是企业级的代码管理与协作平台，通过Docker部署可大幅简化环境配置流程，实现快速搭建与迁移。本文将从Docker安装、GitLab镜像拉取、容器启动，到GitLab访问与项目管理，完整呈现本地GitLab服务的部署与使用流程。

1.1 安装Docker

GitLab运行依赖Docker环境，需先在CentOS系统中安装Docker并配置镜像加速，确保后续镜像拉取与容器运行高效稳定。

1.1.1 前置要求

虚拟机需分配至少4GB内存，否则GitLab运行时可能因资源不足出现卡顿或崩溃。

1.1.2 执行Docker安装命令

通过YUM包管理器安装Docker及其依赖组件，命令如下：

# 安装Docker依赖工具
yum install -y yum-utils device-mapper-persistent-data lvm2 
# 添加阿里云Docker YUM仓库（国内仓库，拉取速度更快）
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 
# 安装Docker核心组件
yum install -y docker-ce docker-ce-cli containerd.io

1.1.3 配置Docker镜像加速

Docker默认从国外仓库拉取镜像，速度较慢，需配置国内镜像源加速。文档中提供了3个镜像源，此处整合为通用配置（优先推荐阿里云/华为云，稳定性更高）：

# 创建Docker配置目录
mkdir /etc/docker
# 写入镜像加速配置（整合国内主流源，避免单个源失效）
cat > /etc/docker/daemon.json <<EOF
{"registry-mirrors": ["https://0a40cefd360026b40f39c00627fa6f20.mirror.swr.myhuaweicloud.com","https://6ijb8ubo.mirror.aliyuncs.com"],"exec-opts": ["native.cgroupdriver=systemd"],  # 适配系统CGroup驱动，避免容器启动警告"log-driver": "json-file",  # 日志存储格式"log-opts": {"max-size": "100m"  # 单个日志文件最大100MB，避免磁盘占满}
}
EOF

1.1.4 启动并设置Docker开机自启

# 重新加载系统服务配置
systemctl daemon-reload
# 重启Docker服务
systemctl restart docker.service
# 设置Docker开机自启
systemctl enable docker.service

1.2 拉取GitLab Docker镜像

选择带中文支持的GitLab社区版镜像，降低使用门槛，同时需解决端口冲突问题。

1.2.1 拉取中文社区版镜像

推荐使用维护活跃的twang2218/gitlab-ce-zh镜像，该镜像基于官方GitLab社区版（ce）优化，内置中文语言包：

docker pull twang2218/gitlab-ce-zh

• docker pull：从远程Docker仓库拉取镜像到本地的命令。
• twang2218/gitlab-ce-zh：镜像标识，其中twang2218是镜像维护者，gitlab-ce-zh表示“GitLab社区版-中文”。
• 标签说明：未指定标签时，默认拉取latest（最新稳定版）；如需固定版本，可添加标签（如twang2218/gitlab-ce-zh:16.0.0），避免版本更新导致兼容性问题。

1.2.2 解决端口冲突（关键步骤）

GitLab容器默认使用22端口（SSH协议），而主机SSH服务默认也使用22端口，会导致冲突。需修改主机SSH服务端口：

1. 编辑SSH配置文件：

   vim /etc/ssh/sshd_config
   

2. 找到Port 22行，修改为：

   Port 2222  # 端口可自定义（如2222、2022），需确保未被其他服务占用
   

3. 重启SSH服务使配置生效：

   systemctl restart sshd
   

注意：修改SSH端口后，后续通过SSH连接主机时，需指定新端口（如ssh root@服务器IP -p 2222），避免连接失败。

1.3 启动GitLab容器

通过docker run命令启动容器，并挂载本地目录保存GitLab配置、日志和数据，确保容器销毁后数据不丢失。

1.3.1 执行启动命令

文档中提供了3个类似命令，此处整合为标准命令（使用中文镜像，明确挂载路径）：

docker run -d \-h gitlab \                        # 指定容器内主机名（方便识别）-p 443:443 -p 80:80 -p 22:22 \     # 端口映射：主机端口:容器端口（443=HTTPS，80=HTTP，22=SSH）--name gitlab \                    # 容器名称（自定义，方便后续操作）--restart always \                 # 容器退出后自动重启（确保服务稳定性）-v /srv/gitlab/config:/etc/gitlab \# 挂载配置目录：主机目录:容器目录-v /srv/gitlab/logs:/var/log/gitlab \# 挂载日志目录-v /srv/gitlab/data:/var/opt/gitlab \# 挂载数据目录（核心，保存代码与用户数据）twang2218/gitlab-ce-zh:latest      # 使用的镜像（中文社区版最新版）

1.3.2 检查容器启动状态

GitLab启动需加载大量组件（如数据库、Redis、Web服务），需等待3-5分钟，通过以下命令确认状态：

docker ps -a

当输出中STATUS列显示为Up X minutes (healthy)时，代表GitLab已正常启动，示例如下：

CONTAINER ID   IMAGE                           COMMAND             CREATED         STATUS                   PORTS                                                                                                         NAMES
b6cde725f2c3   twang2218/gitlab-ce-zh:latest   "/assets/wrapper"   2 minutes ago   Up 2 minutes (healthy)   0.0.0.0:22->22/tcp, :::22->22/tcp, 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   gitlab

1.4 访问GitLab

通过浏览器访问GitLab Web界面，完成初始化配置后即可进入管理与使用环节。

需要等待一会儿，等GitLab加载完成后再访问页面

1.4.1 首次访问与密码设置

1. 打开浏览器，输入http://服务器IP地址（无需加端口，默认使用80端口）。
2. 首次访问会提示设置管理员账号（root）的密码，建议设置复杂密码（如GitLab@123），避免被暴力破解。

1.4.2 核心概念说明

GitLab的权限与项目管理基于以下3个核心概念，需先理解再操作：

• 群组（Group）：对应团队或部门（如“开发部”“DevOps组”），用于统一管理多个项目和成员权限。
• 项目（Project）：对应单个软件项目（如“myweb网站”“用户管理系统”），是代码存储与协作的基本单元。
• 成员（Member）：对应用户账号，通过加入群组或项目获得权限，避免单个用户直接管理所有资源。

1.5 配置GitLab（创建组、用户与项目）

以创建“devops组”“aike用户”“myweb项目”为例，演示GitLab的基础配置流程，实现权限的合理分配。

1.5.1 创建“devops”群组

1. 登录root账号后，点击页面顶部导航栏的【新建群组】。
2. 填写群组信息：
   • 【群组名称】：devops
   • 【群组路径】：devops（URL中显示的路径，需与名称一致）
   • 【描述】：DevOps团队专用群组
   • 【可见等级】：选择“公开”（测试环境用，生产环境建议选“私有”）。
3. 点击【创建群组】，完成群组创建。
   

1.5.2 创建“aike”用户

1. 点击页面顶部导航栏的【扳手图标】（管理区域），进入“用户”页面。
2. 点击【新建用户】，填写用户信息：
   • 【姓名】：aike
   • 【用户名】：aike（登录时使用的账号）
   • 【电子邮箱】：[e-mail]（用于密码重置与通知，测试环境可填虚构邮箱）。
3. 暂不设置密码，点击【创建用户】。
4. 创建后点击用户右侧的【编辑】，设置密码（如aike@1234），并保存。
   

1.5.3 创建“myweb”项目

1. 进入“管理区域”，点击【新建项目】。
2. 填写项目信息：
   • 【项目名称】：myweb
   • 【项目路径】：选择“devops”群组（将项目归属于devops组）
   • 【描述】：myweb网站项目
   • 【可见等级】：选择“公开”（测试环境用）。
3. 点击【创建项目】，完成项目创建。
   

1.5.4 给“aike”用户分配权限

有两种分配方式，推荐“群组添加”（一次添加，可访问群组内所有项目），也可“项目单独添加”（仅访问单个项目）：

方式1：通过群组添加（推荐）

1. 进入“devops”群组，点击左侧菜单【成员】。
2. 【添加成员】中搜索“aike”，【选择角色权限】选择“主程序员”（可提交代码、管理分支，适合开发人员）。
3. 点击【添加到群组】，完成权限分配。
   
   

方式2：通过项目添加（单独授权）

1. 进入“myweb”项目，点击左侧菜单【设置】→【成员】。
2. 【添加成员】中搜索“aike”，【选择角色权限】选择“主程序员”。
3. 点击【添加到项目】，完成权限分配。

1.6 使用“aike”用户管理代码

切换到“aike”用户，通过Git命令将本地代码推送到GitLab的“myweb”项目，实现代码的版本控制。

1.6.1 首次登录“aike”用户

1. 退出root账号，使用aike账号（用户名：aike，密码：aike@1234）重新登录。
2. 首次登录会强制要求修改密码，可修改为aike@root123（也可与原密码一致，点击确认即可）。

1.6.2 场景1：本地无Git仓库（全新项目）

若本地未创建过“myweb”项目，需先克隆远程仓库，再添加代码并推送：

1. 克隆远程仓库到本地/opt目录：

   cd /opt
   git clone http://服务器IP地址/devops/myweb.git  # 克隆devops组下的myweb项目
   

2. 进入项目目录，创建并提交README.md文件（项目说明文件）：

   cd myweb  # 进入克隆后的项目目录
   touch README.md  # 创建空的README.md文件
   git add README.md  # 将文件添加到Git暂存区（准备提交）
   git config --global user.name "aike" #第一次上传到仓库前需要先配置
   git config --global user.email "[e-mail]"
   git commit -m "add README.md (项目说明文件)"  # 提交到本地仓库，添加提交备注
   

3. 将本地代码推送到远程仓库：

   git push -u origin master  # 推送到远程master分支（-u设置默认上游分支，后续可直接用git push）
   

   

4. 推送时会提示输入GitLab账号（aike）和密码（aike@root123），输入后即可完成推送。

1.6.3 场景2：本地已有Git仓库（迁移项目）

若本地已存在“myweb”项目，需关联远程仓库并推送代码，支持HTTP协议（需输密码）和SSH协议（免密，推荐）。

子场景2.1：HTTP协议推送（简单，适合测试）

1. 进入本地项目目录：

   cd ~/myweb  # 本地项目所在路径
   

2. 关联远程仓库（GitLab的myweb项目）：

   git remote add origin http://服务器IP地址/devops/myweb.git  # 添加远程仓库，别名设为origin
   git remote  # 验证是否添加成功，输出“origin”即正常
   

   

3. 推送本地代码和标签（Tag）到远程：

   git push -u origin --all  # 推送所有分支的代码（首次推送需加--all）
   git push -u origin --tags  # 推送本地所有Tag（版本标记，如v1.0）
   

   

4. 输入aike账号和密码，完成推送后刷新GitLab页面，即可看到本地代码。
   

子场景2.2：SSH协议推送（免密，适合生产）

HTTP协议每次推送需输密码，SSH协议通过密钥对实现免密，步骤如下：

1. 本地生成SSH密钥对（一路回车，无需设置密码）：

   ssh-keygen -t rsa -C "[e-mail]" -b 4096  # 生成4096位RSA密钥，备注邮箱
   

2. 查看并复制公钥（id_rsa.pub）内容：

   cat ~/.ssh/id_rsa.pub  # 输出公钥，复制所有内容（从ssh-rsa开始到邮箱结束）
   

3. GitLab中添加公钥：

   • 登录aike账号，点击右上角【用户头像】→【设置】→【SSH密钥】。
   • 【密钥】文本框粘贴复制的公钥，【标题】填kgc-local（自定义，标识密钥来源）。
   • 点击【增加密钥】，完成添加。
     

4. 本地关联SSH协议的远程仓库：

   # 先删除原有的HTTP协议远程仓库（若已添加）
   git remote remove origin
   # 添加SSH协议的远程仓库（格式：git@服务器IP:群组/项目.git）
   git remote add origin git@服务器IP地址:devops/myweb.git
   # 验证远程仓库信息
   git remote show origin  # 输出中URL为“git@xxx”即正常
   

   

5. 测试免密推送：

   # 新增一个测试文件，模拟代码修改
   echo '<h3>new line</h3>' >> index.html
   # 提交修改
   git add .  # 将所有修改添加到暂存区
   git commit -m "modify index.html: add new line"  # 提交到本地仓库
   # 推送代码（无需输密码）
   git push
   git push --tags  # 推送Tag（若有）
   

   

二、Git 应用

2.1 Git 的概述

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Git 与常用的版本控制工具 CVS, SVN 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。
程序员在自己的电脑上编写代码，并通过 git 管理。

2.1.1 git 和 svn 的区别

Git 和 SVN（Subversion） 是两种常见的版本控制系统，它们在使用方式、架构和功能上有显著差异。以下是它们的主要区别：

2.1.1.1 分布式 vs. 集中式

• Git：分布式版本控制系统。

  • 每个开发者的本地仓库都包含了项目的完整历史记录和完整的版本库。
  • 可以在本地进行提交、查看日志等操作，不依赖于远程服务器。
  • 即使没有网络连接，开发者也可以继续工作。

• SVN：集中式版本控制系统。

  • 所有版本历史记录都存储在中央服务器中，开发者的本地仓库通常只有当前的工作副本。
  • 需要与中央服务器连接才能提交、获取历史记录等。
  • 如果服务器不可用，则无法进行大部分操作。

2.1.1.2 性能和存储

• Git：

  • 提交速度快，因为大部分操作在本地完成。
  • 存储使用效率高，通过压缩方式存储历史记录。
  • 支持增量式存储，只存储差异，提高效率。

• SVN：

  • 提交速度较慢，依赖中央服务器。
  • 每次更新都会传输大量数据，占用更多的网络带宽。

2.1.1.3 分支管理

• Git：

  • 分支是轻量级的，创建和切换分支非常快速。
  • 每个分支都可以独立开发，不会影响其他分支。
  • 分支操作本地完成，直到需要合并时才与远程同步。

• SVN：

  • 分支是通过复制整个目录实现的，较重，效率低。
  • 分支管理复杂，容易导致合并冲突。

2.1.1.4 工作方式

• Git：

  • 提交（commit）和推送（push）是分开的。
    • 提交将更改保存到本地版本库。
    • 推送将更改同步到远程仓库。
  • 支持离线工作，本地修改后可以稍后再同步到服务器。

• SVN：

  • 提交（commit）直接将更改保存到中央服务器。
  • 必须联网才能提交和获取最新版本。

2.1.1.5 操作复杂度

• Git：

  • 功能强大，但对初学者来说复杂度较高。
  • 需要理解分布式工作流、分支管理等概念。
  • 常用命令较多（如 add、commit、push、pull、merge 等）。

• SVN：

  • 简单易用，特别是对于小团队或简单的项目。
  • 工作流清晰，提交即上传到服务器。

2.1.1.6 支持的平台

• Git：

  • 跨平台使用广泛，特别适合开源社区和分布式团队。
  • 与 GitHub、GitLab、Bitbucket 等平台集成良好。
  • 非常适合大规模开发和复杂的代码协作。

• SVN：

  • 多用于企业内部项目，适合集中式管理。
  • 与一些老旧的企业工具集成较好。

2.1.1.7 安全性

• Git：

  • 本地仓库保留了完整的历史记录，中央服务器崩溃不会丢失数据。
  • SHA-1 哈希算法保证了数据的完整性。

• SVN：

  • 如果中央服务器崩溃，可能导致数据丢失。
  • 需要定期备份服务器数据。

2.1.1.8 学习曲线

• Git：

  • 学习曲线较陡，需要熟悉分布式工作流和复杂命令。
  • 适合经验丰富的开发者和复杂的协作场景。

• SVN：

  • 学习曲线平缓，操作直观。
  • 适合小团队和简单项目。

2.1.1.9 适用场景总结

特性	Git	SVN
开发团队规模	大规模分布式团队、开源项目	小团队或集中管理项目
网络依赖	本地操作不依赖网络	高度依赖网络
分支操作	高效、轻量	复杂、低效
学习成本	高（适合专业开发者）	低（适合初学者）
适合项目类型	大型复杂项目	小型简单项目
容灾能力	高（本地备份完整历史）	低（需依赖服务器备份）

2.1.1.10 小结

• Git：适合现代软件开发的大部分场景，尤其是需要灵活分支管理和分布式协作的大型团队。
• SVN：适合简单项目和对分布式版本控制需求不高的小型团队或企业。

2.2 Git 安装

#Git 安装
yum -y install git
git --version#git安装后需配置用户相关信息
#配置个人的用户名称和电子邮箱
git config --global user.name "aike"
git config --global user.email "[e-mail]"#设置Git默认使用的文本编辑器, 一般可能会是 vi 或者 vim
git config --global core.editor vim#查看已有的配置信息
git config --list#如果使用 --global 选项，那么配置的用户信息会保存在当前用户家目录下的 .gitconfig 文件里， 以后所有的项目都会默认使用此用户信息。
cat ~/.gitconfig#如果要在某个特定的项目中使用其他名字或者电子邮箱，只要去掉 --global 选项重新配置即可，新的设定将会保存在当前项目的 .git/config 文件里。

2.3 Git 主要的工作区域

• 工作区（Working Directory）：代码目录，就是你在电脑里能看到的目录。

  这是你的 桌面，上面放着论文的初稿、各种资料文件（你看到的实际文件）。你可以随时修改这些文件，比如用 Word 或者 Markdown 写论文。这是你日常操作的地方。

• 暂存区（Stage/Index）：工作区和版本库之间的缓存区域，一般存放在 .git 目录下的 index 文件（.git/index）中，英文叫 stage 或 index。

  这是你文件夹中的“待提交清单”，你把一些修改好的论文部分（比如标题页和目录）挑选出来，放进了这个清单中，表示这些部分已经准备好提交给导师了，但还没正式提交。
  它起到一个过渡作用，帮你确认哪些东西要提交，哪些还需要再修改。

• 版本库（Repository）：工作区有一个隐藏目录 .git，这个不算工作区，而是 git 的版本库。

  这是你的 文件柜，放的是你已经定稿并提交的论文（正式的版本）。一旦你觉得某个部分没问题了，就把它“归档”进这个文件柜里，方便以后查阅。如果你不小心修改得一团糟，还可以从文件柜里取出之前的版本进行恢复

工作区：你的桌面，随时可以编辑、添加、删除文件。

暂存区：你的待提交清单，准备好哪些东西需要提交。

版本库：你的文件柜，存放历史版本，供日后查阅或恢复。

2.4 创建版本库

#方法一：在编写代码之前创建工程
git init mypro
初始化空的 Git 版本库于 /root/mypro/.git/ls -A /root/mypro/.git

##方法二：对已有文件的目录进行初始化
mkdir /root/myweb
cd !$ #用于切换到上一条命令中最后一个参数所指定的目录
echo '<h1>this is my web</h1>' > index.htmlgit init
初始化空的 Git 版本库于 /root/myweb/.git/ls -A

2.5 查看 git 状态

git status

git status -s
?? index.htmlgit status -s 的输出是两列：左侧列：表示文件在 暂存区 的状态。右侧列：表示文件在 工作区 的状态。文件的状态代码如下：??：文件是 未跟踪（Untracked）的。A：文件已 新增到暂存区（Added）。M：文件被 修改过（Modified）。D：文件被 删除（Deleted）

2.6 将目录下所有文件都添加到暂存区，只有当暂存区有文件才能 commit

git add .git status -s

git status

2.7 删除暂存区的文件，相当于撤销刚才的 add 操作

git rm --cached index.htmlgit status -s		#此时文件变成未知状态
git add index.html   或  git add .

2.8 commit 提交到版本库

git commit -m "init"git status			#此时工作区为空
# 位于分支 master
无文件要提交，干净的工作区

2.9 查看版本库文件

git ls-files #主要用途是列出当前工作区中被 Git 跟踪的文件（即已纳入版本控制的文件）

2.10 将文件从暂存区和本地一起删除

git rm index.html
rm 'index.html'
ls         #此时目录中 index.html 没有了
git status     #现在的状态是代码库没有了但是暂存区还有

2.11 commit 提交到版本库，彻底删除

git commit -m "rm index.html"
git status

2.12 查看提交记录

git log

2.13 返回到 init 提交时的状态

git checkout 297d96a3f31666af4888478a223e0bbad82f07d4ls		#此时之前删除的 index.html 恢复回来了

2.14 返回到最新的 master 状态

git checkout masterls     #此时 index.html 没有了

2.15 在暂存区恢复已删除的文件

git checkout masterls     #此时 index.html 没有了#在暂存区恢复已删除的文件
cp /etc/passwd /etc/shadow /etc/hosts ./ls
hosts  passwd  shadow
git add .
git status -s

rm -rf *
git status -s
git status

在 Git 中，git checkout -- * 和 git checkout -- . 都用于丢弃工作区中未暂存的修改，但它们在处理文件的范围上有细微区别：

• git checkout -- .
  • 表示丢弃当前目录（包括所有子目录）中所有未暂存的修改
  • 会递归处理当前目录下的所有文件和子文件夹
• git checkout -- *
  • 同样会处理当前目录及子目录的文件，但受 shell 通配符扩展规则影响
  • 在某些 shell 环境中，* 不会匹配以点（.）开头的隐藏文件（如 .gitignore、.env 等）
  • 可能会受到 shell 设置的影响，行为略有差异

简单来说，git checkout -- . 更可靠，能确保包括隐藏文件在内的所有文件都被处理，而 git checkout -- * 可能会遗漏隐藏文件。在大多数情况下，推荐使用 git checkout -- . 来确保一致性。

如果使用的是 Git 2.23+ 版本，更推荐使用 git restore . 或 git restore -- . 命令，这是 Git 引入的新命令，专门用于恢复工作区文件，语义更清晰。

git checkout -- .
ls

2.15.1 注意事项

1. 不可恢复性：

   • 如果文件已经修改，执行这些命令后将直接丢失修改，无法恢复。
   • 如果文件新增但未进入版本库，也会被删除。

2. 版本库状态：

   • 如果文件已经 git add 但未提交，git checkout -- 会恢复到暂存区状态。

2.16 Git命令速查表

操作需求	命令	说明
查看状态	git status/git status -s	显示文件在工作区、暂存区的状态，-s为简洁模式
添加到暂存区	git add .	将当前目录所有文件添加到暂存区
撤销暂存	git rm --cached 文件名	仅从暂存区删除，保留工作区文件
提交到版本库	git commit -m "备注"	备注需清晰描述提交内容，如“add README.md”
查看跟踪文件	git ls-files	列出已纳入版本控制的文件
彻底删除文件	git rm 文件名+git commit	从工作区和版本库同时删除，需提交确认
查看提交记录	git log	显示所有提交历史，含哈希值、作者、时间、备注
版本回滚/切换	git checkout 哈希值/git checkout master	回滚到指定版本（用log中的哈希值），或切回最新master
恢复工作区文件	git checkout -- .	丢弃工作区未暂存的修改，优先于git checkout -- *（避免遗漏隐藏文件）

总结

本文先解析 CI/CD 的定义、价值及传统 / 容器 / K8s 三种环境下的应用差异，再以 CentOS 系统为例，分步讲解 Docker 安装配置、GitLab 中文镜像部署（含端口冲突解决、数据挂载）、群组 / 用户 / 项目创建与权限分配，以及本地代码通过 HTTP/SSH 协议推送到 GitLab 的操作，最后阐述 Git 与 SVN 的区别、Git 安装配置，围绕 “工作区 - 暂存区 - 版本库” 流程详解版本控制实操命令，形成从理论到工具部署再到代码管理的完整 DevOps 入门内容。