我正在与另一个开发人员合作进行一个项目，我们正在使用Github作为我们的远程仓库。我在Mac上使用git 1.7.7.3，他在Windows上使用git 1.7.6。
这是发生了什么
git pull。git push。随着时间的推移，提交日志中会散布“合并分支”消息，并且还将开发人员B显示为开发人员A所做的提交更改。我们发现防止此问题的唯一方法是git pull --rebase在第3步中进行操作，但我不知道重新定基会带来哪些副作用。这是我第一次从事多开发人员git repo的工作，所以这只是正常现象吗？关于如何解决这个问题有什么想法？
Answers:
您看到的提交非常好。一个pull有效的运行git fetch，然后git merge所以当你运行一个合并通常发生git pull。
可以使用重定基础而不是合并的替代方法，但是通常应该避免这种情况。变基使您可以保留线性历史记录，但也可以删除有关最初发生的分支的任何信息。这也将导致当前分支的历史记录被重写，从而重新创建目标分支（在您的情况下为远程）中未包含的所有提交。由于重新创建的提交是不同的提交，因此与其他开发人员一起进行开发时会引起很多混乱，尤其是当人们在重写之前已经检出了部分提交时（例如使用功能分支）。因此，根据经验，永远都不要重写任何已经推送的提交。
您看到的提交将合并两个（或多个）分支。拥有一个不执行其他任何操作然后合并多个分支的提交就很好了。实际上，当您有一个合并提交，它可以在查看历史记录时合并分支，因此非常清楚。与重新定级相比，合并还使您可以有效地查看原始历史记录，包括合并的实际分支。
因此，长话短说：是的，拥有合并提交是完全可以的，您不必担心它们。
由于我的理解，图表和结论不正确，因此该答案已被修改。
git pull导致合并提交，因为git正在合并。可以通过将分支设置为使用rebase而不是merge来更改此设置。使用rebase而不是在pull上合并将为共享存储库提供更线性的历史记录。另一方面，合并提交显示了分支上的并行开发工作。
例如，两个人在同一个分支上工作。分支开始于：
...->C1
第一个人完成工作并推送到分支：
...->C1->C2
第二个人完成了他们的工作并想要推送，但是不能，因为他们需要更新。第二人称的本地存储库如下所示：
...->C1->C3
如果拉取设置为合并，则第二个人存储库将看起来像。
...->C1->C3->M1
\ /
->C2->
其中M1是合并提交。这个新的分支历史将被推送到仓库中。如果相反，则将pull设置为对本地存储库进行重设，如下所示：
...->C1->C2->C3
没有合并提交。历史变得更加线性。
两种选择都反映了分支的历史。git允许您选择喜欢的历史记录。
确实在某些地方，重新设置可能会导致远程分支机构出现问题。这不是其中一种情况。我们更喜欢使用rebase，因为它简化了已经很复杂的分支历史记录，并显示了相对于共享存储库的历史记录版本。
您可以设置branch.autosetuprebase = always来让git自动将远程分支建立为rebase而不是master。
git config --global branch.autosetuprebase always
此设置使git自动为每个远程分支创建配置设置：
branch.<branchname>.rebase=true
您可以为已设置的远程分支机构自行设置。
git config branch.<branchname>.rebase true
我要感谢@LaurensHolst对我之前的发言提出质疑和追求。我当然已经了解了更多有关git如何与pull和merge提交一起工作的知识。
实际上，对此有一个简单得多的答案。只需让开发人员B在提交之前进行拉动即可。这将防止这些合并提交，因为它们是由您在本地存储库中尝试与远程存储库上的提交历史记录合并的本地存储库中的历史记录引起的。如果您在进行拉取时收到一条消息，说“更改将被覆盖”，则表示您都触摸了同一文件，因此：
git stash
git pull
git stash pop
那么您可以解决任何合并冲突（如果有）。
stash之前pull。Ugh git要求我一直处于游戏的顶端。
git pull --rebase无论如何，都需要在本地更改之前集成远程更改。
git log --no-merges