我和同事正在使用Git，只有一个远程源代码库。 我们都会进行本地提交，然后推送到源代码库。在我们工作的过程中，自然会出现一些分歧。
一旦push到源代码库，我希望我们可以合并本地分支，然后再push到源代码库。 我预计得到的将是一个相当直接的版本历史记录，而没有描述合并。
从相当复杂的版本“地铁图”和经常出现的“Merge branch 'master'”消息来看，我猜我们做了一些不太对的事情。
我觉得这个问题以前已经在这里回答过了，但我不能完全理解我收集到的信息。
我们有一个类似的情况。虽然我们使用一个中央主仓库，但我们经常有个别开发人员生成 Merge branch 'Master' 消息。我们的解决方案是让开发人员在从远程主仓库拉取时执行git pull --rebase。
我认为你正在寻找git rebase。
你历史记录中记录的每个合并都是从“保留真实历史”角度所必需的。你们的分支在这一点上分叉，然后被合并（请注意，两个分支都有独特的提交，因此无法快进）。
如果你执行rebase操作，当前的tip（包括你同事的更改）将成为新的分支点，除非他们之间推送了代码，你的更改将可以通过快进应用，给人以线性开发的印象（但时间戳不是单调递增的）。
你做得很对。你正在并行开发，不时地集成同事的更改，而git忠实地记录了确切的历史记录。
尽管您可以通过变基“避免”合并提交，但通常最好坚持使用合并历史记录：每当您变基提交时，您实际上正在创建一个新提交，它会撒谎这个提交是如何产生的。虽然这些谎言通常是无害的，但它们可能会在以后引起麻烦。如果您跳过在每个变基提交上重新运行测试套件，则特别如此。
我认为，“创建线性历史记录”的整个想法有点错误。您真正想要的不是线性历史记录。您想要真实的历史记录，在其中每个提交都经过了测试。因为这使您以后能够使用有意义的结果运行git bisect。
简而言之：不要改变你的习惯。它们现在就很好。将来你可能会感激它们。
git config --global pull.rebase true可以将git pull命令设为默认使用 rebase 模式。 - tback