为什么Git不能自动快进？

当我执行git拉、添加、提交、推时，就会发生这种情况

 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'http://foo:8080/tfsdev/foo/_git/Development.Services'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

当我将-ff添加到git pull时，它将通过。 我认为快进是默认的，为什么会发生这种情况

当我将-ff添加到git pull时，它将通过。我认为快进是默认的，为什么会发生这种情况

你在这里混淆了一堆不同的概念。。。这并不奇怪，因为

git-pull

也混淆了一系列不同的概念，为了方便起见，这通常会导致混淆。（当然，偶尔也很方便。：-）

使用

git pull

通常会运行

git merge

，这通常会执行快进而不是合并。这会使您的分支通过从远程（通过

git fetch

）带来的任何

git pull

更新，这样您添加的提交也只会添加到（而不是替换或删除）它们的提交。但是

git push

并不是

git pull

的对立面，而是

git fetch

的对立面：它不进行任何合并

当你做一个

pull

+做一些事情（提交或其他什么）+

push

序列时，你正在与同样做pull-commit-push序列的其他人竞争。谁赢了，谁就得推。这部分就这么简单。当你不赢的时候，问题就来了

当你是唯一一个跑步的人时，很容易赢得这场比赛。如果没有其他人推动这一分支，你将永远赢得比赛。这里发生的事情是，你不是唯一一个跑步的人，你输了

不幸的是，完整的答案是复杂的，你没有展示足够的情况来回答这个具体的案例。让我们来看看到底发生了什么。< / P> 始终跟踪您当前的分支机构 如果

git status

在分支母版上显示

，或
git branch
打印
*母版
，则当前分支为
母版
。大多数Git命令都适用于您当前的分支，
Git pull
在这里也不例外

git pull
命令只运行另外两个git命令。第一个总是
git fetch
。第二个，你可以改变

首先，
git pull
运行
git fetch
运行的第一个命令
git pull
是
git fetch
。它运行一个有限的
git-fetch
，告诉
git-fetch
只带来当前分支所需的提交和其他项。如果您只运行
git fetch
，git将带来所有内容，这可能需要更长的时间，但意味着您可以随时了解所有内容

git fetch

命令是处理当前分支的git常规规则的一个例外。在某些情况下，它仍然会查看您当前的分支，但是

git fetch

通常会更新您的远程跟踪分支。在大多数情况下，您将只拥有一个名为

origin

的所谓远程，并且运行

git fetch

将从

origin

带来一切，并更新您的

origin/master

、

origin/develop

和其他

origin//code>分支。这些是名为
origin
的远程跟踪分支

因此，如果您自己运行
git fetch
，它将更新所有
origin/*
远程跟踪分支。如果运行
git pull
，它将根据当前分支以只更新其中一个的方式运行
git fetch
。这些更新总是安全的：它们将新提交带到您的存储库中，这对存储库中的所有现有提交都没有影响

让人困惑的是，
git fetch
将其所有更新写入名为
fetch\u HEAD
的文件，您将在中看到该文件。但它也会更新远程跟踪分支，除非您使用的是非常旧的Git版本（比Git版本1.8.4旧）。对于那些使用古老git（1.7.x）的人来说，从
origin
获取所有东西的手动
git-fetch
会更新它们，但由
git-pull
运行的不会更新

然后，
git pull
运行其他操作
这里有点乱。
git pull
的第二部分是
git merge
或
git rebase
。默认值是
git merge
，尽管
git-rebase
通常是一个更好的主意。您必须提前选择应该使用哪个命令
git pull
。但是你应该用哪一个呢？唯一能确定的方法就是看看会发生什么。如果您选择了新提交，您可以使用
git log
和其他git命令查看它们

不过，要想知道会发生什么，你必须把它带进来。这就是git fetch所做的。git fetch

步骤安全地引入了新的提交，将它们安全地放在那些远程跟踪分支后面。现在，您可以决定是合并还是重新设置基础

git pull

命令让您在查看之前做出决定。所以，选择您希望它执行合并、重定基础和拉取操作的一个，然后它将获取并执行该操作。要使其执行rebase，请运行

git pull--rebase

，或者将当前分支设置为默认情况下执行

git pull

（此设置是针对每个分支的，因此您必须针对每个分支进行设置。还有一个配置条目告诉Git设置“rebase模式”对于Git创建的每个分支都会自动执行，但在我看来，只需自己运行

Git fetch

，然后自己运行第二个命令就容易多了。这让您有机会查看所获取的内容，并且在出现问题时也不会太混乱。）

当第二个命令是

git merge

让我们假设第二件事

git pull

运行的是

git merge

。这对我来说确实有效

...--o--*     <-- master
         \
          o   <-- origin/master

...--o--o
         \
          o   <-- master, origin/master

...--o--o--o  <-- master, origin/master

...--o--*--o   <-- master
         \
          `-o    <-- origin/master

...--o--*--o--o   <-- master
         \   /
          `-o    <-- origin/master

...--o--o--*   <-- master, origin/master

...--o--o   o--o   <-- master
         \ /
          o   <-- origin/master

...--o--o   o--o   <-- master
         \ /
          o   <-- origin/master

...--o--o   o--o   <-- master
         \ /
          o-----o   <-- origin/master

...--o--o   o--o--o   <-- master
         \ /     /
          *-----o   <-- origin/master