blu*_*urb 5 git version-control merge
我有两个分支，A) 开发和 B) 功能
我在 B 上工作，现在准备将 B 合并到 A。A 显然已经完成了很多工作，通过拉取请求合并了许多其他功能分支。我拉出 A 的最新头并出于测试目的，假设我将 A 合并到 B （注意，我在两个方向上都有相同的行为，但我试图找出问题所在）。
我将 A 合并到 B，但是在解决合并冲突后出现了很多编译器错误。我注意到实际上 A 中包含的代码只是没有将其传递给 B。这会导致构建失败，并且缺少很多东西（它至少是一个大的代码提交价值）。
我追踪了我在从 A 到 B“合并”时遇到问题的提交。虽然它不是没有合并，但当我在合并后签出 B 时键入“git log”时我确实看到了它。出于某种原因，与提交相关的实际更改会消失。有问题的代码没有合并冲突，我确信我在处理 B 时从未触及过该部分，因此其他任何事情都可能发生。
关于“丢失”提交（即使我在分支日志中看到它），我应该怎么做才能恢复实际更改？我会使用 diff 工具，但我担心这是一个更大问题的症状，我不知道的其他代码也可能丢失。
我对 git 相当陌生，所以我有点不确定如何解决这个问题。请让我知道是否还有其他有用的信息。
到目前为止我尝试过的：
将 A 合并到 B，提交在那里，但提交的代码没有将 B 合并到 A，相同代码/提交的相同问题
我试过变基，但分支因许多冲突而被许多提交关闭。所有提交也在服务器上，所以从我读过的内容来看，这可能是一个坏主意。如果我应该尝试在某个方向（A->B 或 B->A）重新定位，请告诉我。
解决方案
如果只是缺少一个提交，您可以通过在 B 分支上发出cherry-pick命令轻松地将其应用到 A 分支：
git cherry-pick commit_name
此命令采用特定提交（按名称）并将其作为新提交应用于当前分支。只需检查日志中的提交名称并将其粘贴为参数即可。
以下是有关该命令的更多信息： https://git-scm.com/docs/git-cherry-pick
有关可能原因的更多信息
至于问题本身。您遇到这种情况的原因可能有很多，其中有些可能是微不足道的，有些则不然。我想说 GIT 最有可能看到这些差异，但由于某种原因得出的结论是不应应用它们（在自动合并过程中）。您必须检查 B 分支的历史记录、它是如何以及何时（关于此 A 提交）创建的，以及它是否有该特定提交的任何历史记录。
无论如何，如果来自该提交的更改实际上并不存在于 B 代码中，那么樱桃选择应该可以帮助您解决此问题，因为它将使用新的提交名称应用这些更改，从而避免任何问题。