修改代码前，怎样备份并保留原代码

改代码前先留一份可恢复的原状，能降低试错成本，也能让重构、升级和自动化工具生成的改动更容易检查。这里的“备份”不只有复制整个文件夹：对 Git 项目，提交一个检查点通常更清晰；对未纳入版本控制的文件，可以单独复制；对小范围改动，补丁文件也能保存差异。

不同方法适合不同情况。关键不在于备份形式有多复杂，而在于事先弄清楚要保存的内容、保存到哪里，以及需要恢复时怎样确认没有误覆盖。

一、先确认要保留的“原代码”是什么

动手前，先区分下面几类内容。它们并不总会被同一种备份方式覆盖：

• 已提交的代码：Git 仓库中已有提交的文件，可以通过历史记录恢复。
• 已跟踪但尚未提交的改动：工作区中修改过的文件。它们不属于当前提交，需要额外保存。
• 未跟踪的新文件：尚未纳入 Git 的文件，例如新建的脚本或配置。普通的 Git 差异命令通常不会显示它们。
• 仓库之外的内容：本地配置、数据文件、密钥、编辑器设置等，未必在项目仓库中。

如果不先检查这几类内容，可能出现“看起来存了差异，恢复时却少了新文件”或“代码还原了，本地配置却丢了”的情况。数据库、上传文件和运行环境也不能简单等同于源代码备份：它们往往需要单独设计备份与恢复流程。

二、Git 项目优先使用提交检查点

在 Git 仓库里，最容易理解、也最便于审查的办法，是在开始修改前建立一个提交。提交会把纳入版本控制的文件状态记录在历史中，之后可以比较、切换分支或从特定提交取回文件。

先确认当前目录和仓库状态：

pwd
git status --short --branch
git branch --show-current

检查输出中的修改、删除和未跟踪文件。尤其要留意未跟踪文件：它们不会因为已经出现在文件夹里，就自动包含在提交中。需要检查忽略规则时，可以使用：

git status --short --ignored

确认要保存的改动后，可以建立检查点：

git add -A
git status
git diff --cached
git commit -m "修改前检查点"

git add -A 会暂存当前目录范围内已跟踪文件的修改、删除，以及未被忽略的未跟踪文件。运行前后都应检查状态，避免把不该提交的文件、密钥或本地数据一起提交。git diff --cached 展示已暂存的内容；只有确认暂存区符合预期后，才提交。

检查点提交并不意味着要把临时改动推送到远端。提交可以只存在本地。它的价值在于给当前状态一个可识别的锚点，而不是替代代码审查或团队提交规范。

用独立分支隔离试验

如果接下来要做较大的重构、尝试 AI 生成的改动，或运行可能改写很多文件的工具，可以在干净状态下新建分支：

git switch -c experiment/refactor-before-change

分支让试验中的提交与原分支分开，但它不会自动保存尚未提交的工作区改动，也不会让危险命令变得安全。创建分支前仍要检查 git status。完成后，可以逐个比较和挑选提交；如果试验失败，回到原分支即可。不要为了“清理现场”而随意运行会丢弃改动的命令。

三、补丁适合保存差异，不等于完整备份

有时不方便提交，或者只想把当前差异存成文件，可以导出补丁：

git diff --binary HEAD > before-change.patch

这会保存相对于 HEAD 的已跟踪文件差异，包括已暂存和未暂存的改动；--binary 用于让 Git 差异格式包含二进制文件的变更信息。它不会包含未跟踪文件，也不会自动保存被忽略的文件、仓库外内容或运行环境。补丁文件应放在仓库之外，或确认它不会被后续操作覆盖。

查看补丁包含哪些内容：

git apply --stat before-change.patch
git apply --check before-change.patch

--check 用于检查补丁能否应用，不会实际应用补丁。需要恢复时，先确认工作区状态和目标分支，再执行：

git apply before-change.patch

补丁应用依赖目标文件与补丁记录的上下文。目标代码变化较多时，应用可能失败；即使成功，也应该检查差异。补丁不是加密文件，也可能包含密钥、内部地址或个人信息，不要因为它只是“文本差异”就随意上传。

如果只想保存已暂存的差异，可用 git diff --cached；只保存未暂存差异则用 git diff。这些命令同样不会自动包含未跟踪文件。

四、Git 之外：复制一份独立目录

对于没有 Git 的项目、需要保留仓库外文件，或需要做一次可直接对照的目录快照，可以将项目复制到另一个位置。备份目录不要放在源目录内部，否则可能把备份再次复制进去，造成递归、容量膨胀或难以辨认的快照。

下面的 Python 示例会把指定目录复制到一个新的目标目录；目标路径已经存在时会报错，不会合并或覆盖。它保留符号链接本身，而不是跟随链接复制链接目标：

from pathlib import Path
from shutil import copytree
import sys

if len(sys.argv) != 3:
    raise SystemExit(
        "用法: python backup_dir.py 源目录 目标目录"
    )

source = Path(sys.argv[1]).expanduser().resolve()
destination = Path(sys.argv[2]).expanduser().resolve()

if not source.is_dir():
    raise SystemExit(f"源目录不存在或不是目录: {source}")

if source == destination or source in destination.parents:
    raise SystemExit("目标目录不能与源目录相同，也不能位于源目录内部")

if destination.exists():
    raise SystemExit(f"目标路径已存在，拒绝覆盖: {destination}")

copytree(source, destination, symlinks=True)
print(f"已复制到: {destination}")

