Git技术问询：误在master分支修改后迁移代码及-s/-X ours合并用法

一、迁移误提交到Master的修改到Feature分支并撤销Master的提交 #

首先，你已经从Master分支checkout出Feature分支的操作是对的——因为当你基于当前的Master（包含误提交）创建Feature分支时，Feature已经自动继承了Master上的所有修改和提交记录。接下来只需要把Master分支回退到误提交之前的状态即可，这里分两种场景处理：

情况1：误提交还没有推送到远程仓库 #

这种情况可以安全地重置Master的提交历史：

• 切换回Master分支：git checkout master
• 撤销最后一次提交（保留修改到暂存区，如果之后需要调整还能复用）：

  git reset --soft HEAD~1
  

  如果你确定不需要保留这些修改，想直接回到误提交前的干净状态，可以用硬重置（注意：这个操作会永久丢弃修改，谨慎使用）：

  git reset --hard HEAD~1
  

情况2：误提交已经推送到远程仓库 #

此时不能用git reset（会改写远程历史，导致团队协作混乱），应该用git revert生成一个新的撤销提交：

• 切换回Master分支：git checkout master
• 创建撤销提交，将最后一次提交的修改完全回滚：

  git revert HEAD
  

  执行后Git会打开编辑器让你填写撤销提交的说明，保存后推送到远程即可：git push origin master

二、合并时-s/-X ours参数的用法 #

这两个参数都是Git合并时的策略选项，但作用差异很大，分清楚场景使用：

1. -s ours：完全忽略对方分支的合并策略 #

这个参数指定使用ours合并策略，当合并两个分支时，完全丢弃对方分支的所有修改，直接保留当前分支的全部内容，仅生成一个合并提交记录（用来标记合并事件，但实际没有合并任何对方的更改）。

使用场景：比如你想标记两个分支已经“合并”，但实际上不想采纳对方分支的任何修改，例如废弃旧分支时的标记操作。

示例命令：

# 切换到当前分支（比如feature）
git checkout feature
# 合并dev分支，但完全保留feature的内容
git merge -s ours dev

2. -X ours：冲突时自动选择当前分支版本的扩展选项 #

这个参数属于recursive默认合并策略的扩展选项，仅在合并出现冲突时生效：当文件的同一部分出现冲突时，Git会自动选择当前分支的版本来解决冲突；而没有冲突的部分，依然会正常合并对方分支的修改。

使用场景：合并分支时，你希望在冲突发生时默认使用自己分支的代码，减少手动解决冲突的工作量，但仍保留对方分支的无冲突修改。

示例命令：

# 切换到当前分支（比如feature）
git checkout feature
# 合并master分支，冲突时自动用feature的版本解决
git merge -X ours master

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