文档/教程【免费下载链接】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点击查看免费下载本指南承接 第 38 天Staging Changing 的本地 Git 工作流系统讲解如何查看已暂存与未暂存的差异、借助可视化工具审阅变更、回看提交历史与单个快照以及安全地取消暂存、丢弃本地修改并从旧快照恢复文件。读完本文你将掌握git diff、git difftool、git log、git show、git restore、git clean等命令的完整用法并能理解rebase与merge的本质区别为后续接入 GitHub 等远程协作平台打下基础。前情回顾从暂存到变更管理第 38 天我们完成了一个本地 Git 仓库的初始化git init、文件暂存git add、首次快照提交git commit -m ...、文件移除git rm、重命名与忽略.gitignore等基础操作并学会了用git status -s快速查看文件状态。在那一阶段我们尚未接触 GitHub 或其他任何基于 Git 的远程服务所有操作都发生在本地工作区目的是先牢牢掌控自己的项目而这一切能力在接入远程工具后依然全部有效。本日的主题可以概括为四件事查看Viewing、取消暂存Unstaging、丢弃Discarding与恢复Restoring。这些能力共同构成了「提交前安全审查」与「犯错后快速回退」的完整闭环。查看暂存与未暂存的变更在提交commit之前养成先查看「将要提交什么」的习惯是良好的实践。Git 提供了两把对应的钥匙git diff --staged将**暂存区staging area与最近一次提交HEAD**进行比较展示你已经git add但尚未提交的所有变更包括新增、修改与删除的文件。git diff将暂存区与**工作目录working directory**进行比较展示你修改了但尚未git add的内容。举个典型的操作流先用git status -s看到新增文件code.txt状态标记A和修改过的main.js状态标记M接着执行git diff --stagedGit 会逐文件输出全部待提交差异。如果我们随后又向code.txt追加了几行文本此时再执行git diff就能看到这份尚未暂存的新增内容。读懂 diff 输出格式diff 输出的可读性直接决定了你审查变更的效率核心标记如下文件名行以---旧版本a/前缀与新版本b/前缀标示分别代表变更前后的文件以开头的行为新增行以-开头的行为删除行 ... 为块头hunk header说明变更在文件中的位置与行数范围新文件会被整体视为全部新增因此在code.txt首次加入时其内容全部以行呈现。对许多人来说阅读原始文本 diff 仍然不够直观这正是下一节可视化工具的价值所在。使用可视化 Diff 工具审阅变更常见且成熟的可视化 diff 工具有KDiff3跨平台Windows / Linux / macOS的三方合并与差异比较工具P4MergePerforce 出品的免费可视化 diff / merge 工具同样跨平台WinMerge仅适用于 Windows 的开源差异比较工具VSCode现代主流 IDE内置完整的 diff 查看与合并能力。将 VSCode 配置为 Git 的默认 diff 工具只需执行全局配置命令git config --global diff.tool vscode为了在启动时直接进入 diff 视图并等待比较完成还需要配置 VSCode 的启动命令参数git config --global diff.tool.vscode.cmd code --wait --diff $LOCAL $REMOTE这里的$LOCAL与$REMOTE是 Git 在调用工具时自动注入的临时文件路径变量--wait让 Git 等待编辑器关闭后再继续--diff直接以双栏对比模式打开。执行完成后可以用git config --global -e打开全局配置文件默认编辑器如 nano核对diff.tool相关设置是否正确落盘。配置就绪后在仓库中运行git difftoolGit 会逐个打开发生变更的文件进入 VSCode 的 diff 页面。下图中左侧为旧版本右侧为新版本可以清晰地看到新增的一行内容如果只想比较已暂存与最近提交之间的差异相当于可视化版的git diff --staged则使用git difftool --staged随后可以按提示在多个变更文件之间循环切换审阅再决定是否提交。需要说明的是绝大多数 IDE 已内置了等价功能日常开发中很少需要从终端手动调用git difftool但当你所处的环境没有安装 IDE 时这一套命令依然能提供完整能力。查看提交历史git log是回看仓库历史的入口命令它会输出仓库中所有提交的完整信息每条提交都对应一串十六进制哈希值commit hash完整形式为 40 位对仓库唯一同时展示所在分支、作者、提交日期与提交信息commit messagegit log如果提交很多完整输出会很长此时git log --oneline将每条提交压缩为一行——只保留缩短后的哈希前缀与一行提交说明。这个短哈希可以直接复用于git diff、git show等其他命令git log --oneline若希望把顺序反过来、从第一次提交开始浏览可以追加--reversegit log --oneline --reverse这在项目刚开始、提交数量有限时尤其有用可以按时间正序梳理整个项目的演进脉络。查看单个提交与快照内容git log给出的是提交清单而git show则负责深入单条提交的内部细节。操作方法是先通过git log --oneline --reverse取得提交列表然后挑选其中一个提交 ID 执行git show commit ID输出会包含该提交的完整哈希、作者、日期、提交信息以及实际变更内容与git diff类似的逐行差异。也可以使用相对引用HEAD~N其中 N 表示从当前版本往回数第几步git show HEAD~1HEAD~1即当前 HEAD 的上一个快照。如果想列出某个快照snapshot目录中所有文件的完整树形清单则使用git ls-treegit ls-tree HEAD~1输出中的blob代表文件tree代表目录此外还可能看到指向其他提交commit与标签tag的引用条目。例如下列输出即表示该快照包含README.md与main.js两个文件blob拿到 blob 对应的哈希后可以继续用git show查看该特定版本文件的完整内容从而精确定位某一历史时刻某个文件的状态。取消暂存文件有时我们会执行git add .把一切全部加入暂存区但其中某些文件其实还不想进入本次快照。取消暂存的标准做法是使用git restore --stagedgit restore --staged newfile.txt这条命令撤销的是git add这一步文件会从暂存区退出重新变为未跟踪untracked状态git status -s中显示为??。对于已跟踪但被修改过的文件如main.js状态为M同样可以用该命令把改动移出暂存区恢复成「已修改但未暂存」的状态。这在「提前为未来几天写笔记」的场景中非常实用——例如在 90DaysOfDevOps 的学习过程中有时会提前写好次日内容但又不想将其提交并推送到公开仓库取消暂存便能让工作区保持「随时可分次提交」的整洁状态。丢弃本地修改如果修改了某些文件但最终不满意想要彻底作废这些改动git restore再次登场。针对整个目录执行git restore .Git 会把工作目录中所有已跟踪文件的改动恢复为最近一次快照HEAD中的内容。注意未跟踪文件untracked不会受到影响——例如尚未被跟踪的newfile.txt依然存在因为仓库中从未存在过它的旧版本可供恢复。要清理未跟踪文件则需要git clean。直接执行它会得到安全警告因为删除不可逆git clean如果确认后果可承受可以使用-fd组合参数强制删除-fforce跳过确认-d同时递归删除未跟踪的目录git clean -fd更稳妥的做法是先用git clean -ndry run预览将要删除的文件清单确认无误后再执行真正的删除。从早期版本恢复文件Git 最有价值的能力之一就是能从历史快照中快速还原文件的旧版本。需要再次强调这不是备份系统而是一个非常快速的恢复点restore point文章作者也明确建议重要代码仍应在其他位置通过备份方案另行保存。演示一个完整的「误删恢复」流程。首先用操作系统的命令Unix 系的rm删除目录中最关键的文件此时工作目录中已没有README.md。如果改用git rm readme.md删除动作会同步记录进 Git 数据库并反映到暂存区这里我们刻意模拟「彻底删除」的场景随后提交该删除并确认工作区与暂存区都已不再包含该文件。发现误删后如何找回文档提到可以用git undo之类的思路回退最近一次提交但如果删除发生在若干次提交之前就不宜整体回退。正确做法是先用git log找到包含该文件的提交再用--source参数精确指定恢复来源git restore --sourceHEAD~1 README.md--source指明从哪个快照取文件HEAD~1表示上一个提交README.md指定要恢复的目标。执行后该文件会以未跟踪状态重新出现在工作目录中接着用前面学过的流程git add→git commit重新跟踪、暂存并提交即可。需要补充说明文档中提到的git undo并非标准 Git 内建命令Git 没有内置undo子命令实际回退提交通常使用git revert生成一个反向提交保留历史或git reset移动分支指针git restore --sourcerev file这种定点恢复方式既不触碰其他提交也不会误伤历史是最精准的选择。Rebase 与 Merge 的取舍git rebase与git merge被许多初学者视为 Git 的头号难题但首先要明确两者解决的是同一个问题——把某个分支的变更整合进另一个分支只是方式截然不同。设想一个典型场景从主分支main切出特性分支feature开发新功能期间 main 分支持续产生新提交。此时需要把 main 上的新内容同步进 feature。方式一merge合并git merge feature main这条命令把 main 分支合并进 feature 分支。合并是非破坏性的——现有分支不被动任何改动因此简单、安全。代价是每次需要并入上游变更时feature 分支都会多出一个「合并提交」merge commit如果 main 分支非常活跃这些与特性开发无关的合并提交会不断累积污染 feature 分支的历史使其难以阅读。方式二rebase变基git checkout feature git rebase mainrebase会把整个 feature 分支“搬移”到 main 分支的最新提交之上将 main 上的所有新提交纳入基础但与 merge 不同它不使用合并提交而是为 feature 分支的每一个原始提交重写为全新的提交对象从而形成一条线性的历史。最大的收益是极其干净的项目历史没有多余的合并提交提交序列近似一条直线对比两种方式的分支图可以直观感受到差异。但干净的代价同样真实重写历史具有危险性如果不遵循「rebase 黄金法则」Golden Rule of Rebasing即绝不要对已推送至共享仓库、他人正在使用的分支执行 rebase重写后的历史可能与协作者的本地记录产生冲突对协作流程造成灾难性影响丢失合并上下文rebase 抹去了「上游变更是在何时、以何种方式并入特性分支」的信息而 merge commit 恰恰保留了这一上下文。因此实践上的常见取舍是尚未推送、仅供本地开发的分支可以放心 rebase 换取整洁历史已经推送并共享的分支优先使用 merge 保证协作安全。仓库中的真实印证一个用 Git 驱动的大型学习项目本文所在的 90DaysOfDevOps 仓库本身就是 Git 实践的最佳案例从根目录的 README.md 与 _sidebar.md 维护项目导航到 2022.md、2023.md、2024.md 逐年沉淀学习路径再到2022/zh_tw/Days/下按天组织的 90 篇文档与配套截图、2022/zh_tw/的 语言版本 README背后都是第 38、39 天所讲的这套本地 Git 工作流修改 → 暂存 → 审阅 diff → 提交 → 必要时回退。你完全可以用本日所学命令git log --oneline --reverse、git show、git restore等在本仓库中实际演练观察一个真实开源项目的历史演进方式。学习路线预告接下来第 40 天将进入与 Git 协作平台集成的阶段届时本日掌握的 diff 审阅、历史查看与恢复能力会与 GitHub 等平台上的 Pull Request、Commit 审阅界面直接对应。小结本日共梳理了五类高频 Git 操作用git diff/git diff --staged查看变更并用git difftool可视化审阅用git log、git show、git ls-tree回看历史与快照用git restore --staged取消暂存用git restore .与git clean -fd丢弃本地修改用git restore --sourcerev file从旧快照定点恢复文件。最后厘清了merge与rebase的本质差异与应用边界。牢记两条铁律提交前必看 diff重写历史前必想协作——这些习惯将伴随你进入远程协作的下一阶段。赞分享文档/教程【免费下载链接】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 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列中 Git 本地工作流的核文档/教程90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复的完整实战指南90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复的完整实战指南 本文是 90DaysOfDevOps 挑战中 Git 系列D文档/教程90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列对应仓库 2022 年英文档/教程上一篇OpenMed RTF 文本提取与脱敏指南控制流解析、源码偏移映射与写回机制下一篇Zephyr RTOS 在 Microchip PolarFire SoC Icicle Kitmpfs_icicle上的构建、烧录与调试实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 第 39 天：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点击查看免费下载本指南承接 第 38 天Staging Changing 的本地 Git 工作流系统讲解如何查看已暂存与未暂存的差异、借助可视化工具审阅变更、回看提交历史与单个快照以及安全地取消暂存、丢弃本地修改并从旧快照恢复文件。读完本文你将掌握git diff、git difftool、git log、git show、git restore、git clean等命令的完整用法并能理解rebase与merge的本质区别为后续接入 GitHub 等远程协作平台打下基础。前情回顾从暂存到变更管理第 38 天我们完成了一个本地 Git 仓库的初始化git init、文件暂存git add、首次快照提交git commit -m ...、文件移除git rm、重命名与忽略.gitignore等基础操作并学会了用git status -s快速查看文件状态。在那一阶段我们尚未接触 GitHub 或其他任何基于 Git 的远程服务所有操作都发生在本地工作区目的是先牢牢掌控自己的项目而这一切能力在接入远程工具后依然全部有效。本日的主题可以概括为四件事查看Viewing、取消暂存Unstaging、丢弃Discarding与恢复Restoring。这些能力共同构成了「提交前安全审查」与「犯错后快速回退」的完整闭环。查看暂存与未暂存的变更在提交commit之前养成先查看「将要提交什么」的习惯是良好的实践。Git 提供了两把对应的钥匙git diff --staged将**暂存区staging area与最近一次提交HEAD**进行比较展示你已经git add但尚未提交的所有变更包括新增、修改与删除的文件。git diff将暂存区与**工作目录working directory**进行比较展示你修改了但尚未git add的内容。举个典型的操作流先用git status -s看到新增文件code.txt状态标记A和修改过的main.js状态标记M接着执行git diff --stagedGit 会逐文件输出全部待提交差异。如果我们随后又向code.txt追加了几行文本此时再执行git diff就能看到这份尚未暂存的新增内容。读懂 diff 输出格式diff 输出的可读性直接决定了你审查变更的效率核心标记如下文件名行以---旧版本a/前缀与新版本b/前缀标示分别代表变更前后的文件以开头的行为新增行以-开头的行为删除行 ... 为块头hunk header说明变更在文件中的位置与行数范围新文件会被整体视为全部新增因此在code.txt首次加入时其内容全部以行呈现。对许多人来说阅读原始文本 diff 仍然不够直观这正是下一节可视化工具的价值所在。使用可视化 Diff 工具审阅变更常见且成熟的可视化 diff 工具有KDiff3跨平台Windows / Linux / macOS的三方合并与差异比较工具P4MergePerforce 出品的免费可视化 diff / merge 工具同样跨平台WinMerge仅适用于 Windows 的开源差异比较工具VSCode现代主流 IDE内置完整的 diff 查看与合并能力。将 VSCode 配置为 Git 的默认 diff 工具只需执行全局配置命令git config --global diff.tool vscode为了在启动时直接进入 diff 视图并等待比较完成还需要配置 VSCode 的启动命令参数git config --global diff.tool.vscode.cmd code --wait --diff $LOCAL $REMOTE这里的$LOCAL与$REMOTE是 Git 在调用工具时自动注入的临时文件路径变量--wait让 Git 等待编辑器关闭后再继续--diff直接以双栏对比模式打开。执行完成后可以用git config --global -e打开全局配置文件默认编辑器如 nano核对diff.tool相关设置是否正确落盘。配置就绪后在仓库中运行git difftoolGit 会逐个打开发生变更的文件进入 VSCode 的 diff 页面。下图中左侧为旧版本右侧为新版本可以清晰地看到新增的一行内容如果只想比较已暂存与最近提交之间的差异相当于可视化版的git diff --staged则使用git difftool --staged随后可以按提示在多个变更文件之间循环切换审阅再决定是否提交。需要说明的是绝大多数 IDE 已内置了等价功能日常开发中很少需要从终端手动调用git difftool但当你所处的环境没有安装 IDE 时这一套命令依然能提供完整能力。查看提交历史git log是回看仓库历史的入口命令它会输出仓库中所有提交的完整信息每条提交都对应一串十六进制哈希值commit hash完整形式为 40 位对仓库唯一同时展示所在分支、作者、提交日期与提交信息commit messagegit log如果提交很多完整输出会很长此时git log --oneline将每条提交压缩为一行——只保留缩短后的哈希前缀与一行提交说明。这个短哈希可以直接复用于git diff、git show等其他命令git log --oneline若希望把顺序反过来、从第一次提交开始浏览可以追加--reversegit log --oneline --reverse这在项目刚开始、提交数量有限时尤其有用可以按时间正序梳理整个项目的演进脉络。查看单个提交与快照内容git log给出的是提交清单而git show则负责深入单条提交的内部细节。操作方法是先通过git log --oneline --reverse取得提交列表然后挑选其中一个提交 ID 执行git show commit ID输出会包含该提交的完整哈希、作者、日期、提交信息以及实际变更内容与git diff类似的逐行差异。也可以使用相对引用HEAD~N其中 N 表示从当前版本往回数第几步git show HEAD~1HEAD~1即当前 HEAD 的上一个快照。如果想列出某个快照snapshot目录中所有文件的完整树形清单则使用git ls-treegit ls-tree HEAD~1输出中的blob代表文件tree代表目录此外还可能看到指向其他提交commit与标签tag的引用条目。例如下列输出即表示该快照包含README.md与main.js两个文件blob拿到 blob 对应的哈希后可以继续用git show查看该特定版本文件的完整内容从而精确定位某一历史时刻某个文件的状态。取消暂存文件有时我们会执行git add .把一切全部加入暂存区但其中某些文件其实还不想进入本次快照。取消暂存的标准做法是使用git restore --stagedgit restore --staged newfile.txt这条命令撤销的是git add这一步文件会从暂存区退出重新变为未跟踪untracked状态git status -s中显示为??。对于已跟踪但被修改过的文件如main.js状态为M同样可以用该命令把改动移出暂存区恢复成「已修改但未暂存」的状态。这在「提前为未来几天写笔记」的场景中非常实用——例如在 90DaysOfDevOps 的学习过程中有时会提前写好次日内容但又不想将其提交并推送到公开仓库取消暂存便能让工作区保持「随时可分次提交」的整洁状态。丢弃本地修改如果修改了某些文件但最终不满意想要彻底作废这些改动git restore再次登场。针对整个目录执行git restore .Git 会把工作目录中所有已跟踪文件的改动恢复为最近一次快照HEAD中的内容。注意未跟踪文件untracked不会受到影响——例如尚未被跟踪的newfile.txt依然存在因为仓库中从未存在过它的旧版本可供恢复。要清理未跟踪文件则需要git clean。直接执行它会得到安全警告因为删除不可逆git clean如果确认后果可承受可以使用-fd组合参数强制删除-fforce跳过确认-d同时递归删除未跟踪的目录git clean -fd更稳妥的做法是先用git clean -ndry run预览将要删除的文件清单确认无误后再执行真正的删除。从早期版本恢复文件Git 最有价值的能力之一就是能从历史快照中快速还原文件的旧版本。需要再次强调这不是备份系统而是一个非常快速的恢复点restore point文章作者也明确建议重要代码仍应在其他位置通过备份方案另行保存。演示一个完整的「误删恢复」流程。首先用操作系统的命令Unix 系的rm删除目录中最关键的文件此时工作目录中已没有README.md。如果改用git rm readme.md删除动作会同步记录进 Git 数据库并反映到暂存区这里我们刻意模拟「彻底删除」的场景随后提交该删除并确认工作区与暂存区都已不再包含该文件。发现误删后如何找回文档提到可以用git undo之类的思路回退最近一次提交但如果删除发生在若干次提交之前就不宜整体回退。正确做法是先用git log找到包含该文件的提交再用--source参数精确指定恢复来源git restore --sourceHEAD~1 README.md--source指明从哪个快照取文件HEAD~1表示上一个提交README.md指定要恢复的目标。执行后该文件会以未跟踪状态重新出现在工作目录中接着用前面学过的流程git add→git commit重新跟踪、暂存并提交即可。需要补充说明文档中提到的git undo并非标准 Git 内建命令Git 没有内置undo子命令实际回退提交通常使用git revert生成一个反向提交保留历史或git reset移动分支指针git restore --sourcerev file这种定点恢复方式既不触碰其他提交也不会误伤历史是最精准的选择。Rebase 与 Merge 的取舍git rebase与git merge被许多初学者视为 Git 的头号难题但首先要明确两者解决的是同一个问题——把某个分支的变更整合进另一个分支只是方式截然不同。设想一个典型场景从主分支main切出特性分支feature开发新功能期间 main 分支持续产生新提交。此时需要把 main 上的新内容同步进 feature。方式一merge合并git merge feature main这条命令把 main 分支合并进 feature 分支。合并是非破坏性的——现有分支不被动任何改动因此简单、安全。代价是每次需要并入上游变更时feature 分支都会多出一个「合并提交」merge commit如果 main 分支非常活跃这些与特性开发无关的合并提交会不断累积污染 feature 分支的历史使其难以阅读。方式二rebase变基git checkout feature git rebase mainrebase会把整个 feature 分支“搬移”到 main 分支的最新提交之上将 main 上的所有新提交纳入基础但与 merge 不同它不使用合并提交而是为 feature 分支的每一个原始提交重写为全新的提交对象从而形成一条线性的历史。最大的收益是极其干净的项目历史没有多余的合并提交提交序列近似一条直线对比两种方式的分支图可以直观感受到差异。但干净的代价同样真实重写历史具有危险性如果不遵循「rebase 黄金法则」Golden Rule of Rebasing即绝不要对已推送至共享仓库、他人正在使用的分支执行 rebase重写后的历史可能与协作者的本地记录产生冲突对协作流程造成灾难性影响丢失合并上下文rebase 抹去了「上游变更是在何时、以何种方式并入特性分支」的信息而 merge commit 恰恰保留了这一上下文。因此实践上的常见取舍是尚未推送、仅供本地开发的分支可以放心 rebase 换取整洁历史已经推送并共享的分支优先使用 merge 保证协作安全。仓库中的真实印证一个用 Git 驱动的大型学习项目本文所在的 90DaysOfDevOps 仓库本身就是 Git 实践的最佳案例从根目录的 README.md 与 _sidebar.md 维护项目导航到 2022.md、2023.md、2024.md 逐年沉淀学习路径再到2022/zh_tw/Days/下按天组织的 90 篇文档与配套截图、2022/zh_tw/的 语言版本 README背后都是第 38、39 天所讲的这套本地 Git 工作流修改 → 暂存 → 审阅 diff → 提交 → 必要时回退。你完全可以用本日所学命令git log --oneline --reverse、git show、git restore等在本仓库中实际演练观察一个真实开源项目的历史演进方式。学习路线预告接下来第 40 天将进入与 Git 协作平台集成的阶段届时本日掌握的 diff 审阅、历史查看与恢复能力会与 GitHub 等平台上的 Pull Request、Commit 审阅界面直接对应。小结本日共梳理了五类高频 Git 操作用git diff/git diff --staged查看变更并用git difftool可视化审阅用git log、git show、git ls-tree回看历史与快照用git restore --staged取消暂存用git restore .与git clean -fd丢弃本地修改用git restore --sourcerev file从旧快照定点恢复文件。最后厘清了merge与rebase的本质差异与应用边界。牢记两条铁律提交前必看 diff重写历史前必想协作——这些习惯将伴随你进入远程协作的下一阶段。赞分享文档/教程【免费下载链接】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 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列中 Git 本地工作流的核文档/教程90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复的完整实战指南90DaysOfDevOps 第 39 天Git 变更查看、取消暂存、丢弃与恢复的完整实战指南 本文是 90DaysOfDevOps 挑战中 Git 系列D文档/教程90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列对应仓库 2022 年英文档/教程上一篇OpenMed RTF 文本提取与脱敏指南控制流解析、源码偏移映射与写回机制下一篇Zephyr RTOS 在 Microchip PolarFire SoC Icicle Kitmpfs_icicle上的构建、烧录与调试实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考