我怀疑＆＃34; git revert＆＃34;
没有互联网连接。当互联网连接到来时，我已经做了4次提交。 然后互联网连接到了。在我推动之前我必须拉。所以我拉，它导致自动合并发生（没有任何冲突）。此合并创建为另一个（第5次提交） 最后，我推动所有＆＃34;五，＆＃34;提交gitlab。
如果我的经理确实＆＃34; git revert＆lt; 5th commit SHA＆gt;，那么从我的第一次提交到第5次提交的所有更改都会消失吗？ 如果是，那为什么呢？ 如果不是，那么当其他人拉出时，gitlab上会有多少次提交？
注意 - 一切都发生在主分支上。此处不会创建辅助分支。
答案 0 :(得分：1)
您（或您的经理）需要了解revert。
首先，它不会删除提交。它创建一个新的提交，撤消一个或多个旧提交的更改。
其次，如果要还原合并提交，还需要指定要还原到哪个合并的父项。这很重要，因为您的“第5次”提交是合并。
最后，如果您执行还原合并，则以后很难重新引入撤消的更改。该文档声明您告诉git您永远不会想要合并的还原方。
所以你推后的东西是
x --- x --- x --- A --- B --- C --- D --- M
\ /
o --- o --- o --- o --- O
x是您（和遥控器）在您开始工作之前提交的。
o和O是您在“离线”时出现在遥控器上的提交。
A到D是您的提交。
M是您在pull编辑时由git创建的合并。此合并将D视为父级1，将O视为父级2。
现在，如果你说
git revert -m 1 <SHA-of-M>
这表示“将M还原为D”。这将有效撤消所有o提交以及O。另一方面，
git revert -m 2 <SHA-of-M>
这表示“将M还原为O”。这将有效撤消A，B，C和D。
但同样，此不会删除提交。它也不会从分支历史中删除提交。结果将是
x --- x --- x --- A --- B --- C --- D --- M --- W
\ /
o --- o --- o --- o --- O
TREE处的W（内容）与TREE上的D或TREE上的O相匹配（具体取决于哪个）您指定的-m选项。
并重申：不仅合并一方的所有提交都有效撤消，而且重新执行它们并不容易，因为git认为它们是由M“占用”的。 / p>
如果您（或您的经理）试图从历史记录中删除“不必要的提交”，那么您必须进行历史记录重写。有几种方法可以做到这一点; revert不是其中之一。影响已推送的提交的任何历史记录重写都会产生与之相关的成本。合并提交“丑陋”或“不必要”的观点是一个观点问题;我怀疑在大多数情况下成本是否合理。但是要进行一些编辑：
一个可行的程序（假设您的本地master仍在M）：
1）创建一个临时分支并将其移至O
git checkout master
git checkout -b o_master
git reset --hard HEAD^2
2）将master移至D
git checkout master
git reset --hard HEAD^
3）使用rebase创建线性历史
git rebase o_master master
git branch -d o_master
您可能必须在rebase期间解决一些冲突;请参阅git rebase docs。
这给出了移动提交的外观，所以你有
x --- x --- x -- o --- o --- o --- o --- O --- A' --- B' --- C' --- D'
您有一些新的提交（A'到D'）;每个都是原始提交的替代品（A到D）。 A'，B'和C'处的代码状态未经测试，可能无法编译或可能出现故障，这可能会影响将来的调试工作;所以你应该测试它们。 D' 的代码状态应该等于M之前的代码状态（因此可能是经过测试），但这并非100％保证（出于各种原因，但特别是如果要解决冲突的话，那么最好验证（对D'进行测试{或D'，或者至少差异M。
接下来你会做一个“强制推动”。
git push -f
此时，您已重写了远程历史记录。当您仍尚未删除任何提交时，您已从master引用中删除了一些旧提交。这意味着您的所有同事都必须更新，并且他们所做的任何工作（基于M）必须重新定位到D'。有关此问题的更多详细信息，请参阅git rebase文档中的“从上游rebase恢复”。
从技术上讲，所有旧提交仍然存在，但默认情况下它们不可见，因为您已将它们从refs的历史中删除。如果您需要将它们物理删除，那就是另一个多步骤过程。