git config pull.ff only或等效地git pull --ff-only是最安全的。原因是rebase可以覆盖历史记录，并且如果另一个开发人员强制推送到同一分支，可能会导致提交丢失。

但所有这些都是有效的。

在其默认模式下，git拉取是git获取的简写，然后是git合并FETCH_HEAD。

当你执行git pull origin master时，
git pull执行合并，这通常会创建一个合并提交。因此，默认情况下，从远程拉取是没有一个无害的操作：它可以创建一个以前不存在的新提交SHA哈希值。这种行为会让用户感到困惑，因为感觉应该是一个无害的下载操作实际上以不可预测的方式改变了提交历史。

为了避免这种情况，你需要

git pull --ff-only

（或者不？继续阅读，看看哪一个符合您的要求）

对于git pull --ff-only，Git只有在可以“快速转发”而不创建新提交的情况下才会更新您的分支。如果做不到这一点，git pull --ff-only只需中止并显示错误消息。

您可以将Git客户端配置为默认始终使用--ff-only，因此即使您忘记了命令行标志，您也会得到这种行为：

git config --global pull.ff only

注意：--global标志将更改应用于您机器上的所有存储库。如果您只希望您所在的存储库具有这种行为，请省略该标志。

摘自

此警告是在Git 2.27中添加的。

这是完整警告的样子：

在不指定如何协调不同分支的情况下拉取是气馁。您可以通过运行以下之一来压制此消息下一次拉取之前的某个时间命令：

git configpull.rebasefalse#合并（默认策略）
git configpull.rebasetrue#rebase
仅git配置pull.ff#仅快进

您可以将“git config”替换为“git config--global”来设置默认值所有存储库的首选项。您还可以传递--rebase、--no-rebase，或命令行上的--ff-Only以覆盖配置的默认per调用。

警告显示了三个命令作为选项，所有这些命令都将抑制警告。但它们用于不同的目的：

git config pull.rebase false     # merge (the default strategy)

这将保留默认行为并抑制警告。

git config pull.rebase true      # rebase

这实际上是在远程分支之上提交的，在本地和远程维护单个分支（与默认行为不同，默认行为涉及两个不同的分支-一个在本地，另一个在远程-并且为了将两者结合起来，执行合并）。

git config pull.ff only          # fast-forward only

只有当本地分支可以快速转发时，它才会执行拉取。如果不是，它只是用错误消息中止（并且不创建任何提交）。

更新时间：

如果您有Git 2.29或更高版本，您现在可以将pull.ff设置为false、true或only以摆脱警告。

git config pull.ff true

true-这是默认行为。如果可能，Pull会快进，否则会合并。

git config pull.ff false

false-拉取永远不会快进，并且总是创建合并。

git config pull.ff only

only-如果可能，拉取被快进，否则操作被中止并显示错误消息。

备注：您可能需要关注VonC的答案这里，以便在未来的更新中更新此功能的更改。

这是git 2.27中的新警告添加：

 * "git pull" issues a warning message until the pull.rebaseconfiguration variable is explicitly given, which some existingusers may find annoying---those who prefer not to rebase need toset the variable to false to squelch the warning.

要删除警告，如果您没有在命令行上指定行为（使用--ff、--no-ff、--ff-only、--rebase），请将建议值之一设置为git pull的首选默认行为。在所有情况下，如果可能，git将尝试快进（什么是Git快速转发？）合并。设置控制当分支中有变化但没有存在于远程分支中时会发生什么。

  git config pull.rebase false  # merge (the default strategy)

这是现有的默认行为；将其设置为没有警告，也没有行为变化；git将把远程分支合并到本地分支中。

  git config pull.rebase true   # rebase

在这里，git将尝试将您的更改重新建立在远程分支之上。有关您可能需要的原因的更多详细信息，请参阅我什么时候应该使用git ull--rebase？。

  git config pull.ff only       # fast-forward only

如果无法进行快进合并，git将拒绝继续进行。正如git拉取--rebase和git拉取--ff-Only之间的区别引用的那样：

拒绝合并并以非零状态退出，除非当前HEAD已经是最新的，或者合并可以作为快进解决

注意：前面我们教了“git pull”^（man），当用户没有说历史记录需要合并、重新基于或只接受快进时发出警告，但是对于那些设置了pull.ff配置变量的人触发了警告。

在Git 2.29（2020年第四季度）中不再是这种情况（意思是：不再警告）。

