Git撤销合并提交提示‘Already up to date’的原因及相关疑问

可复现测试场景 #

测试代码 #

mkdir git_test
cd git_test
git init
touch test.txt
echo "asdf" >> test.txt
git add test.txt
git commit -m "added file"
echo "asdf2" >> test.txt
git add -u
git commit -m "added another line in main"
git checkout -b feature
echo "asdf3 in feature" >> test.txt
git add -u
git commit -m "added a third line in feature"
echo "asdf4 in feature" >> test.txt
git add -u
git commit -m "added 4th line in feature"
git checkout master
echo "adding line 3 in main" >> test.txt
git add -u
git commit -m "added line 3 in main"

场景一 #

直接将feature合并到master并解决冲突后，执行git revert -m 1 [提交哈希]可成功撤销合并提交（因模拟公共分支，不使用git reset）。

场景二 #

先将master合并到feature并解决冲突，再合并feature到master，此时执行git revert -m 1 [合并提交哈希]，提示Already up to date! On branch master \n nothing to commit, working tree clean，无法完成撤销。

我的疑问 #

1. 为何第二种场景无法撤销合并提交？
2. 若HEAD为合并提交，它实际包含什么内容？
3. 撤销合并提交的本质是什么？合并提交是否仅标记合并事件？
4. 能否仅撤销feature分支中的部分提交，而非整个合并操作？

问题解答 #

1. 第二种场景无法撤销合并提交的原因 #

当你先把master合并到feature，再将feature合并到master时，Git会执行快进合并（Fast-forward Merge）——此时feature的提交历史已经包含了master的所有提交，master只需直接移动指针到feature的最新提交即可，不会生成新的合并提交。你试图撤销的“合并提交哈希”要么不存在，要么就是feature的最后一个普通提交，而非真正的合并提交。

当你执行git revert时，Git发现当前master的状态和撤销后的状态完全一致，因此提示“Already up to date”。本质是场景二中没有可撤销的合并提交。

2. HEAD为合并提交时的内容 #

合并提交是特殊的提交，它包含两个父提交：一个是当前分支合并前的最后提交，另一个是被合并分支的最后提交。

从内容上看，合并提交的文件内容是合并冲突解决后的最终状态——不是两个父提交内容的简单叠加，而是手动解决冲突后、或Git自动合并无冲突内容后的结果。同时，合并提交的元数据会记录两个父提交的哈希，标记本次合并的分支来源关系。

3. 撤销合并提交的本质与合并提交的作用 #

• 撤销合并提交的本质：git revert -m 1 <合并提交哈希>并非删除合并提交，而是生成一个新提交，将当前分支恢复到合并前的状态（即-m 1指定的第一个父提交的状态）。它会抵消合并提交带来的所有代码变更，但保留合并提交的历史记录。
• 合并提交的作用：它不只是标记合并事件，还承载了合并后的最终代码状态，以及分支合并的历史关系。通过合并提交，Git可以追溯两个分支的合并点，明确代码的来源。

4. 能否仅撤销feature分支的部分提交 #

可以，不需要撤销整个合并。你可以直接针对feature分支中需要撤销的单个提交执行git revert <提交哈希>：

• 如果该提交已经合并到master，直接在master上执行git revert会生成新提交，抵消该提交的代码变更。
• 如果该提交在合并时产生过冲突，执行git revert可能需要重新解决冲突，但流程和普通提交的撤销一致。

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