D6 Git + GitHub

精讲（必讲）。这是全员从 D1 起就在用的"协作基础设施"。学完能安全提交代码、发起 PR，并理解公司 CI/CD 是怎么被 git tag 触发的。

教学目标（学完能做什么）

熟练完成 Git 基本操作：clone / add / commit / push / pull / branch / merge，能解决常见冲突
能走通 GitHub 协作流程：建分支 → 提交 → 发起 PR → 代码评审 → 合入
知道公司仓库结构与提交规范（中文提交信息、只推该推的）
能解释公司 CI/CD 触发机制：git tag <app>-vX.Y.Z && git push → GitHub Actions → 自建 runner → 构建镜像 → 部署 k3s
知道 Git 事故处理（误提交/误删怎么救）

前置要求

D1（已 clone 过仓库）、D5（命令行操作）

本模块在业务中的位置

公司代码托管在 GitHub（主仓 ChangUoo-insight/insightful-ops）。发版完全由 git tag 驱动（见 CLAUDE.md CI/CD 一节），所以"会 Git/GitHub"不是可选技能，是每天吃饭的本事。D16 用 Claude Code 干活、第 4 周团队项目，全程都在这套协作流程里。

内容分段

1. Git 是什么、本地工作流

分布式版本控制：每个开发者本地都有一份完整历史。
三个区域：工作区 → 暂存区(index) → 本地仓库(HEAD)。

git status                 # 看状态（最高频命令）
git add <file>             # 工作区 → 暂存区
git commit -m "D6 作业：...（姓名）"   # 暂存区 → 本地仓库，中文信息
git log --oneline -10      # 看提交历史
git diff                   # 看未暂存改动

2. 远程协作

git remote -v                              # 看远程地址
git clone git@github.com:ChangUoo-insight/insightful-ops.git
git pull origin main                       # 拉最新
git push origin <分支名>                    # 推分支

开发流程（公司实践）：每次改动走"新分支 → 提交 → PR"：
1. git switch -c feat/你的名字-描述（建分支）
2. 在分支上提交（多次）
3. git push origin feat/xxx（推分支）
4. GitHub 上发起 PR，等评审
5. 合入后切回 main 并 pull

3. 分支与合并、冲突

分支 = 可移动的指针；main 是主干，feature 分支并行开发。
合并：git merge <分支>；快进 vs 三方合并。
冲突：两人改了同一处。解法：打开冲突文件 → 看到 <<<<<<< / ======= / >>>>>>> → 手工选定保留内容 → 删标记 → add+commit。
冲突不可怕，越早 pull 越少冲突。

4. GitHub 协作：PR 与 Code Review

PR（Pull Request）= 把你的分支合入主干前的"评审单"。
PR 里写清楚：改了什么、为什么、怎么验证（对应 CLAUDE.md 的 Plan/审计模板思路）。
Code Review：别人看你的改动；评审意见要礼貌回应，合入前至少一个 reviewer 同意。
关联 Issue：fixes #123 可在合入时自动关 Issue。

5. 公司仓库与提交规范

仓库结构：services/（各业务服务源码）+ manifests/（k8s 清单）+ docs/（文档，含本培训目录）。
提交信息：中文、一句说清干了啥，如：D6 作业：首次提交 PR（姓名）、新增采购统计接口。
提交范围克制：只提交与本次任务相关的文件，别顺手带进无关改动。
规范遵守：CLAUDE.md 里的 Class A（commit/push 需批准？——注意：commit 不在 Class A 列出的清单里，但 push 属于需先计划的分级，按公司 AGENTS.md 操作分级走）。

注：AGENTS.md 将 git commit/tag/push 列为 Class A（执行前需批准），培训期内学员的 PR 由负责人评审把关即可视为该环节。

6. 公司 CI/CD：git tag 如何触发发版（本模块重中之重）

开发者打 tag：git tag <app>-vX.Y.Z
        │  git push origin <app>-vX.Y.Z
        ▼
GitHub Actions 触发（runner 标签：self-hosted, linux, x64, k3s-test）
        ▼
构建镜像 → 推到 registry.akria.net
        ▼
k3s 集群拉新镜像 → 滚动更新部署

命名规则：<应用名>-v<版本号>，如 core-api-v2-v1.3.0。
详细指南在 .agent/skills/cicd-deploy/SKILL.md（D22 实操）。
今天只要求看懂这张图；D22 会亲手打 tag 发一次版。

7. Git 事故处理（了解，知道去哪儿查）

场景	处理
误提交想撤销	`git revert <hash>`（安全，留记录） / `git reset`（慎用，会改写历史）
误删文件还没提交	`git checkout -- <file>` 找回
提交信息写错	`git commit --amend -m "新信息"`（仅未推送时）
本地乱了想重来	`git status` + `git diff` 先看清楚，别乱 reset
删了不该删的分支	`git reflog` 找 hash 恢复

红线：改了历史又 push 过 = 事故；拿不准就先问。

讲解节奏建议（约 90 分钟）

时段	内容
09:00-09:15	引入：代码托管 = 团队的账本 + 发版扳机
09:15-09:45	本地工作流 + 三区域（现场演示 add/commit/log）
09:45-10:05	分支与冲突（制造一次冲突现场解决）
10:05-10:25	PR 与 Code Review 流程
10:25-10:50	公司 CI/CD：git tag 触发全流程（画图）
10:50-11:30	学员实操：走一遍分支→提交→推分支（对应作业）
11:30-11:50	事故处理 + 常见误区
11:50-12:00	布置作业

常见误区汇总

误区	正确理解
`commit` 了代码就到服务器了	commit 在本地；push 才到 GitHub
直接在 main 上改	开发走 feature 分支 + PR，main 保持可发布
提交信息随便写	中文、一句说清；历史是给人看的，也用于回溯事故
冲突很可怕	正常现象；早 pull 少冲突，遇到按 3 步解
tag 只是标记	公司里 tag 是发版扳机，打了 tag 就触发 CI/CD
`git push --force` 无所谓	改写已推送历史 = 事故，禁止
本地乱了就 reset	先 status/diff/reflog 看清楚，拿不准问人

D6 Git + GitHub

On this page