文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 2022 年度计划中 Git 系列课程的第四讲对应仓库 2022/vi/Days/day39.md 与英文原版 2022/Days/day39.md。在前三天Day 37 认识 Git、Day 38 暂存与提交之后本讲聚焦提交之前的审查环节与后悔药操作如何用git diff看清已暂存与未暂存改动、如何配置可视化 diff 工具、如何查看提交历史与单次提交内容以及如何取消暂存、丢弃本地改动、从快照恢复文件最后厘清git rebase与git merge的取舍。学完本讲你将掌握一套完整的本地版本控制巡检与恢复工作流为下一讲接入 GitHub 等基于 Git 的远程服务打下基础。注意本讲所有操作都发生在本地仓库内尚未涉及 GitHub 或任何基于 Git 的远程服务。这些命令的价值恰恰在于在代码离开你的机器之前先由你把关每一次提交。查看已暂存与未暂存改动Viewing the Staged and Unstaged Changes在提交之前最佳实践是先用git diff系列命令审查将要进入快照的内容。上一讲Day 38我们学会了用git status观察暂存区而git diff则直接给出改动的内容级差异。git diff --staged查看已暂存的内容运行git diff --staged可以查看当前暂存区相对于上一次提交HEAD的所有差异——包括所有新增文件、被修改的文件以及被删除的文件git diff --staged在输出中被修改文件的差异通过---与标记行区分---表示变更前的版本旧行表示变更后的版本新行。例如文档演示中add some text即表示新增了一行文本。由于git diff的输出可能较长分页器如less会在末尾显示(END)按q退出。git diff暂存区与工作目录的对比git diff --staged比较的是暂存区 vs 上次提交而裸的git diff比较的是工作目录 vs 暂存区。也就是说如果你在git add之后又修改了文件这些新的改动不会被git diff --staged捕获只会出现在git diff中。文档中的演示流程如下对已暂存的新文件code.txt追加几行文本运行git diff即可看到工作目录中尚未暂存的改动文件已被git add暂存输出中显示为A状态的新文件文件内容修改尚未暂存输出中显示为M状态的已修改文件。两个命令组合起来就能完整回答我改了哪些东西、哪些已进入暂存区、哪些还没这三个问题命令对比对象典型用途git diff --staged暂存区 vs 上次提交HEAD提交前审查即将进入快照的内容git diff工作目录 vs 暂存区查看git add之后又发生的改动git status工作目录/暂存区 vs HEAD了解文件级别的状态概览git status -s为精简版可视化 Diff 工具Visual Diff Tools终端中的git diff输出对新人并不友好尤其是涉及大文件或复杂改动时。文档作者的建议是使用可视化 diff 工具常见的选项包括KDiff3跨平台的开源文件与目录 diff/合并工具P4MergePerforce 提供的可视化 diff/合并工具WinMerge仅支持 WindowsVSCode内置 diff 视图多数 IDE 也内置此功能。配置 diff 工具要让 Git 在调用 diff 工具时启动 VSCode先设置全局配置git config --global diff.tool vscode然后运行git config --global -e打开全局配置文件位于用户主目录的.gitconfig查看或调整相关参数git config --global -e使用git difftool打开可视化对比配置完成后用git difftool替代git diffGit 就会把差异交给可视化工具渲染git difftoolGit 会打开 VSCode 的 diff 页面左右分栏对比两个版本。文档演示中仅修改了一个文件——从空变成右侧新增了一行代码这种并排视图远比终端中的/---标记容易追踪。同样可以用git difftool --staged在提交前逐文件审查已暂存的改动git difftool --staged文档作者特别说明他日常使用 VSCode 作为 IDE和大多数 IDE 一样VSCode 内置了差异对比功能绝大多数场景下不必从终端启动 diff 工具但在没有安装 IDE 的环境中如远程服务器或受限的开发机掌握这些命令依然很有价值。查看提交历史Viewing the Historygit log完整历史git log提供仓库内全部提交的综合视图每个提交拥有对仓库唯一的十六进制哈希串输出中还包含当前所在分支、作者、日期和提交说明。git loggit log --oneline精简视图git log --oneline将每个提交压缩为一行缩短的哈希串加单行提交说明。缩短后的哈希可以直接用于diff、show等命令不必复制完整的 40 位十六进制串。git log --onelinegit log --oneline --reverse从最早提交看起默认git log按时间倒序排列最新在上。加上--reverse后最早的提交会排在最上面适合从项目起点梳理演进过程git log --oneline --reverse查看单个提交Viewing a Commitgit log只能看到提交的摘要信息。若想深入查看某个提交到底改了什么使用git showgit show commit ID先用git log --oneline --reverse拿到提交列表再挑选其中一个哈希串传给git show。输出会包含该提交的完整元数据哈希、作者、日期、提交说明以及具体到行的改动内容。相对引用HEAD~1除了直接用哈希串Git 支持相对引用。git show HEAD~1中的数字1表示从当前版本往回退 1 步git show HEAD~1这对快速查看上一步改了什么非常方便。若想知道某个快照目录里都有哪些文件则用git ls-treegit ls-tree HEAD~1git ls-tree以树状列出快照内容。文档演示中可以看到输出里包含两个blob对象——blob 代表文件内容而tree代表目录。提交commit和标签tag也会出现在这类对象信息中。理解这三类对象blob / tree / commit是理解 Git 内部存储模型的关键blob文件的某一版本的内容快照tree一组目录项文件名 对应 blob/tree 引用commit指向一棵 tree并记录父提交、作者、时间与提交说明。拿到 blob 的哈希后可以继续用git show下钻查看该 blob 对应的文件内容git show blob ID取消暂存文件Unstaging Files场景你执行了git add .把一切都放进了暂存区但其中某些文件并不想进入本次提交。文档演示中newfile.txt被加进了暂存区但作者尚未准备好提交它于是用git restore --staged撤销这次git addgit restore --staged newfile.txt同样的操作也适用于已修改的文件。比如main.js已暂存git status中显示为绿色的M表示 modified执行git restore --staged main.js后修改会退出暂存区恢复到已修改但未暂存的状态。文档作者特别提到这个命令在维护 90DaysOfDevOps 仓库时非常实用他有时会提前为后续几天起草笔记但又不想把这些草稿提交并推送到公开仓库git restore --staged恰好能把这些内容从暂存区摘出来留在本地工作目录中继续打磨。丢弃本地改动Discarding Local Changes当你对某些改动不满意、想彻底作废时仍然使用git restore系列命令。git restore .从快照恢复工作目录git restore .该命令将工作目录中所有已跟踪文件恢复到最近快照HEAD/暂存区的状态。注意未跟踪untracked的文件不受影响——文档演示中newfile.txt从未被跟踪git restore .执行后它依然存在。git clean清理未跟踪文件要删除newfile.txt这类未跟踪文件使用git clean。直接运行会先给出警告提示git clean如果你明确知道后果可以加-fd强制删除文件并连同所有未跟踪目录一起清理git clean -fd-f表示强制-d表示同时处理目录。git clean是少数具有破坏性的命令执行前建议先用git clean -n做一次演习列出将被删除的内容。将文件恢复到更早版本Restoring a File to an Earlier VersionGit 的核心价值之一就是能从快照中恢复文件的旧版本。需要强调的是Git 不是备份系统它提供的是非常快速的恢复点文档作者建议对重要代码另外建立备份方案将副本保存到其他位置。演示流程如下删除工作目录中最关键的文件readme.md这里用的是 Unix 删除命令而非 Git 命令rm readme.md此时工作目录中已没有readme.md。实际上也可以改用git rm readme.md这会同时删除工作目录文件并让删除操作反映到 Git 数据库中即暂存该删除git rm readme.md为了让演练更贴近文件被彻底删除的场景文档先用 Unix 命令删除再提交这次删除证明工作目录与暂存区中都不再有任何相关内容git commit -m Remove readme.md失误发生了现在我们需要这个文件回来 可能的恢复路径有两种撤销整个提交git undo可以撤销最后一次提交但如果删除发生在较早的提交中这条路就行不通精确恢复单个文件先用git log找到提交历史确认文件存在于HEAD~1上一个快照中然后从快照中提取指定文件git restore --sourceHEAD~1 README.md--source指定从哪个提交/快照读取内容。执行后readme.md重新出现在工作目录中此时它是一个未跟踪的新文件需要重新走一遍跟踪、暂存、提交流程。这个删除—提交—恢复的闭环演示了 Git 快照模型的精髓只要文件在某次提交中存在过它就可以被找回。Rebase 与 Merge 的选择Rebase vs Mergegit rebase和git merge大概是 Git 使用中最让人头疼的议题。首先要明确两者解决的是同一个问题——把一个分支的改动整合到另一个分支只是实现方式不同。场景设定假设你在独立的feature分支上开发新功能与此同时main分支持续产生新提交git merge非破坏性的简单选择git merge feature main上面的命令把main合并进feature分支。Merge 的最大优点是非破坏性已有分支不会被改变。缺点也很明显——每次需要并入上游改动时feature分支都会多出一个与功能无关的 merge commit如果main非常活跃这些 merge commit 会逐渐污染feature分支的历史。git rebase重写历史以换取线性整洁另一种方案是把feature分支 rebase 到main之上git checkout feature git rebase mainRebase 会把整个feature分支移动到main的最新提交之后相当于把main的新提交全部吸收进来。与 merge 不同rebase不产生 merge commit而是为原分支的每个提交创建全新的提交从而重写项目历史。Rebase 的最大收益是更干净的项目历史消除了多余的 merge commit对比上面两张示意图可以清晰地看到一条近乎线性的演进路径。权衡与黄金法则选择更干净的历史并非没有代价协作风险rebase 重写的是已发布的历史。如果不遵循 Rebase 黄金法则绝不对已推送到共享仓库的提交执行 rebase重写历史会对团队协作工作流造成灾难性影响丢失上下文merge commit 本身记录着上游改动在何时被整合进 feature这一信息rebase 会丢失这部分上下文。因此实践中的取舍建议是尚未推送的本地分支、独享分支上用 rebase 保持历史整洁已经共享给团队的分支用 merge 保持历史真实可追溯。这一主题在下一讲接入 GitHub 等托管服务后见 Day 40会与 Pull Request 工作流产生更紧密的联系。本讲命令速查表场景命令查看已暂存改动git diff --staged查看未暂存改动工作目录 vs 暂存区git diff配置可视化 diff 工具git config --global diff.tool vscode查看全局配置git config --global -e用可视化工具查看差异git difftool/git difftool --staged查看完整提交历史git log查看精简历史git log --oneline/git log --oneline --reverse查看单个提交/文件内容git show commit/blob ID、git show HEAD~1列出快照目录内容git ls-tree HEAD~1取消暂存git restore --staged file丢弃已跟踪文件的本地改动git restore .清理未跟踪文件git clean、git clean -fd慎用从指定快照恢复单个文件git restore --sourceHEAD~1 file整合分支保留历史git merge整合分支重写历史、线性整洁git rebase这组命令共同构成了提交前的审查—调整—确认闭环也是接下来把本地仓库与 GitHub、GitLab、Bitbucket 等基于 Git 的托管服务对接时最常用的基本功。更多 Git 命令与上下文可继续阅读仓库中 Day 40 及 Git 系列其他章节。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列对应仓库 2022 年英文档/教程90DaysOfDevOps 实战篇Git 查看、取消暂存、丢弃与恢复变更Day 39 全解析90DaysOfDevOps 实战篇Git 查看、取消暂存、丢弃与恢复变更Day 39 全解析 本篇技术指南聚焦于 90DaysOfDevOps 学习路线文档/教程90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列中 Git 本地工作流的核文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 2022 年度计划中 Git 系列课程的第四讲对应仓库 2022/vi/Days/day39.md 与英文原版 2022/Days/day39.md。在前三天Day 37 认识 Git、Day 38 暂存与提交之后本讲聚焦提交之前的审查环节与后悔药操作如何用git diff看清已暂存与未暂存改动、如何配置可视化 diff 工具、如何查看提交历史与单次提交内容以及如何取消暂存、丢弃本地改动、从快照恢复文件最后厘清git rebase与git merge的取舍。学完本讲你将掌握一套完整的本地版本控制巡检与恢复工作流为下一讲接入 GitHub 等基于 Git 的远程服务打下基础。注意本讲所有操作都发生在本地仓库内尚未涉及 GitHub 或任何基于 Git 的远程服务。这些命令的价值恰恰在于在代码离开你的机器之前先由你把关每一次提交。查看已暂存与未暂存改动Viewing the Staged and Unstaged Changes在提交之前最佳实践是先用git diff系列命令审查将要进入快照的内容。上一讲Day 38我们学会了用git status观察暂存区而git diff则直接给出改动的内容级差异。git diff --staged查看已暂存的内容运行git diff --staged可以查看当前暂存区相对于上一次提交HEAD的所有差异——包括所有新增文件、被修改的文件以及被删除的文件git diff --staged在输出中被修改文件的差异通过---与标记行区分---表示变更前的版本旧行表示变更后的版本新行。例如文档演示中add some text即表示新增了一行文本。由于git diff的输出可能较长分页器如less会在末尾显示(END)按q退出。git diff暂存区与工作目录的对比git diff --staged比较的是暂存区 vs 上次提交而裸的git diff比较的是工作目录 vs 暂存区。也就是说如果你在git add之后又修改了文件这些新的改动不会被git diff --staged捕获只会出现在git diff中。文档中的演示流程如下对已暂存的新文件code.txt追加几行文本运行git diff即可看到工作目录中尚未暂存的改动文件已被git add暂存输出中显示为A状态的新文件文件内容修改尚未暂存输出中显示为M状态的已修改文件。两个命令组合起来就能完整回答我改了哪些东西、哪些已进入暂存区、哪些还没这三个问题命令对比对象典型用途git diff --staged暂存区 vs 上次提交HEAD提交前审查即将进入快照的内容git diff工作目录 vs 暂存区查看git add之后又发生的改动git status工作目录/暂存区 vs HEAD了解文件级别的状态概览git status -s为精简版可视化 Diff 工具Visual Diff Tools终端中的git diff输出对新人并不友好尤其是涉及大文件或复杂改动时。文档作者的建议是使用可视化 diff 工具常见的选项包括KDiff3跨平台的开源文件与目录 diff/合并工具P4MergePerforce 提供的可视化 diff/合并工具WinMerge仅支持 WindowsVSCode内置 diff 视图多数 IDE 也内置此功能。配置 diff 工具要让 Git 在调用 diff 工具时启动 VSCode先设置全局配置git config --global diff.tool vscode然后运行git config --global -e打开全局配置文件位于用户主目录的.gitconfig查看或调整相关参数git config --global -e使用git difftool打开可视化对比配置完成后用git difftool替代git diffGit 就会把差异交给可视化工具渲染git difftoolGit 会打开 VSCode 的 diff 页面左右分栏对比两个版本。文档演示中仅修改了一个文件——从空变成右侧新增了一行代码这种并排视图远比终端中的/---标记容易追踪。同样可以用git difftool --staged在提交前逐文件审查已暂存的改动git difftool --staged文档作者特别说明他日常使用 VSCode 作为 IDE和大多数 IDE 一样VSCode 内置了差异对比功能绝大多数场景下不必从终端启动 diff 工具但在没有安装 IDE 的环境中如远程服务器或受限的开发机掌握这些命令依然很有价值。查看提交历史Viewing the Historygit log完整历史git log提供仓库内全部提交的综合视图每个提交拥有对仓库唯一的十六进制哈希串输出中还包含当前所在分支、作者、日期和提交说明。git loggit log --oneline精简视图git log --oneline将每个提交压缩为一行缩短的哈希串加单行提交说明。缩短后的哈希可以直接用于diff、show等命令不必复制完整的 40 位十六进制串。git log --onelinegit log --oneline --reverse从最早提交看起默认git log按时间倒序排列最新在上。加上--reverse后最早的提交会排在最上面适合从项目起点梳理演进过程git log --oneline --reverse查看单个提交Viewing a Commitgit log只能看到提交的摘要信息。若想深入查看某个提交到底改了什么使用git showgit show commit ID先用git log --oneline --reverse拿到提交列表再挑选其中一个哈希串传给git show。输出会包含该提交的完整元数据哈希、作者、日期、提交说明以及具体到行的改动内容。相对引用HEAD~1除了直接用哈希串Git 支持相对引用。git show HEAD~1中的数字1表示从当前版本往回退 1 步git show HEAD~1这对快速查看上一步改了什么非常方便。若想知道某个快照目录里都有哪些文件则用git ls-treegit ls-tree HEAD~1git ls-tree以树状列出快照内容。文档演示中可以看到输出里包含两个blob对象——blob 代表文件内容而tree代表目录。提交commit和标签tag也会出现在这类对象信息中。理解这三类对象blob / tree / commit是理解 Git 内部存储模型的关键blob文件的某一版本的内容快照tree一组目录项文件名 对应 blob/tree 引用commit指向一棵 tree并记录父提交、作者、时间与提交说明。拿到 blob 的哈希后可以继续用git show下钻查看该 blob 对应的文件内容git show blob ID取消暂存文件Unstaging Files场景你执行了git add .把一切都放进了暂存区但其中某些文件并不想进入本次提交。文档演示中newfile.txt被加进了暂存区但作者尚未准备好提交它于是用git restore --staged撤销这次git addgit restore --staged newfile.txt同样的操作也适用于已修改的文件。比如main.js已暂存git status中显示为绿色的M表示 modified执行git restore --staged main.js后修改会退出暂存区恢复到已修改但未暂存的状态。文档作者特别提到这个命令在维护 90DaysOfDevOps 仓库时非常实用他有时会提前为后续几天起草笔记但又不想把这些草稿提交并推送到公开仓库git restore --staged恰好能把这些内容从暂存区摘出来留在本地工作目录中继续打磨。丢弃本地改动Discarding Local Changes当你对某些改动不满意、想彻底作废时仍然使用git restore系列命令。git restore .从快照恢复工作目录git restore .该命令将工作目录中所有已跟踪文件恢复到最近快照HEAD/暂存区的状态。注意未跟踪untracked的文件不受影响——文档演示中newfile.txt从未被跟踪git restore .执行后它依然存在。git clean清理未跟踪文件要删除newfile.txt这类未跟踪文件使用git clean。直接运行会先给出警告提示git clean如果你明确知道后果可以加-fd强制删除文件并连同所有未跟踪目录一起清理git clean -fd-f表示强制-d表示同时处理目录。git clean是少数具有破坏性的命令执行前建议先用git clean -n做一次演习列出将被删除的内容。将文件恢复到更早版本Restoring a File to an Earlier VersionGit 的核心价值之一就是能从快照中恢复文件的旧版本。需要强调的是Git 不是备份系统它提供的是非常快速的恢复点文档作者建议对重要代码另外建立备份方案将副本保存到其他位置。演示流程如下删除工作目录中最关键的文件readme.md这里用的是 Unix 删除命令而非 Git 命令rm readme.md此时工作目录中已没有readme.md。实际上也可以改用git rm readme.md这会同时删除工作目录文件并让删除操作反映到 Git 数据库中即暂存该删除git rm readme.md为了让演练更贴近文件被彻底删除的场景文档先用 Unix 命令删除再提交这次删除证明工作目录与暂存区中都不再有任何相关内容git commit -m Remove readme.md失误发生了现在我们需要这个文件回来 可能的恢复路径有两种撤销整个提交git undo可以撤销最后一次提交但如果删除发生在较早的提交中这条路就行不通精确恢复单个文件先用git log找到提交历史确认文件存在于HEAD~1上一个快照中然后从快照中提取指定文件git restore --sourceHEAD~1 README.md--source指定从哪个提交/快照读取内容。执行后readme.md重新出现在工作目录中此时它是一个未跟踪的新文件需要重新走一遍跟踪、暂存、提交流程。这个删除—提交—恢复的闭环演示了 Git 快照模型的精髓只要文件在某次提交中存在过它就可以被找回。Rebase 与 Merge 的选择Rebase vs Mergegit rebase和git merge大概是 Git 使用中最让人头疼的议题。首先要明确两者解决的是同一个问题——把一个分支的改动整合到另一个分支只是实现方式不同。场景设定假设你在独立的feature分支上开发新功能与此同时main分支持续产生新提交git merge非破坏性的简单选择git merge feature main上面的命令把main合并进feature分支。Merge 的最大优点是非破坏性已有分支不会被改变。缺点也很明显——每次需要并入上游改动时feature分支都会多出一个与功能无关的 merge commit如果main非常活跃这些 merge commit 会逐渐污染feature分支的历史。git rebase重写历史以换取线性整洁另一种方案是把feature分支 rebase 到main之上git checkout feature git rebase mainRebase 会把整个feature分支移动到main的最新提交之后相当于把main的新提交全部吸收进来。与 merge 不同rebase不产生 merge commit而是为原分支的每个提交创建全新的提交从而重写项目历史。Rebase 的最大收益是更干净的项目历史消除了多余的 merge commit对比上面两张示意图可以清晰地看到一条近乎线性的演进路径。权衡与黄金法则选择更干净的历史并非没有代价协作风险rebase 重写的是已发布的历史。如果不遵循 Rebase 黄金法则绝不对已推送到共享仓库的提交执行 rebase重写历史会对团队协作工作流造成灾难性影响丢失上下文merge commit 本身记录着上游改动在何时被整合进 feature这一信息rebase 会丢失这部分上下文。因此实践中的取舍建议是尚未推送的本地分支、独享分支上用 rebase 保持历史整洁已经共享给团队的分支用 merge 保持历史真实可追溯。这一主题在下一讲接入 GitHub 等托管服务后见 Day 40会与 Pull Request 工作流产生更紧密的联系。本讲命令速查表场景命令查看已暂存改动git diff --staged查看未暂存改动工作目录 vs 暂存区git diff配置可视化 diff 工具git config --global diff.tool vscode查看全局配置git config --global -e用可视化工具查看差异git difftool/git difftool --staged查看完整提交历史git log查看精简历史git log --oneline/git log --oneline --reverse查看单个提交/文件内容git show commit/blob ID、git show HEAD~1列出快照目录内容git ls-tree HEAD~1取消暂存git restore --staged file丢弃已跟踪文件的本地改动git restore .清理未跟踪文件git clean、git clean -fd慎用从指定快照恢复单个文件git restore --sourceHEAD~1 file整合分支保留历史git merge整合分支重写历史、线性整洁git rebase这组命令共同构成了提交前的审查—调整—确认闭环也是接下来把本地仓库与 GitHub、GitLab、Bitbucket 等基于 Git 的托管服务对接时最常用的基本功。更多 Git 命令与上下文可继续阅读仓库中 Day 40 及 Git 系列其他章节。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列对应仓库 2022 年英文档/教程90DaysOfDevOps 实战篇Git 查看、取消暂存、丢弃与恢复变更Day 39 全解析90DaysOfDevOps 实战篇Git 查看、取消暂存、丢弃与恢复变更Day 39 全解析 本篇技术指南聚焦于 90DaysOfDevOps 学习路线文档/教程90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列中 Git 本地工作流的核文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
