git pull可能正在创建提交。如果您进行本地提交然后运行git pull在其他人将提交推送到存储库，则Git将下载其他开发人员的提交，然后将其合并到本地分支中。
将来如何避免这些合并提交
您可以使用它git pull --rebase来防止将来发生这种情况，但是重新定级存在其危险，我建议pull完全避免使用。
相反，我鼓励您遵循以下使用模式：
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
说明
git remote update -p下载远程存储库中的所有提交并更新远程跟踪分支（例如origin/master）。它不会碰到您的工作目录，索引或本地分支。
所述-p参数梅干删除上游分支。因此，如果foo分支在origin存储库中git remote update -p删除，则会自动删除您的origin/foo引用。
git merge --ff-only @{u}告诉Git将上游分支（@{u}参数）合并到您的本地分支中，但前提是您的本地分支可以“快速转发”到上游分支（换句话说，如果没有分支）。
git rebase -p @{u}有效地移动了您已经提交但尚未推送到上游分支顶部的提交，从而消除了创建您要避免的愚蠢合并提交的需要。这改善了开发历史的线性度，使其更易于查看。
该-p选项告诉Git保留合并。这可以防止Git将重新提交的提交线性化。例如，如果您将功能分支合并到中，则这一点很重要master。如果没有-p，则特征分支上的每次提交都会被复制，master作为线性化的一部分git rebase。这将使开发历史更难以审核，而不是更容易。
当心： git rebase可能未达到预期的效果，因此请在推送前检查结果。例如：
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
git pull --rebase与以下原因相比，我更喜欢这种方法：
- 它允许您在修改历史记录以合并它们之前查看传入的上游提交。
- 如果需要重新建立有意合并的基础（例如，将已经按下的要素分支合并到中），则可以使用
-p（--preserve-merges）选项。git rebasemaster
速记： git up代替git pull
为了简化上述操作，建议您创建一个别名up：
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
现在，使分支保持最新状态所需要做的就是运行：
git up
代替git pull。如果由于本地分支机构与上游分支机构不同而出现错误，则可以根据需要进行调整。
为什么不git pull --rebase呢？
Running git pull --rebase等同于运行git fetch后跟git rebase。这将尝试快进到新的上游提交，但是如果这不可能，那么它将把本地提交重新建立到新的上游提交上。通常可以，但是请注意：
- 变基是一个高级主题，变基之前您应该了解其含义。
git pull --rebase并没有给您机会在合并之前检查提交。根据什么改变后的上行，这很可能是重订是错误的操作，一rebase --onto，merge，reset，或者push -f可能比普通的更合适rebase。- 无法（当前）传递
--preserve-merges给rebase操作，因此要素分支的任何有意合并将被线性化，从而重放（并因此重复）所有要素分支的提交。
“修复”由...创建的现有合并提交 git pull
如果尚未推送由创建的合并提交git pull，则可以使合并提交变基。假设您没有进行任何有意的合并（例如，将已经按下的功能分支合并到当前分支中），则应执行以下操作：
git rebase @{u}
上面的命令告诉Git选择从HEAD（当前提交）可以到达的所有非合并提交，减去从@{u}（可以是“上游分支”的简写，即，origin/master如果HEAD是master）的所有提交，重播（cherry-pick ）将它们放在上游分支的顶部，然后将当前分支引用移至指向重播提交的结果。这有效地将非合并提交移动到最新的上游提交，从而消除了由创建的合并git pull。
如果您有意进行合并提交，则您不想运行git rebase @{u}它，因为它会重播另一个分支中的所有内容。处理这种情况实际上要复杂得多，这就是为什么最好使用git up并git pull完全避免使用它的原因。您可能必须使用reset撤消由创建的合并pull，然后再执行git rebase -p @{u}。该-p给的说法git rebase并没有可靠地为我工作，所以你可能最终不得不使用reset撤消故意合并，更新您的本地分支@{u}，然后重做故意合并（这是一个痛苦，如果有很多毛茸茸的合并冲突）。