文档/教程【免费下载链接】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 系列第 38 天文档 2022/ja/Days/day38.md 为核心骨架围绕一个本地 Git 仓库完整走查暂存Staging与变更Changing的日常流程如何用git init建立仓库、用git status观察状态、用git add/git commit产生项目快照以及删除、重命名、忽略文件的正确做法。读完你既能掌握一套可复制、可运行的本地版本控制操作清单也能理解每次提交背后的工作区—暂存区—仓库流转原理为后续接入 GitHub 等基于 Git 的服务打下基础。系列脉络为什么要用走查Walkthrough的方式学习在进入本文之前该系列已经铺垫了三天的内容Day 35 讲解了版本控制系统Version Control System的基本概念Day 36 完成 Git 的安装与配置Windows / Linux / WSL 下的git --version、git config等Day 37 梳理了 Git 基础命令速查表并澄清了Git 没有访问控制Git 太重等常见误解。第 38 天的文档开篇就点明动机我们已经覆盖了一些基础但把它们放进一个走查walkthrough里能让我更好地学习和理解我们为什么这样做。在接触 GitHub 这类基于 Git 的服务之前Git 在本地工作站上的能力已经足够强大。因此本文将沿用文档中的GitProjectSteps示例目录一步一步还原全部操作。从 git init 开始本地仓库的起点文档明确指出整个走查从我们在本地机器上创建了一个文件夹并用git init命令初始化它开始。在第 37 天的速查表中git init的完整定义是在指定目录中创建一个空的 Git 仓库语法为git init directory。在尚未初始化的目录中执行git statusGit 会提示当前目录还不是一个仓库not a git repository无法进行任何 Git 操作随后执行git initGit 会报告初始化成功并提示默认分支名为master新版 Git 也可通过配置修改默认分支名。初始化完成后文档提醒我们注意目录中出现了一个隐藏文件夹.git。文档原文2022/ja/Days/day38.md解释这就是 Git 仓库细节的存储位置也是我们分支branches和提交commits相关信息存放的地方。从源码结构可以推断.git目录内部通常包含objects/对象数据库存储每次提交的快照与文件内容、refs/分支与标签引用、HEAD当前分支指针、index暂存区文件等核心组成部分。理解这一点对后文理解暂存区和提交历史至关重要。理解三区域模型工作区、暂存区与提交历史要顺畅读懂本文后续的所有命令先建立 Git 最核心的三区域心智模型这也是第 37 天速查表中git status/git diff描述的底层依据区域含义相关命令工作区Working Directory你正在编辑的文件所在的普通目录日常echo、touch、编辑器编辑暂存区Staging Area / Index记录下一次提交要包含哪些变更的中间区域git add、git rm、git restore --staged仓库Repository / .git已提交快照的持久化历史数据库git commit、git log三者的流转关系是工作区改动 →git add→ 暂存区 →git commit→ 仓库新快照。第 38 天文档中的每个小节本质上都是在围绕这条流转链回答什么时候、用什么命令、把变更放到哪个区域。暂存文件git add 与你的第一次提交观察未跟踪文件假设我们在空目录中开始了第一天的编码工作创建了README.md文件。此时执行git statusGit 会告诉我们当前位于master分支、还没有任何提交并且README.md出现在**未跟踪文件Untracked files**列表中提示可以用git add 文件将其加入暂存区以便提交。文档特别强调了git status在这一步的价值2022/ja/Days/day38.md它知道这个新文件存在但我们还没有提交它。这正是暂存区的体现——新文件尚未进入下一次提交的候选清单。将文件加入暂存区执行暂存命令git add README.md再次运行git status输出中出现了之前没有的 **Changes to be committed待提交的变更**区块README.md显示为绿色的新文件new file。这就是暂存完成的效果变更已从工作区进入暂存区只差一次提交。产生第一个快照暂存完成后用如下命令提交形成项目的第一次快照first commit / first snapshotgit commit -m Meaningful message-m后面跟的是一条有意义的提交信息这样后续每次提交都能清楚看到这个提交改了什么。文档还观察到一个细节终端提示符中的黄色叉号变成了绿色对勾——这是作者所用终端主题在第 3234 天的 Linux 终端专题中有介绍对仓库状态是否干净的可视化反馈绿色即表示当前没有未提交的变更。提交变更git add . 与文本编辑器的力量项目继续演进我们很可能想添加更多文件、或修改已有文件。最朴素的做法是重复之前的流程# 创建或编辑文件 # 将所有变更加入暂存区 git add . # 提交 git commit -m meaningful messagegit add .会把当前目录下所有变更新增、修改、删除一次性加入暂存区适用于变更范围明确的场景。但文档指出一个问题如果想在提交信息里写清楚到底改了什么用-m直接塞进一句话并不理想——比如git commit -m Well, I changed some code because it did not work and when I fixed that I also added something new to the readme.md to ensure everyone knew about the user experience and then I made a tea.这虽然也能提交但显然不够清晰。文档推荐的方式是先git add再不带-m直接运行git commit让 Git 打开默认文本编辑器本例中是 nano来撰写提交信息。具体操作流程对应 2022/ja/Days/day38.md修改文件后先运行git status确认哪些已暂存、哪些未暂存用git add将文件加入暂存区直接运行git commitGit 会打开默认编辑器nano在编辑器中编写短描述第一行作为提交标题和长描述空行之后的正文作为补充说明保存并退出编辑器提交完成。这种标题 正文的提交信息结构是 Git 社区通行的惯例第一行是精炼的摘要正文可以解释动机、影响范围或补充细节为后续git log阅读历史留下充分的上下文。提交最佳实践何时提交、如何措辞文档专门用一节总结提交的实践原则2022/ja/Days/day38.md这些原则至今仍是团队协作的通用规范经常提交commit often不要等到整个项目完成才提交。每一次提交都应是一个有意义的、可独立回退的节点。提交之间不要耦合无关任务如果同时存在一个 bug 修复和一处拼写错误最佳实践是把它们分成两个独立提交便于日后单独查看、回滚或 cherry-pick。让提交信息有含义git log显示的只是一行行文字信息写得越清楚未来的你和队友越容易定位变更。保持措辞一致团队或个人应在每次提交中使用统一的口径与风格如统一使用祈使句、统一前缀如fix:/feat:让历史记录整齐可读。跳过暂存区git commit -a 的便利与风险我们是否总是必须在提交前暂存变更文档的回答是答案是肯定的但不要把这当作捷径——你必须 100% 确认自己不需要那个快照来回滚这是一件有风险的事。在实际操作中Git 提供了一个跳过显式暂存步骤的开关git commit -a-a即--all。它会自动暂存所有已跟踪tracked文件的修改并直接提交。注意它的关键限制只对已经被 Git 跟踪的文件生效新增的未跟踪文件仍需先用git add加入。使用-a的风险在于你跳过了先看暂存区内容再决定这一道检查工序万一工作区里混有不想提交的修改它们会被一并打包进快照。因此文档的忠告非常明确——只有在你对变更内容有 100% 把握时才使用。删除文件两步流程与一条命令的 git rm项目里难免有不再需要的文件。文档以目录中的oldcode.ps1为例该仓库 2022 系列 的 Day 38 原文亦使用同一示例提醒一个容易踩的坑仅仅因为我们从目录中删除了文件Git 仍然感知到这个文件我们还必须把它从仓库中移除。也就是说只删除工作区文件是不够的——暂存区index中仍保留着该文件的记录。常规的两步流程是先在操作系统中删除文件再通过git add或git rm把这个删除动作加入暂存区。对于文件多、变动频繁的大型项目这种两步骤既难记又繁琐。文档给出的推荐做法是用一条命令完成删除工作区文件 从 Git 跟踪中移除git rm oldcode.ps1从截图中可以还原完整链路git rm oldcode.ps1输出rm oldcode.ps1随后git ls-files确认该文件已从 Git 跟踪列表中消失git status显示deleted: oldcode.ps1删除已进入暂存区git commit -m remove file the easy way提交后git status回到nothing to commit, working tree clean整个删除操作完成。补充一点与第 39 天相衔接的知识如果只想把文件从暂存区移除停止跟踪但保留工作区文件则应使用git rm --cached file这在后文忽略文件场景中会再次用到。重命名与移动文件git mv和删除类似在操作系统里重命名或移动文件Git 同样需要两步走先在 OS 层面改动文件再更新暂存区确保文件的新的名字/位置被正确记录。两步流程示意对应 2022/ja/Days/day38.md# 第一步在操作系统中重命名 mv oldname.md newname.md # 第二步让 Git 感知这个变更 git add oldname.md # 记录删除 git add newname.md # 记录新增而和git rm一样Git 也提供了一条命令的等价操作git mv oldname.md newname.mdgit mv会同时完成移动工作区文件和更新暂存区中的跟踪记录避免两步操作遗漏尤其适合批量重命名或移动文件时的场景。忽略文件.gitignore 与 git rm --cached为什么要忽略文件项目中常常存在只在本地使用或分享出去纯属浪费空间的文件文档给出的两个典型例子是日志logs运行日志会不断膨胀提交进仓库既占体积又制造噪音密钥secrets不想在公开场合或跨团队共享的敏感信息绝不能进入仓库。创建 .gitignore忽略的办法是在项目目录中创建.gitignore文件把要忽略的文件或文件夹写进去。文档的演示流程是# 观察当前目录与 logs 内容 ls ls logs # 查看 git 状态确认 logs/ 是未跟踪目录 git status # 写入忽略规则 echo logs/ .gitignore # 查看包含隐藏文件的目录列表确认 .gitignore 已创建 ls -la此后再次运行git statuslogs/目录就不再出现在未跟踪文件列表中被 Git 静默忽略。关于.gitignore的写法原文档以logs/目录为例。作为通用知识补充除了目录还可以写单个文件如secret.txt、通配符模式如*.log、*.tmp、以及带感叹号的否定模式如!important.log每行一条规则#开头的是注释。值得一提的是这个仓库本身就是.gitignore的活教材仓库根目录的 .gitignore 文件内容为.DS_Store——忽略 macOS 自动生成的元数据文件避免这类系统文件污染提交历史。这是忽略与项目无关的系统/本地文件的典型真实案例。对已跟踪文件反悔git rm --cached文档特别指出一种容易遇到的情况2022/ja/Days/day38.md也许你之前确实想分享 logs 文件夹但后来意识到并不想分享。此时仅仅在.gitignore中加上logs/是不够的——因为该目录已经被 Git 跟踪.gitignore只对未跟踪文件生效。正确的做法是先把它从暂存区跟踪列表中移除git rm --cached logs/ -r--cached的含义是只从索引/暂存区移除不删除工作区文件。执行后该目录变为未跟踪状态.gitignore中的规则随即生效后续的变更不会再进入提交。第 39 天文档中的git restore --staged命令也承担类似职责取消暂存可以一并对照学习。简短状态git status -s 与别名git status信息详尽但大多数时候我们只想知道什么被修改了、什么是新文件。Git 提供了精简输出git status -s-s--short会以紧凑格式逐行列出状态M已跟踪文件被修改M在第一列表示已暂存的修改在第二列表示未暂存的修改??未跟踪的新文件A、D、R等分别对应已暂存的添加、删除、重命名。由于git status -s使用频率极高文档作者表示通常会在系统上设置别名来简化输入。结合第 37 天速查表中git config --global alias的用法可以这样配置git config --global alias.s status -s # 之后即可用 git s 代替 git status -s第 37 天的速查表还给出了git config --global user.name/user.email、core.editor等配置项这些是提交信息正确署名的前提2022/ja/Days/day37.md。命令速查Day 38 全量命令一览为便于检索与实战引用将本文涉及的本地仓库操作命令汇总如下场景命令作用初始化git init在当前目录创建空的 Git 仓库生成.git隐藏目录查看状态git status列出已暂存、未暂存与未跟踪的文件精简状态git status -s以M/??等短码精简显示仓库状态暂存git add file将指定文件加入暂存区暂存全部git add .将当前目录下所有变更加入暂存区提交git commit -m msg提交暂存快照并附上消息编辑器提交git commit打开默认编辑器如 nano撰写短/长提交信息跳过暂存提交git commit -a自动暂存已跟踪文件的修改并提交有风险删除文件git rm file删除工作区文件并从 Git 跟踪中移除取消跟踪git rm --cached file从暂存区移除跟踪记录但保留工作区文件重命名git mv old new重命名/移动文件并同步更新跟踪记录忽略编辑.gitignore按规则忽略文件/文件夹如logs/、*.log别名git config --global alias.s status -s为高频命令创建快捷别名下一步Day 39 与系列衔接文档结尾提到在明天的文章中我们将继续通过这些常见 git 命令的简短示例来学习。后续的 Day 39 正是承接本文的内容主题为查看、取消暂存、丢弃与恢复Viewing, unstaging, discarding restoring覆盖git diff、git difftool、git log、git show、git restore、git clean以及 rebase 与 merge 的对比。本文提到的git rm --cached、git commit -a带来的回滚需求都将在 Day 39 找到完整的恢复手段。至此本地仓库的文件生命周期管理闭环已经完整建立git init→ 暂存git add→ 提交git commit→ 变更git add . / commit→ 删除git rm→ 重命名git mv→ 忽略.gitignore git rm --cached→ 精简观察git status -s。这些能力全部在本地工作站即可实践也是进入 GitHub、GitLab 等基于 Git 的协作服务前必须打牢的地基——正如文档所说现在的一切本地操作在接入那些工具后都会变得同样有用。原文档的 Resources 部分收录了一批视频教程与速查表资源版本控制概念、Git 新手教程、Git 专业教程、Git 速查表等在仓库内部可以继续对照阅读第 3539 天的系列文档并在 Day 37 速查表 中查阅分支、重置、rebase、push 等进阶命令的完整说明。赞分享文档/教程【免费下载链接】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 之 Git 暂存与变更从 git init 到 .gitignore 的本地仓库全流程实操90DaysOfDevOps 之 Git 暂存与变更从 git init 到 .gitignore 的本地仓库全流程实操 本篇文章承接 90DaysOfDev文档/教程90DaysOfDevOps 实战篇Git 暂存Staging与变更管理从 git init 到 .gitignore 的本地工作流全解析90DaysOfDevOps 实战篇Git 暂存Staging与变更管理从 git init 到 .gitignore 的本地工作流全解析 导读本文是文档/教程90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南90DaysOfDevOps Day 39Git 变更查看、取消暂存、丢弃与恢复实战指南 本篇是 90DaysOfDevOps 系列对应仓库 2022 年英文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考