我们使用 Github Desktop（以前的 Github for Windows）作为我们的 Git 客户端。我们经常遇到以下情况：
开发人员 A 提交了一堆带有可爱的解释性消息的更新。开发人员 B 一直在同一个分支中工作，并在之后提交了一条消息。
开发人员 B 的提交信息显示在 git 日志中，然后，我们从开发人员 B 获得合并提交，并自动显示“合并分支 ...”消息。合并提交包含开发人员 A 的所有更改，但开发人员 A 的可爱消息消失了。这种行为似乎发生了一些变化——过去很少发生，现在似乎一直在发生。
（很难找到关于 Github Desktop 中的“同步”按钮正在做什么的最新信息，确切地说，但我确实找到了一个参考，表明它曾经这样做git pull --rebase，然后改变了。这似乎符合以下事实这个合并提交问题比以前严重得多。）
所以我的问题是：有什么办法可以防止开发者 A 的提交信息丢失？
编辑添加：似乎问题有两个方面：1）我们的开发人员并不总是在提交之前进行拉取，从而导致合并提交。原始提交不会丢失，但不可见。2) Github Desktop 显示日志的方式是显示合并提交，但不显示原始提交。这是我从 Github 桌面团队收到的电子邮件中的评论：
进一步深入研究，看起来确实由于我们在 GitHub Desktop 中显示历史记录时使用的 --first-parent 标志而隐藏了提交。目前没有办法改变这种行为。
以下是 GitHub Desktop 的开发人员分享的我们这样做的一些原因：
“GitHub Desktop 针对 GitHub Flow 进行了优化。在这个模型中，合并几乎总是代表（1）通过拉取请求将分支合并到默认分支中，或者（2）从默认分支更新分支。
在第一种情况下，最有用的是查看哪些拉取请求已被合并——而不是构成该拉取请求的单个提交。我们认为拉取请求非常棒，并且对于理解历史非常有用，因此我们希望优先考虑它们。
在第二种情况下，看到合并中的提交只会掩盖分支上的更改。查看分支独有的提交是最有用的。”
我们最终觉得 Github Desktop 可能不适合我们——我个人已经切换到 GitKraken，而且我们中的很多人更多地使用命令行。