理解 git revert 和 git merge答案

【问题标题】：Understanding git revert and git merge理解 git revert 和 git merge
【发布时间】：2016-05-15 06:04:08
【问题描述】：

我刚刚犯了一个非常大的 git 错误，这让我意识到我不懂 Git。这就是发生的事情-

从 master 创建了一个私有分支，在该分支中进行了更改
将 master 拉入该分支。
切换到 master 分支（没有从 origin/master 拉，因此我的 master 分支没有最新的 master）
合并了我的私有分支并将其推送到主分支。
得到一个错误，说你不能不拉就不能推，我遵守并拉了主人。然后将它与我的提交一起推送。
在我的提交中，我从 master 提取到我的私有分支中并且不在我的本地 master 中的所有更改都在那里。
还原了提交，还原还原了我未进行的所有更改，并且所有这些更改的提交历史记录都消失了。

我不明白为什么单个文件的提交历史消失了。有人可以帮我理解这一点吗？

附：经验教训 - 总是先拉再推，经常拉

【问题讨论】：

Revert 不会破坏历史记录，只会恢复来自参数的提交。考虑将你的 master 重置为恢复之前的状态，这次恢复正确的提交。
@Basilevs 提交历史记录在那里，但如果单个文件提交历史记录丢失。我也觉得提交历史不应该被破坏，但不知道为什么文件的提交历史会丢失。

标签： git version-control merge

【解决方案1】：

还原了提交，还原还原了我未进行的所有更改，并且所有这些更改的提交历史记录都消失了。

提交历史记录应该仍然是该分支 (git log) 的一部分，或者至少在 reflog 中。
git revert 应该在现有提交之上创建一个新提交（其内容取消旧提交）。

一旦你找到了正确的提交，即。在您开始在您的私有分支中合并和恢复之前的那个，将所述私有分支重置为它（git reset --hard：确保您没有任何本地修改或先进行 git stash）

然后再试一次，这次先更新master（git pull）

【讨论】：

【解决方案2】：

当我们做一个git merge或者一个git pull，几乎等于git fetch and git merge的时候，有2种成功的结果，要么是快进(ff)合并，要么是非快进( no-ff) 合并。参考：git-merge。请看一下“FAST-FORWARD MERGE”和“TRUE MERGE”。

一些远程存储库可能有拒绝接受任何会导致非 ff 合并的推送的策略。在推送之前，最好始终确保您的本地分支是远程分支的正确超集。

这里的真超集，或严格超集，连同真子集，意味着它在数学中的含义。

如果Branch Master 类似于A-B-C-D，而Branch Private 类似于A-B-C-D-E-F，我们可以说Master 是Private 的真子集。从 Private 拉到 Master，或将 Private 推到 Master，或将 Private 合并到 Master，将进行快进合并。如果我们从 Master 拉到 Private，或者从 Master 推送到 Private，或者将 Master 合并到 Private，除了告诉你一切都是最新的，什么都不会发生。

如果 Branch Private 类似于 A-B-C-E，则 Master 不是 Private 的子集，反之亦然。拉、推、合并都会导致非快进合并。

这是我在日常工作中所做的：

git fetch origin master
git checkout -b master FETCH_HEAD
#change the code
git add .
git commit
#right before I am going to `git push`
git fetch origin master
git cherry HEAD FETCH_HEAD
#if there is any new commit in the remote master, `git cherry` will list it.
#if `git cherry` outputs nothing, which means the local master is a
#superset of the remote master, my `git push` will make a 
#fast-forward merge.
git push origin master:master
...
#else if `git cherry` outputs something, like `+ 12345667800abcdef`, 
#which measn someone else has updated the remote master, 
#my `git push` will make a non-fast-forward merge.
#suppose the local master is like `A-B-C-D` and the remote master is like `A-B-C-E-F`
git reset C --hard
git pull origin master
git cherry-pick D
#now the local master is like `A-B-C-E-F-D'`, which is now a proper 
#superset of the remote master
git push origin master:master

【讨论】：