如何在重置/变基上游仓库后正确使用Git stash？

问题场景回顾 #

本地基于基线A开发出修改B（已通过stash暂存），远程上游仓库已从A更新到C，目标是将本地仓库变基到C，并把B的修改应用到C之上：

Remote: A -> C ---
             ---^
             |
Local:  A -> B

之前执行的操作导致远程C的变更丢失：

git stash push                # 暂存当前HEAD B的修改
git fetch remote
git reset --hard remote/main  # 将本地HEAD设为远程C
git stash pop                 # 尝试把B合并到C

错误原因 #

git stash pop存储的是基于A的修改补丁，直接合并到C（A的后续版本）时，若文件存在重叠修改，要么Git自动合并时因上下文不匹配导致错误覆盖C的变更，要么手动解决冲突时误删了C的内容。这种补丁合并方式不符合变基的需求，容易出问题。

正确操作方案 #

方案一：使用git rebase（推荐，完全符合变基需求） #

情况1：B是未提交的修改（仅stash暂存）

1. 回到原开发分支（比如main），此时本地HEAD还是A：

   git checkout main
   

2. 恢复stash的修改到工作区：

   git stash pop
   

3. 将B的修改提交为本地提交：

   git add .
   git commit -m "feat: 完成B的修改"
   

4. 拉取远程最新的C版本：

   git fetch remote
   

5. 执行变基，将B的提交重放到C之后：

   git rebase remote/main
   

   • 若出现冲突，解决冲突后执行git rebase --continue；若要放弃变基，执行git rebase --abort

情况2：B已提交但被误存到stash

1. 从stash创建临时分支并恢复修改：

   git stash branch temp-branch
   

2. 检查修改后提交（若未提交）：

   git add .
   git commit -m "feat: 完成B的修改"
   

3. 拉取远程最新版本：

   git fetch remote
   

4. 变基到远程C：

   git rebase remote/main
   

5. 之后可将临时分支合并回原开发分支，或直接使用该分支推送

方案二：使用git pull --rebase（简洁版，适合已提交B的场景） #

如果B已经是本地提交，直接执行：

git checkout main
git pull --rebase remote main

该命令等价于git fetch remote && git rebase remote/main，自动将本地B提交重放到远程C之后。

方案三：使用git cherry-pick（适合B是单个独立提交的场景） #

1. 拉取远程最新版本：

   git fetch remote
   

2. 将本地分支重置到远程C：

   git reset --hard remote/main
   

3. 找到B提交的哈希值（可通过git log --oneline在原分支或stash记录中查询）：

   git log --oneline
   

4. 将B的提交应用到C之后：

   git cherry-pick <B的提交哈希>
   

   • 冲突处理方式同变基，解决后执行git cherry-pick --continue

内容的提问来源于stack exchange，提问作者SwiftMango