Git、GitHub Actions、Shell 与 Docker：从本地开发到 CI/CD 和容器化

这组工具解决的是工程落地问题：代码怎么协作、怎么自动测试、怎么打包运行、怎么保证环境一致。

Git 工作流

常用命令：

git status
git add .
git commit -m "feat: add login"
git pull
git push
git checkout -b feature/login

常见概念：

merge：保留分支合并历史
rebase：把提交“搬到”新基底上，历史更线性
reset：移动当前分支指针，可能改工作区
revert：新增一个反向提交，更适合公共分支

GitHub Actions

workflow 由触发条件和 jobs 组成。

name: CI
 
on:
  push:
  pull_request:
  workflow_dispatch:
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

常见触发：

push
pull_request
schedule
workflow_dispatch

Git Hooks

Git Hooks 是本地钩子，可以在 commit、push 等动作前后执行脚本。

常见用途：

commit 前格式化
commit 前 lint
push 前测试
校验 commit message

Shell 管道和重定向

cat app.log | grep ERROR

管道把左边命令输出交给右边命令。

node script.js > output.txt
node script.js >> output.txt

> 覆盖写入，>> 追加写入。

Docker 核心概念

Image 是镜像，Container 是镜像运行后的实例。

Dockerfile 描述如何构建镜像。

Volume 用于持久化数据。

Network 用于容器通信。

Dockerfile

FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["npm", "run", "start"]

先复制依赖声明再安装依赖，是为了利用 Docker build cache。

docker-compose

docker-compose 用于同时启动多个服务。

services:
  web:
    build: .
    ports:
      - "3000:3000"
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
 
volumes:
  db-data:

它适合本地开发、集成测试和小型部署。

延伸理解

复习这篇时，不要只记住名词，要把重点放在 Git 工作流、CI、Git hooks、Shell 管道、Dockerfile 和 Compose 的工程化组合。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。

DevOps 的价值是缩短反馈周期，同时降低发布风险；工具链只是手段。
CI/CD 要覆盖构建、测试、静态检查、镜像构建、部署和回滚，而不是只有自动运行命令。
脚本、Docker、GitHub Actions 应该可重复、可审计、可在本地或 CI 环境稳定运行。

在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。

实践检查清单

明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
最后用一句话总结取舍：它牺牲了什么，换来了什么。

自测问题

这个主题解决的核心问题是什么？
如果不用当前方案，还有哪些替代方案？代价是什么？
最容易出错的边界条件在哪里？
如何在代码、测试或监控中验证它真的可靠？

项目化应用场景

可以把这类知识放到一个从提交代码到上线的流水线里理解：开发者 push 代码，GitHub Actions 安装依赖、运行 lint、测试、构建镜像，然后推送到部署环境。Dockerfile 保证运行环境一致，docker-compose 帮助本地启动依赖服务，Shell 脚本处理重复命令。好的 DevOps 流程应该让错误尽早暴露，并让回滚和排查有依据。

常见误区：

CI 只跑 build，不跑测试和静态检查。
本地环境和线上环境差异过大。
脚本没有失败退出，导致错误被吞掉。

目录