git stash暂存本地修改安全拉取技巧

当你为了本地部署而修改了项目中的配置文件时，如何既保留自己的修改，又能顺利地从远程仓库拉取（git pull）未来的更新，而不会每次都遇到冲突。

方法一：使用 git stash (最推荐的工作流)

这个方法可以被理解为“暂时保管你的修改”。它非常灵活和安全。
工作流程如下：

1. 保存你的本地修改
   在你准备 git pull 之前，运行这个命令：
   1

   git stash

   这个命令会把你所有已修改但还未提交的文件（比如你改过 docker-compose.yml）打包起来，放进一个“储藏室”，然后你的工作目录会变得“干净”，回到和上次提交时一模一样的状态。
2. 拉取远程更新
   现在你的工作目录是干净的，可以毫无冲突地拉取远程更新了：
   1

   git pull

3. 恢复你之前的修改
   拉取成功后，再把刚才储藏起来的修改拿出来，应用到新的代码上：
   1	git stash pop

   git 会很智能地尝试把你当初的修改（image: -> build:）重新应用到更新后的 docker-compose.yml 文件上。
   如果 git stash pop 时发生冲突怎么办？

• 这种情况很少见，除非远程仓库的作者也正好修改了 docker-compose.yml 的同一行。
• 如果真的发生了，Git 会提示你文件中有冲突，并用 <<<<<, =====, >>>>> 标记出来。
• 你只需要再次手动编辑 docker-compose.yml 文件，解决冲突（比如保留你的 build: . 修改），然后保存文件，并执行 git add docker-compose.yml 来告诉 Git 你已经解决了冲突。
  优点：非常安全，你总是能看到远程仓库对配置文件的修改，不会错过重要的更新。

方法二：使用 Override 文件 (一劳永逸的最佳实践)

很多项目，特别是使用 Docker 的项目，都支持一种“覆盖”机制。这是处理自定义配置的 最优雅、最推荐 的方式。
对于 Docker Compose，它会自动寻找一个叫 docker-compose.override.yml 的文件，并把它里面的配置与 docker-compose.yml 的配置合并。
具体操作：

1. 不要修改 docker-compose.yml 文件！ 保持它从 git 拉下来时的原样。
2. 在同一个目录下， 创建一个新文件 ，命名为 docker-compose.override.yml 。
3. 把你 需要修改的配置 写在这个新文件里。例如，你想把 image 改成 build ，你的 docker-compose.override.yml 文件内容就应该是：
   1 2 3 4 5 6 7

   # docker-compose.override.yml services:   new:     build: .     # 你还可以在这里覆盖其他配置，比如端口     # ports:     #  - "8080:3000"

4. 把这个 override 文件加入 .gitignore ，这样 git 就会彻底忽略它，你永远不用担心它会引起冲突。
   1 2	# 把文件名追加到 .gitignore 文件末尾 echo "docker-compose.override.yml" >> .gitignore

这样做的好处：

• 彻底分离 ：你的本地配置和项目的基础配置完全分开了。
• 无冲突 ：因为 docker-compose.yml 文件你从未动过，所以 git pull 永远不会和它冲突。 docker-compose.override.yml 被 .gitignore 忽略， git 也看不见它。
• 优雅 ：当你运行 docker compose up 时，Docker 会自动读取两个文件，将配置合并，实现你想要的效果。

方法三：让 Git “假装看不见”你的修改 (简单但有风险)

如果你确定这个文件你永远只想用你本地的版本，并且不关心远程的更新，可以用这个方法。
操作命令：

1
2

# 告诉 Git，以后请忽略对这个文件的改动
git update-index --assume-unchanged docker-compose.yml

执行这个命令后，git 就会“假装” docker-compose.yml 文件没有被修改过。

• 你运行 git status，不会看到它被列为 “modified”。
• 你运行 git pull，git 也不会尝试合并远程的 docker-compose.yml 文件，因此永远不会冲突。
  ⚠️ 重要警告：
  这是一个有风险的操作。如果项目作者在未来的更新中对 docker-compose.yml 做出了重要修改（比如添加了新的必需服务、修改了端口、增加了关键的环境变量），你将会完全错过这些更新，可能导致你的应用无法启动或运行不正常。
  如何撤销这个操作？
  如果你想重新让 Git “看见”这个文件的改动，并接收远程更新，可以运行：

1

git update-index --no-assume-unchanged docker-compose.yml

方法四： 修改了核心代码

如果你修改了核心代码，比如修复了 Bug 或开发了新功能，那么你应该使用 Git 分支 (Branch) 来管理你的代码。这是 Git 最核心的功能之一。
标准工作流程：

1. 为你的修改创建一个新分支 不要在 main 或 master 主分支上直接修改！
   1 2	# 创建一个叫 my-feature 的新分支，并切换过去 git checkout -b my-feature

2. 在新分支上进行修改和提交 你可以随心所欲地修改任意文件，然后把它们提交到你的 my-feature 分支上。
   1 2 3

   # 修改文件... git add . git commit -m "我增加了 xxx 功能"

   现在，你的所有修改都安全地保存在 my-feature 分支里了。
3. 需要更新时，先更新主分支
   1 2 3 4 5

   # 1. 切换回主分支 git checkout main # 2. 拉取远程更新 git pull

4. 合并主分支的更新到你的功能分支
   1 2 3 4 5

   # 1. 切换回你的功能分支 git checkout my-feature # 2. 把 main 分支的最新代码合并进来 git rebase main

   rebase (变基) 是一种更高级的合并，它会把你分支上的提交，一个个地在最新的主分支代码上“重放”一遍。这能保持你的提交历史非常干净。
   • 如果在 rebase 过程中出现冲突， git 会提示你，并让你手动解决。
   • 解决完后继续 rebase 过程即可。这比一次性处理所有冲突要容易得多。