【发布时间】：2022-07-06 12:37:57
【问题描述】：
我正在处理的 repo 不使用 master 作为最前沿，他们使用 develop 分支。 master 用于关注最新版本。因此，master 应该始终在 develop 之后。
我没有意识到这个工作流程，并将文档修复（涉及 README 文件等内容）推送到 master。举个简单的例子，我们的网站曾经在 Sourceforge 上，我更新了自述文件以讨论 GitHub。
因为我意识到我在错误的分支上，所以我恢复了一些东西。在 GitHub 领域，执行此操作的方法是使用另一个合并请求，该请求基本上会还原您的第一次提交。
我的master 分支目前在我的自述文件中显示与 Sourceforge 相关的措辞。我的develop 分支目前显示与 GitHub 相关的措辞。但是develop 分支是 16 个提交后面 master。
使用 GitHub 的“合并”功能向我展示了一个可以还原我的文档的差异，就像 master 分支被还原一样。
到目前为止，我发现的唯一解决方法是手动合并 16 个提交，但通过手动丢弃所有更改来消除它们的冲突。显然，更新文档的提交已经发生在开发中，因为这些话是正确的。
在开发分支中使用git rebase master 或git merge master 会破坏我的更改。实际上，我需要一个“仅限 db”的合并。
【问题讨论】：
-
你能展示你想要的提交图，以及你现在拥有的吗？
-
Revert，在 Git 中，并不意味着“恢复到”，而是“添加一些可以撤消的东西”。所以一般来说，还原会推动你更进一步。这通常是可取的，因此通常是可取的。何时以及是否是您的 愿望完全是另一个问题，需要的信息比您提供的要多得多。参见上面@mkrieger1 的评论，但请查看错误命名的“revert”和
git reset之间的区别。 -
所以我想通了，很简单，答案是：在开发分支上，我做了
git merge -s ours master，这将这 17 个提交再次推送到我的开发分支，但丢弃了它们的文本。在未来的某个时候，当我们削减一个新版本（这是唯一一次触及 master）时，这些更改最终会在 Master 上发布，因为单个 diff，它是所有文档，可以从git blame观点。