见提交54200ce（2020年9月24日）byAlex Henrie（#0）。
^{（合并于提交中的Junio C Hamano----#0----,2020年9月29日）}

pull：如果pull.ff已设置，则不警告

^{签名人：Alex Henrie}

一个足够理解设置pull.ff的用户不需要额外的说明。

在Git 2.31（2021年第一季度）之前，当用户没有告诉“git pull”^（man）使用rebase或合并时，该命令会发出响亮的消息，告诉用户在rebase或合并之间进行选择，但无论如何都会创建合并，迫使想要rebase的用户重做操作。

通过收紧条件以提供消息来修复此问题的早期部分-如果历史快进，则没有理由停止或强制用户在rebase或合并之间进行选择。

见提交7539fdc，提交b044db9（2020年12月14日）byJunio C Hamano（#0）。
见提交c525de3，提交278f4be，提交77a7ec6（2020年12月12日）byFelipe Contreras（#0）。^{（2021年1月6日，被提交d3fa84d中的Junio C Hamano----#0----合并）}

pull：仅在非ff时显示默认警告

^{作者：Junio C Hamano
签名人：Felipe Contreras}

没有必要在每次拉取时显示烦人的警告……只有那些不是快进的。

当前的警告测试仍然通过，但不是因为参数或配置，而是因为它们都是快进的。

我们现在需要测试非快进情况。

随着2.34（2021年第四季度）的警告变化：“git pull”^（man）在其--rebase后端有各种角落案例没有经过深思熟虑，例如“git pull --ff-only”^（man）并没有停止，而是继续前进，当另一边的历史不是我们历史的后代时重新建立基础。

另见下文：Git 2.34还没有修复所有问题。

见提交6f843a3，提交359ff69，提交031e2f7，提交adc27d6，提交e4dc25e（2021年7月22日），和提交1d25e5b，提交日期（2021年7月21日）by伊利亚·纽伦（#0）。见提交3d5fc24（2021年7月21日）byAlex Henrie（#0）.
^{（2021年8月30日提交7d0daf3合并为Junio C Hamano----#0----）}

pull：当无法快速转发时默认中止

^{初始补丁：Alex Henrie
签名人：Elijah Newren}

当用户没有指定如何将不同的分支与git pull协调时，我们已经显示了一段时间的长警告。
现在让它成为一个错误。

git pull现在包含在其手册页中：

将来自远程存储库的更改合并到当前分支中。

• 如果当前分支位于远程后面，则默认情况下它将快进当前分支以匹配远程。
• 如果当前分支和远程分支已经发散，用户需要指定如何将发散的分支与--no-ff、--ff或--rebase（或pull.ff或pull.rebase中的相应配置选项）进行协调。

更准确地说，git pull使用给定的参数运行git fetch，然后根据配置选项或命令行标志，将调用git merge或git rebase来协调发散分支。

所以：而不是看到（在Git 2.33.1之前）：

不指定如何协调不同分支的拉取是不鼓励的。
您可以通过在下次拉取之前的某个时间运行以下命令之一来压制此消息：

git config pull.rebase false  # merge (the default strategy)git config pull.rebase true   # rebase

您将看到：

您有不同的分支，需要指定如何协调它们。
您可以在下次拉取之前的某个时间运行以下命令之一来执行此操作：

git config pull.rebase false  # merge (the default strategy)git config pull.rebase true   # rebase

也就是说，如果你不要运行其中一个命令，你会得到一个致命的错误：

fatal: Need to specify how to reconcile divergent branches.

Git 2.35（2022年第一季度）更新

方舟报告：

Git 2.34仍然损坏。它拒绝拉取作为当前分支头的祖先的远程分支。
git失败而不是什么都不做。
VSCode具有同步功能，可以拉和推。
由于GIT更改了行为，该功能已被破坏数月。

幸运的是，这个问题终于在GIT master中得到了修复

这是在此git邮件线程中报告/讨论的，并且正在进行修复（是否需要提交ea1954a）

在Git 2.35（2022年第一季度）之前，“git pull”^（man）在对方落后时使用任何策略都应该成功，因为它是一个无操作，但事实并非如此。

见提交ea1954a（2021年11月17日）byErwin Villejo（#0）。
^{（2021年11月21日提交0f2140f合并Junio C Hamano----#0----）}

pull：当已经更新时应该是noop

^{签名人：Erwin Villejo}

已经更新的拉取bug已修复为--ff-only，但它不包括未指定--ff或--ff-only的情况。

这将更新--ff-only修复程序，以包括命令行标志或配置中未指定--ff或--ff-only的情况。

运行这个：

git config pull.ff only

祝贺你自己，你可以继续你的工作。

最安全的选项设置为ff只全局。运行：

git config --global pull.ff only

此选项将被添加到全局.gitconfig。

[pull]ff = only

如果稍后的快进失败，请尝试git pull --no-ff。

确保您当前所在的分支存在于远程存储库中。如果您正在使用艾特莱森（比特桶和Jira），可能是在拉取请求后您的分支被删除并且您忘记签出到其他分支（即主/开发）。

我不知道这是否与您的问题有关，但请注意，Git的v2.34.0版本存在问题。git pull命令没有预期的行为。

发布说明中关于来自Git的修复程序和2021-11-24的新版本的消息：

当对方落后于我们时，使用任何策略的“git拉”都应该成功，因为它是一个无操作，但没有“。

Git v2.34.1发行说明

此问题已在2.34.1更新您的Git版本中修复。

如果将Git与Visual Studio（2019或2022）一起使用并开始遇到此问题，则可以从Git选项卡->设置中定义此选项。

拉取时重设本地分支

如果您希望分支“合并”更改，则设置为false；如果您希望“重新定位”更改，则设置为True。

对我来说，一旦我设置了配置，我仍然无法合并。这是致命的：不可能快进，流产

上述解决方案都不起作用，所以我使用了合并与开发。合并起源/开发

例如，您从开发分支创建了一个分支A，并且在从开发分支拉到A分支期间得到了这个发散的问题。您无法将更新代码从开发分支带到ur A分支。所以请按照此步骤解决此问题

1. git检查开发分支（这将切换到开发brnach）
2. git拉取（它会拉取所有的变化来开发）
3. git检出A功能分支（这将切换到您的功能分支）
4. git合并开发分支（它会将所有更改合并到您的功能分支）

现在，您已经将代码从开发更新到本地分支。享受你的编码：）

对我很管用

git config --global pull.ff true

在我的例子中，当我打算只获得我想要的分支的最新更新时，我从不同的分支中拉取。我更改了分支，它恢复了正常。

git configpull.rebasefalse

合并（默认策略）

这在我的案例中奏效了：

git rebase起源/my_remote_branch_name

如果你从一个分叉的回购推，像我： P，试试这个

git push -f origin <branch_name>

这被推送。如果有任何冲突，您可以从git处理

上面提到的好答案已经很少了，但如果你发现它令人困惑，你可以试试这个：

git reset --hard origin/<remote_branch_name>

此命令将丢弃任何本地分支更改，并使您的本地分支与远程brach完全相同。换句话说，它使您的本地分支成为远程分支的副本。

已经有很多答案了，然而，我的处理方式-如果你想从分支A拉到分支B-

1. 我将首先创建一个来自A的拉取请求以让说主。
2. 确保所有冲突都已解决，并将A合并到master中。
3. 之后，简单地从master拉入分支B。

git pull origin main --rebase为我工作！

这里有很多很好的答案。但我想从路线原因的角度来回答…

不容易确定OP路由原因每个人都可能不同。解决问题很棒，但首先防止它们更好。虽然我尊重上面的答案，因为他们的知识远远超过我的。

这是我的问题的原因与上面相同的错误：

1. 从我的开发分支到我的远程开发分支执行提交和推拉（使用VS Code）；
2. 然后是我的团队部门的公关。
3. 然后在github中，我将我的团队分支合并到我的Dev分支（更高）中，以使Dev与其他团队保持一致，以确保我们都保持一致。
4. 第二天早上我做了一个新的提交，但是当我去推/拉VS Oce在我的本地我得到错误。

我应该做的是在远程合并后，我应该在进行进一步更改之前将远程拉取或获取到本地，然后我就不会出现错误。

所以我的日常工作应该改变，当我在遥控器上将Team合并到Dev时，我还必须立即将其拉到本地

我还有另一个复合因素，我的新提交与合并到我的开发分支中的内容发生冲突，所以我收到了不同的错误，告诉我在拉取之前删除或隐藏我的更改。

因此，如果能把这件事完成，按正确的顺序做事，可能会从一开始就防止错误。（可能有）。

这意味着您的本地主机和远程主机有分歧，这意味着它们都有不能简单地快速转发的贡献。为了保持本地提交，您可以按照以下步骤操作：

1. git switch -C feature_branch (from master, create local branch with your local commits)2. git switch master3. git reset --hard origin/master (lose all local changes, and become same as origin/master)4. git switch feature_branch5. git merge master (add remote changes to your local)6. git push7. Make a pull request for master.