我们正在使用Github Desktop（以前的Github for Windows）作为我们的Git客户端。我们经常遇到以下情况：
开发人员A使用可爱的解释性消息提交了大量更新。 开发人员B一直在同一个分支中工作，然后提交一条消息。
开发人员B的提交消息显示在git日志中，然后，我们从Developer B获得一个合并提交，其中包含一个自动消息“merge branch ...”。合并提交包含所有Developer A的更改，但Developer A的可爱消息已经消失。看起来这种行为有所改变 - 它过去很少发生，现在似乎一直在发生。
（很难找到Github Desktop中“同步”按钮的最新信息，但我确实发现a reference建议它曾用git pull --rebase和然后改变了。这似乎符合这个合并提交问题比以前更糟的事实。）
所以我的问题是：有没有办法防止丢失开发者A的提交消息？
已编辑添加： 似乎问题是双重的： 1）我们的开发人员在提交之前并不总是做拉，导致合并提交。原始提交不会丢失，但不可见。 2）Github Desktop显示日志的方式是显示合并提交但未显示原始提交。以下是我从Github Desktop团队收到的电子邮件中的评论：
进一步深入研究，看起来确实如此 由于我们在显示时使用的--first-parent标志而隐藏 GitHub桌面的历史。目前没有办法改变这一点 行为。
这是我们为什么这样做的开发者的理性背后的一些理性 GitHub桌面共享：
“GitHub Desktop针对GitHub Flow进行了优化。在此模型中，合并 几乎总是代表（1）一个分支合并到 通过拉取请求的默认分支或（2）从中更新的分支 默认分支。
在第一种情况下，查看哪些拉取请求最有用 已合并 - 而不是构成拉取请求的单个提交。 我们认为拉取请求是惊人的，对理解非常有用 历史，所以我们想要优先考虑它们。
在第二种情况下，只查看合并中提交的提交 模糊了分支上的变化。看到它是最有用的 提交对于分支而言是唯一的。“
我们最终觉得Github Desktop可能不适合我们 - 我个人已经切换到GitKraken，我们很多人都在使用命令行。
答案 0 :(得分：2)
Git合并不应该那样。如果您无法确定您的Git GUI正在执行哪些命令（合并，rebase，壁球......），我建议您使用命令行执行A B 2，这样您就可以控制发生的事情。
由于大多数图形Git客户端带来的模糊和词汇混淆，我倾向于提倡命令行Git。
答案 1 :(得分：1)
开发人员A的提交消息可能不会丢失。这是Github Desktop应用程序显示提交的方式。
您可以通过运行git log --graph来检查您是否确实丢失了提交。
如果您希望客户端显示合并的提交，您可以使用SourceTree或TortoiseGit。
有关详细信息，请参阅this answer和this question。