将代码保存为 backup_dir.py 后，可以这样运行：

python backup_dir.py ./my-project ./backups/my-project-before-change

部分系统使用 python3 命令启动 Python，可相应替换。目标目录的父目录需要存在，且当前用户要有读取源文件、创建目标目录的权限。脚本适合普通文件目录复制，不提供加密、压缩、版本管理、远程存储或数据库一致性保障；复制期间源目录若持续变化，得到的副本也可能不是同一时刻的完整快照。含有正在写入的数据文件时，应先让相应程序安全关闭或使用该程序提供的备份方式。

复制整个 Git 仓库通常也会复制 .git 历史，占用更多空间；如果只是保存代码状态，可以优先考虑提交或建立分支。反过来，如果项目依赖仓库之外的文件，单靠 Git 也不够，应明确列出这些文件并用适当方式单独保存。

五、选择合适的方法

六、修改前的最小检查清单

1. 确认位置：确认当前目录、仓库根目录和目标分支，避免在错误的项目副本中操作。
2. 确认状态：查看已修改、已删除和未跟踪文件；知道哪些文件被忽略。
3. 选定备份边界：决定是否需要保存仓库外配置、数据文件、生成物或本地脚本。
4. 避开敏感信息：不要把访问令牌、私钥、密码和生产数据放进不可信的远端、公共补丁或共享目录。
5. 确认备份可用：查看提交、补丁或复制结果确实存在；重要文件可抽查内容、大小或哈希。
6. 再开始修改：一次只改变有限范围，完成后查看 git diff 和测试结果。

对于重要备份，可以生成 SHA-256 摘要，用来比较文件内容是否一致，但摘要本身不是备份，也不能证明备份一定可恢复。示例命令：

sha256sum before-change.patch

在没有 sha256sum 的系统上，可使用系统自带的校验工具；例如 Windows PowerShell：

Get-FileHash .\before-change.patch -Algorithm SHA256

七、恢复时先比较，再替换

恢复不是“把旧文件一股脑覆盖回去”。先检查当前状态和备份内容，确认要恢复的文件、版本以及是否有备份之后产生的新改动。使用 Git 时，可以比较两个提交或分支：

git diff main...experiment/refactor-before-change

如果只想查看某个文件在检查点中的内容，可以先输出到临时文件检查，而不是直接覆盖当前文件：

git show <提交号>:path/to/file > /tmp/file-from-checkpoint

其中 <提交号> 和 path/to/file 需要替换为实际提交号与仓库内路径。这个命令会写入指定的临时路径；若该路径已存在，重定向会覆盖它。因此，应选择明确的临时文件名并确认目标位置。确认内容后，再决定如何取回文件。不同 Git 版本与工作区状态下，恢复命令的选项和影响范围可能不同，执行前应阅读命令帮助并检查工作区，尤其避免误用会丢弃本地修改的强制选项。

用目录副本恢复时，建议先比较文件清单和内容，再逐个取回需要的文件。直接用整份旧目录覆盖新目录，可能把后来新增的文件删除，也可能带回已经过期的配置。若项目有构建产物或用户数据，更要区分“代码文件”和“运行时文件”。

八、常见错误与边界

1. 以为 git diff 包含所有文件

默认差异主要针对已跟踪文件；新建但未跟踪的文件不会出现在普通的 git diff 输出里。用 git status --short 检查新文件，必要时在确认内容后纳入暂存或另行复制。

2. 把 git stash 当成完整、长期备份

git stash 适合暂时收起部分工作区改动，但它有自己的范围和使用规则。默认行为通常不会保存未跟踪文件；可用 git stash push -u 把未跟踪文件一并收起，但被忽略的文件仍不会因此自动包含。存储在本地仓库中的 stash 也不等于独立异地备份。使用前后查看状态和 stash 列表，并在长期保留需求下优先采用清晰的提交或独立副本。

3. 复制到源目录里面

备份目录嵌套在源目录中，容易造成重复复制和空间增长。将目标放到源目录之外，或使用 Git 提交管理代码历史。

4. 只备份文件，没验证能否恢复

“复制命令执行完了”不代表关键内容都在。抽查目录结构、未跟踪文件和重要配置；对特别重要的项目，定期在临时位置演练恢复。备份策略是否有用，最终要看能不能取回所需内容。

5. 把敏感文件提交或外传

备份可能包含密钥、凭证、个人信息或业务数据。Git 提交、补丁文件和目录副本都可能泄露这些内容；是否安全取决于存储位置、访问权限、加密和保留策略。检查仓库忽略规则并不能替代安全审查。若凭证意外进入版本历史，应按泄露事件处理，及时撤销或轮换凭证；仅从当前目录删除文件，不能自动抹去已有历史副本。

6. 忽视外部依赖和运行状态

代码备份不包含数据库状态、容器镜像、系统依赖、云端资源或第三方服务配置。若恢复目标是完整恢复一个可运行系统，就需要另行记录依赖版本、配置来源、数据备份和部署步骤。不要把“源码能恢复”说成“服务一定能恢复”。

结语

对 Git 项目，先看状态、再做检查点提交，是多数代码修改前最直接的办法；试验范围大时，可以加上独立分支。补丁适合保存差异，但不包含未跟踪文件；目录副本可以覆盖 Git 之外的内容，却需要控制复制范围、权限和敏感数据。无论选择哪一种，都要在修改前说清保存了什么，并在需要时验证能否恢复。这样做不复杂，却能让后续修改更从容，也更容易定位问题。