【git系列】git-pull 含义用法选项示例详解

【git系列】git-pull 含义用法选项示例详解

文章目录

概述

git pull命令将远程仓库的更改合并到当前分支中。

语法

git pull [<options>] [<repository> [<refspec>…]]

描述

将远程存储库的更改合并到当前分支中。如果当前分支落后于远程分支，默认情况下会快进当前分支以匹配远程分支。如果当前分支和远程分支发生了分歧，用户需要使用–rebase或–no-rebase（或对应的配置选项pull.rebase）来指定如何调整分歧的分支。

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

应该是传递给git-fetch[1]的远程存储库的名称。 可以命名一个任意的远程引用（例如，一个标签的名称），甚至可以是一组带有相应的远程跟踪分支的引用（例如，refs/heads/*:refs/remotes/origin/*），但通常它是远程存储库中一个分支的名称。

和的默认值从当前分支的"remote"和"merge"配置中读取，这些配置由git-branch[1] --track设置。

假设存在以下历史记录，并且当前分支为"master":

  A---B---C 远程上的master
 /
D---E---F---G 本地的master
^
你的存储库中的origin/master

那么"git pull"将获取并重放自从远程master分支与本地master分离（即E）以来的更改，直到它当前的提交（C），并将结果记录在一个新的提交中，连同两个父提交的名称和用户描述更改的日志消息。

  A---B---C origin/master
 /         \
D---E---F---G---H master

有关详细信息，请参阅git-merge[1]，包括冲突如何呈现和处理。

在Git 1.7.0或更高版本中，要取消冲突合并，请使用git reset --merge。警告：在较旧版本的Git中，不建议在存在未提交的更改时运行git pull：虽然可能，但会让您处于一个可能难以解决冲突的状态。

如果任何远程更改与本地未提交的更改重叠，合并将自动取消，并且工作树保持不变。通常最好在拉取之前使任何本地更改正常工作，或者使用git-stash[1]将其存储起来。

选项

-q, --quiet

传递给底层的git-fetch和git-merge，用于抑制传输过程中的报告和合并过程中的输出。

-v, --verbose

向git-fetch和git-merge传递–verbose选项。

–[no-]recurse-submodules[=yes|on-demand|no]
此选项控制是否获取填充子模块的新提交，并且是否更新活动子模块的工作树（参见git-fetch[1]，git-config[1]和gitmodules[5]）。

如果使用rebase进行检出，则还会对本地子模块提交进行变基。

如果使用merge进行更新，则会解决并检出子模块冲突。

与合并相关的选项

–commit, --no-commit

执行合并并提交结果。此选项可用于覆盖–no-commit。仅在合并时有用。

使用–no-commit执行合并并在创建合并提交之前停止，以便用户有机会检查和进一步调整合并结果。

请注意，快进更新不会创建合并提交，因此无法使用–no-commit停止这些合并。因此，如果要确保合并命令不更改或更新分支，请在–no-ff中使用–no-commit。

–edit, -e, --no-edit

在成功完成机械合并后，在提交之前调用编辑器，以进一步编辑自动生成的合并消息，以便用户可以解释和证明合并。–no-edit选项可用于接受自动生成的消息（通常不鼓励使用）。

较旧的脚本可能依赖于历史行为，不允许用户编辑合并日志消息时，运行git merge时将打开编辑器。为了更容易调整此类脚本以适应更新后的行为，可以在其开始时将环境变量GIT_MERGE_AUTOEDIT设置为no。

–cleanup=

此选项确定提交之前合并消息将如何进行清理。有关详细信息，请参见git-commit[1]。另外，如果给定值为scissors，则在合并冲突的情况下，将在传递给提交机制之前将scissors附加到MERGE_MSG。

–ff-only

仅当没有提供解决分歧历史的方法（通过–rebase=*标志）时，才更新为新历史。这是默认设置。

–ff, --no-ff

在合并而不是变基时，指定当合并的历史已经是当前历史的子孙时，如何处理合并。如果请求合并，则–ff是默认设置，除非合并的是未存储在其自然位置refs/tags/层次结构中的带注释（可能已签名）标签，在这种情况下，默认设置为–no-ff。

使用–ff时，尽可能将合并解析为快进（只更新分支指针以匹配合并的分支；不创建合并提交）。无法时（当合并的历史不是当前历史的子孙时），创建合并提交。

使用–no-ff时，在所有情况下都创建合并提交，即使合并也可以解析为快进。

-S[], --gpg-sign[=], --no-gpg-sign
对生成的合并提交进行GPG签名。keyid参数是可选的，默认为提交者身份；如果指定，必须将其附加到选项而不带空格。–no-gpg-sign对于撤消commit.gpgSign配置变量和先前的–gpg-sign都很有用。

–log[=], --no-log

除了分支名称外，还使用最多个实际提交的一行描述来填充日志消息，这些提交正在合并。有关详细信息，请参见git-fmt-merge-msg[1]。仅在合并时有用。

使用–no-log不要列出正在合并的实际提交的一行描述。

–signoff, --no-signoff

在提交日志消息末尾由提交者添加一个Signed-off-by trailer。签署意味着取决于您提交的项目。例如，它可以证明提交者具有以项目许可证提交工作的权利，或者同意某个贡献者声明，例如开发人员原始证书（请参阅http://developercertificate.org，了解Linux内核和Git项目使用的原始证书）。请咨询您要贡献的项目的文档或领导层，以了解在该项目中如何使用签名。

–no-signoff选项可用于取消之前在命令行上使用的–signoff选项。

–stat, -n, --no-stat

在合并结束时显示diffstat。diffstat也受merge.stat配置选项的控制。

使用-n或–no-stat不要在合并结束时显示diffstat。

–squash, --no-squash

生成工作树和索引状态，就像实际进行了一次合并一样（除了合并信息），但实际上不会进行提交，移动HEAD，或记录$GIT_DIR/MERGE_HEAD（以使下一个git commit命令创建一个合并提交）。这允许您在当前分支之上创建一个单独的提交，其效果与合并另一个分支相同（或者在八角形的情况下更多）。

使用–no-squash执行合并并提交结果。此选项可用于覆盖–squash。

使用–squash时，不允许使用–commit，并且将失败。

仅在合并时有用。

–[no-]verify

默认情况下，运行pre-merge和commit-msg hooks。当给出–no-verify时，将绕过这些hooks。参见githooks[5]。仅在合并时有用。

-s , --strategy=

使用指定的合并策略；可以多次提供以指定它们的顺序。如果没有-s选项，则使用内置的策略列表（对于单个头部合并是ort，否则是八角形）。

-X , --strategy-option=

通过合并策略将特定于策略的选项传递给合并策略。

–verify-signatures, --no-verify-signatures

验证要合并的侧支的顶部提交是否使用有效密钥签名，即具有有效uid：在默认的信任模型中，这意味着签名密钥已由受信任的密钥签署。如果侧支的顶部提交没有使用有效密钥签名，则合并将中止。

仅在合并时有用。

–summary, --no-summary

与–stat和–no-stat等效；这些已弃用，并将来会被删除。

–autostash, --no-autostash

在操作开始前自动创建临时stash条目，在特殊引用MERGE_AUTOSTASH中记录它，并在操作结束后应用它。这意味着您可以在脏工作树上运行操作。但是，请谨慎使用：成功合并后最终的stash应用可能会导致非平凡的冲突。

–allow-unrelated-histories

默认情况下，git merge命令拒绝合并没有共同祖先的历史记录。当合并两个独立开始的项目的历史记录时，可以使用此选项覆盖此安全性。由于这是非常罕见的情况，不存在启用此功能的配置变量，并且不会添加。

仅在合并时有用。

-r, --rebase[=false|true|merges|interactive]

当为true时，在获取后将当前分支变基到上游分支。如果存在对应于上游分支的远程跟踪分支，并且上游分支自上次获取以来已经进行了变基，则可以使用该信息避免对非本地更改进行变基。

当设置为merges时，使用git rebase --rebase-merges进行变基，以便包括本地合并提交（有关详细信息，请参见git-rebase[1]）。

当设置为false时，将上游分支合并到当前分支。

当设置为interactive时，启用交互模式的变基。

如果要使git pull始终使用–rebase而不是合并，请参阅git-config[1]中的pull.rebase、branch..rebase和branch.autoSetupRebase。

注意
这是一种潜在危险的操作模式。它重写历史记录，当您已经发布了该历史记录时，这不是一个好兆头。除非您仔细阅读了git-rebase[1]，否则请不要使用此选项。

–no-rebase

这是–rebase=false的简写形式。

与fetch相关的选项

–all

获取所有远程。

-a, --append
将获取的引用名称和对象名称附加到.git/FETCH_HEAD现有内容中。没有此选项，.git/FETCH_HEAD中的旧数据将被覆盖。

–atomic

使用原子事务更新本地引用。要么更新所有引用，要么在出错时不更新任何引用。

–depth=

将获取限制为每个远程分支历史记录顶部指定数量的提交。如果使用git clone命令创建了一个带–depth=选项的浅仓库（参见git-clone[1]），则将历史记录深入或缩短到指定数量的提交。不会获取深化提交的标签。

–deepen=

类似于–depth，但它从当前浅边界开始计算，而不是从每个远程分支历史记录顶部开始。

–shallow-since=

将浅仓库的历史深化或缩短，以包括之后的所有可达提交。

–shallow-exclude=

将浅仓库的历史深化或缩短，以排除从指定的远程分支或标签可达的提交。此选项可以多次指定。

–unshallow

如果源仓库完整，则将浅仓库转换为完整仓库，消除浅仓库所施加的所有限制。

如果源仓库是浅仓库，则尽可能获取所有内容，使当前仓库具有与源仓库相同的历史记录。

–update-shallow

默认情况下，当从浅仓库获取时，git fetch会拒绝需要更新.git/shallow的引用。此选项会更新.git/shallow并接受此类引用。

–negotiation-tip=<commit|glob>

默认情况下，Git将报告到服务器上的所有本地引用可达的提交，以找到与即将接收的packfile的大小有关的公共提交。如果指定，则Git仅报告从给定提示可达的提交。这对于加快获取速度很有用，当用户知道哪个本地引用可能与正在获取的上游引用具有共同的提交时。

此选项可以多次指定；如果是这样，Git将按照命令行上列出的顺序将可达的提交报告给另一方。

此选项的参数可以是ref名称的通配符、引用或（可能是缩写的）SHA-1提交的哈希值。指定通配符相当于多次指定此选项，每次匹配的引用名称都执行一次。

还请参见git-config[1]中记录的fetch.negotiationAlgorithm和push.negotiate配置变量，并查看下面的–negotiate-only选项。

–negotiate-only

不从服务器获取任何内容，而是打印我们与服务器共享的提供的–negotiation-tip=*参数的祖先。

与–recurse-submodules=[yes|on-demand]不兼容。在内部，它用于实现push.negotiate选项，请参阅git-config[1]。

–dry-run

显示将要执行的操作，而不进行任何更改。

–porcelain

将输出以易于解析的格式打印到标准输出。有关详细信息，请参见git-fetch[1]中的OUTPUT部分。

与–recurse-submodules=[yes|on-demand]不兼容，并且优先于fetch.output配置选项。

-f, --force

当使用: refspec进行git fetch时，它可能会拒绝更新本地分支，如git-fetch[1]文档中的部分所讨论。此选项覆盖该检查。

-k, --keep

保留下载的pack。

–prefetch

修改配置的refspec，将所有引用放在refs/prefetch/命名空间中。请参阅git-maintenance[1]中的prefetch任务。

-p, --prune

在获取之前，删除不再存在于远程的任何远程跟踪引用。如果仅由于默认的标签自动跟踪或由于–tags选项而获取标签，则标签不会被修剪。但是，如果标签是由显式的refspec（无论是在命令行还是在远程配置中，例如使用–mirror选项克隆的远程）获取的，则它们也会被修剪。提供–prune-tags等效于提供标签refspec。

–no-tags

默认情况下，获取远程存储库下载的对象指向的标签并将其存储在本地。此选项禁用此自动标签跟踪。可以使用remote..tagOpt设置来指定远程的默认行为。请参阅git-config[1]。

–refmap=

当在命令行上列出的引用上获取引用时，使用指定的refspec（可以多次给出）将引用映射到远程跟踪分支，而不是使用远程存储库的remote.*.fetch配置变量的值。向–refmap选项提供空的会导致Git忽略配置的refspecs，并完全依赖于作为命令行参数提供的refspecs。有关详细信息，请参阅“配置的远程跟踪分支”部分。

-t, --tags

从远程获取所有标签（即将refs/tags/*的远程标签获取到与其同名的本地标签），除了其他要获取的内容。即使使用了–prune，此选项也不会对标签进行修剪（尽管如果它们也是明确的refspec的目标，标签可能会被修剪；请参阅–prune）。

-j, --jobs=

用于所有形式的获取的并行子进程数量。

如果指定了–multiple选项，则不同的远程将并行获取。如果获取多个子模块，则它们将并行获取。要独立控制它们，请使用fetch.parallel和submodule.fetchJobs的配置设置（请参阅git-config[1]）。

通常，递归并行和多远程获取将更快。默认情况下，获取是顺序执行的，而不是并行执行。

–set-upstream

如果成功获取远程，则添加上游（跟踪）引用，这些引用可由无参数的git-pull[1]和其他命令使用。有关更多信息，请参见git-config[1]中的branch..merge和branch..remote。

–upload-pack

当给定，并且要获取的存储库由git fetch-pack处理时，将传递–exec=以指定在另一端运行的命令的非默认路径。

–progress

默认情况下，如果标准错误流附加到终端，将通过标准错误流报告进度状态，除非指定了-q。此标志强制进行进度状态，即使标准错误流未定向到终端。

-o , --server-option=

在使用协议版本2进行通信时，将给定的字符串传输到服务器。给定字符串不能包含NUL或LF字符。服务器对服务器选项的处理（包括未知选项）是特定于服务器的。如果给出多个–server-option=，它们都将按照命令行上列出的顺序发送到另一方。

–show-forced-updates

默认情况下，git检查分支在获取过程中是否被强制更新。可以通过fetch.showForcedUpdates禁用此功能，但–show-forced-updates选项可以确保进行此检查。请参见git-config[1]。

–no-show-forced-updates

默认情况下，git检查分支在获取过程中是否被强制更新。通过传递–no-show-forced-updates或将fetch.showForcedUpdates设置为false，可以跳过此检查以提高性能。如果在git-pull期间使用–ff-only选项，则仍将在尝试快进更新之前检查强制更新。请参阅git-config[1]。

-4, --ipv4

仅使用IPv4地址，忽略IPv6地址。

-6, --ipv6

仅使用IPv6地址，忽略IPv4地址。
要获取的“远程”存储库，它是获取或拉取操作的源。此参数可以是URL（请参见下面的GIT URLS部分）或远程的名称（请参见下面的REMOTES部分）。 指定要获取的引用和要更新的本地引用。当命令行上没有出现时，要获取的引用从remote..fetch变量中读取（请参阅git-fetch[1]中的“配置的远程跟踪分支”部分）。

参数的格式是可选的加号+，后跟源，后跟冒号:，后跟目标引用。当为空字符串时，可以省略冒号。 通常是一个引用，但也可以是完全拼写的十六进制对象名称。

可能包含其中的以指示简单模式匹配。这样的refspec的功能类似于匹配具有相同前缀的任何引用的glob。模式必须在和中都有一个。它将通过将*替换为从源匹配的内容来将引用映射到目标。

如果refspec以^为前缀，则将解释为负refspec。而不是指定要获取的引用或要更新的本地引用，此类refspec将指定要排除的引用。如果一个引用至少与一个正refspec匹配，并且不匹配任何负refspec，则被认为是匹配的引用。负refspec可以用于限制模式refspec的范围，以便不包括特定引用。负refspec本身可以是模式refspec。但是，它们只能包含，不指定。也不支持完全拼写的十六进制对象名称。

请注意，在获取之前无法确定或声明将在仓库中提供此行为的分支；拉取用户只需知道这是分支的预期使用模式。

请注意，直接在git pull命令行上列出多个之间存在差异，并且在配置中为列出多个remote..fetch条目并在没有任何显式的参数的情况下运行git pull命令。在命令行上明确列出的总是在获取后合并到当前分支。换句话说，如果列出了多个远程引用，git pull将创建一个八角形合并。另一方面，如果在命令行上没有列出任何显式的参数，则git pull将获取远程..fetch配置中找到的所有，并仅将第一个合并到当前分支中。这是因为很少进行来自远程引用的八角形操作，而通过获取多个远程头部以一次性跟踪多个远程头部的方式通常很有用。

GIT URLS

通常情况下，URL包含有关传输协议、远程服务器地址和存储库路径的信息。根据传输协议的不同，其中的一些信息可能不存在。

Git支持ssh、git、http和https协议（此外，可以使用ftp和ftps进行获取，但这是低效且已弃用的；请不要使用它们）。

本机传输（即git:// URL）不进行身份验证，应谨慎在不安全的网络上使用。

以下语法可与之一起使用：

• ssh://[user@]host.xz[:port]/path/to/repo.git/
• git://host.xz[:port]/path/to/repo.git/
• http[s]😕/host.xz[:port]/path/to/repo.git/
• ftp[s]😕/host.xz[:port]/path/to/repo.git/

也可以使用类似scp的语法与ssh协议一起使用：

• [user@]host.xz:path/to/repo.git/

仅当在第一个冒号之前没有斜杠时，才会识别此语法。这有助于区分包含冒号的本地路径。例如，本地路径foo:bar可以指定为绝对路径或./foo:bar以避免被误解为ssh url。

ssh和git协议还支持~username扩展：

• ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
• git://host.xz[:port]/~[user]/path/to/repo.git/
• [user@]host.xz:/~[user]/path/to/repo.git/

对于本地存储库，Git本身也支持以下语法：

• /path/to/repo.git/
• file:///path/to/repo.git/

这两种语法在大多数情况下是等效的，除了在克隆时，前者暗示了–local选项。有关详细信息，请参见git-clone[1]。

git clone、git fetch和git pull可以接受适当的捆绑文件。请参见git-bundle[1]。

当Git不知道如何处理某个传输协议时，它会尝试使用远程-远程助手（如果存在）。要显式请求远程助手，可以使用以下语法：

• ::

其中
可以是路径、服务器和路径，或特定远程助手识别的任意类似URL的字符串。有关详细信息，请参见gitremote-helpers[7]。
如果有许多名称相似的远程存储库，并且您希望为它们使用不同的格式（使您使用的URL将被重写为可用的URL），可以创建以下形式的配置部分：

[url "<actual url base>"]
    insteadOf = <other url base>

例如，使用以下内容：

[url "git://git.host.xz/"]
    insteadOf = host.xz:/path/to/
    insteadOf = work:

像"work:repo.git"或"host.xz:/path/to/repo.git"这样的URL将在任何接受URL的上下文中被重写为"git://git.host.xz/repo.git"。

如果只想重写推送的URL，请创建以下形式的配置部分：

[url "<actual url base>"]
    pushInsteadOf = <other url base>

例如，使用以下内容：

[url "ssh://example.org/"]
    pushInsteadOf = git://example.org/

像"git://example.org/path/to/repo.git"这样的URL将在推送时被重写为"ssh://example.org/path/to/repo.git"，但拉取操作仍然使用原始URL。

REMOTES

可以使用以下之一的名称作为参数，而不是URL：

• Git配置文件（$GIT_DIR/config）中的远程。
• $GIT_DIR/remotes目录中的文件。
• $GIT_DIR/branches目录中的文件。

所有这些还允许您省略命令行上的refspec，因为它们每个都包含一个refspec，默认情况下，git将使用该refspec。

配置文件中的命名远程

您可以选择提供先前使用git-remote[1]、git-config[1]甚至通过手动编辑$GIT_DIR/config文件配置的远程的名称。使用此远程的URL将用于访问存储库。默认情况下，在命令行上不提供refspec时，将使用此远程的refspec。配置文件中的条目如下所示：

[remote "<name>"]
    url = <URL>
    pushurl = <pushurl>
    push = <refspec>
    fetch = <refspec>

仅用于推送。它是可选的，并且默认为。对远程进行推送会影响所有定义的pushurls，或者如果未定义pushurls，则会影响所有定义的urls。但是，如果定义了多个URL，则仅从第一个定义的URL获取。

$GIT_DIR/remotes目录中的命名文件

您可以选择提供$GIT_DIR/remotes中的文件的名称。该文件中的URL将用于访问存储库。在命令行上不提供refspec时，该文件中的refspec将作为默认值使用。该文件应具有以下格式：

URL: 上述URL格式之一
Push: <refspec>
Pull: <refspec>

Push:行用于git push，Pull:行用于git pull和git fetch。可以为其他分支映射指定多个Push:和Pull:行。

$GIT_DIR/branches目录中的命名文件

您可以选择提供$GIT_DIR/branches中的文件的名称。该文件中的URL将用于访问存储库。该文件应具有以下格式：

<URL>#<head>

是必需的；#是可选的。

根据操作，git将使用以下之一的refspec，如果命令行上没有提供refspec。在

     G 
    
   
     I 
    
    
    
      T 
     
    
      D 
     
    
   
     I 
    
   
     R 
    
   
     / 
    
   
     b 
    
   
     r 
    
   
     a 
    
   
     n 
    
   
     c 
    
   
     h 
    
   
     e 
    
   
     s 
    
   
     中的此文件的名称是 
    
   
  
    GIT_DIR/branches中的此文件的名称是 
   
  
GITD​IR/branches中的此文件的名称是GIT_DIR/branches中的文件名，默认为master。

git fetch使用：

refs/heads/<head>:refs/heads/<branch>

git push使用：

HEAD:refs/heads/<head>

MERGE STRATEGIES

合并机制（git merge和git pull命令）允许使用-s选项选择后端合并策略。某些策略还可以接受自己的选项，可以通过在git merge和/或git pull中给出-X参数来传递这些选项。

ort
当拉取或合并一个分支时，这是默认的合并策略。此策略只能使用三方合并算法解决两个头。当存在多个可用于三方合并的共同祖先时，它会创建一个合并的共同祖先树，并将其用作三方合并的参考树。根据对来自Linux 2.6内核开发历史的实际合并提交进行的测试，这被认为可以减少合并冲突，而不会导致错误合并。此外，此策略可以检测并处理涉及重命名的合并。它不使用检测到的副本。该算法的名称是一个首字母缩写（“Ostensibly Recursive’s Twin”），来源于它被编写为替代以前的默认算法（递归）。

ort策略可以使用以下选项：

ours
此选项通过优先选择我们的版本来强制解决冲突的块，使其自动解决。与我们的一侧不发生冲突的其他树的更改将反映在合并结果中。对于二进制文件，整个内容都来自我们的一侧。

这不应与ours合并策略混淆，后者根本不考虑另一个树的内容。它丢弃了另一个树所做的一切，声称我们的历史包含其中发生的所有事情。

theirs
这是ours的相反；请注意，与ours不同，没有theirs合并策略来混淆此合并选项。

ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol
将具有指定类型空格更改的行视为三方合并的未更改行。不会忽略与其他更改混合的空格更改。另请参阅git-diff[1] -b，-w，–ignore-space-at-eol和–ignore-cr-at-eol。

如果他们的版本仅引入了对行的空格更改，则使用我们的版本；

如果我们的版本引入了对行的空格更改，但他们的版本包含实质性更改，则使用他们的版本；

否则，合并按照通常的方式进行。

renormalize
在解决三方合并时，运行虚拟的检出和签入操作以处理文件的所有三个阶段。此选项用于在合并具有不同清洁过滤器或行尾规范化规则的分支时使用。有关详细信息，请参见gitattributes[5]中的"Merging branches with differing checkin/checkout attributes"。

no-renormalize
禁用renormalize选项。这将覆盖merge.renormalize配置变量。

find-renames[=]
打开重命名检测，并可选择设置相似度阈值。这是默认设置。这将覆盖merge.renames配置变量。另请参阅git-diff[1] --find-renames。

rename-threshold=
已弃用的find-renames=的同义词。

subtree[=

]

这个选项是一个更高级的子树策略形式，其中策略会猜测两个树应如何移动以匹配彼此进行合并。而是将指定的路径前缀（或从开头删除）以使两个树的形状匹配。

recursive
此策略只能使用三方合并算法解决两个头。当存在多个可用于三方合并的共同祖先时，它会创建一个合并的共同祖先树，并将其用作三方合并的参考树。根据对来自Linux 2.6内核开发历史的实际合并提交进行的测试，这被认为可以减少合并冲突，而不会导致错误合并。此外，它可以检测并处理涉及重命名的合并。它不使用检测到的副本。自Git v0.99.9k至v2.33.0之间，这是解决两个头的默认策略。

递归策略采用与ort相同的选项。然而，还有三个ort忽略（未在上面文档中记录）的额外选项，在递归策略中可能有用：

patience
diff-algorithm=patience的已弃用同义词。

diff-algorithm=[patience|minimal|histogram|myers]
在合并时使用不同的diff算法，可以帮助避免由于不重要的匹配行（例如来自不同函数的大括号）引起的错误合并。另请参阅git-diff[1] --diff-algorithm。请注意，ort特别使用diff-algorithm=histogram，而递归默认使用diff.algorithm配置设置。

no-renames
关闭重命名检测。这将覆盖merge.renames配置变量。另请参阅git-diff[1] --no-renames。

resolve
此选项只能使用三方合并算法解决两个头（即当前分支和从其拉取的另一个分支）。它尝试仔细检测交叉合并的模棱两可性。它不处理重命名。

octopus
这解决了超过两个头的情况，但拒绝执行需要手动解决的复杂合并。它主要用于将主题分支头一起捆绑在一起。这是拉取或合并多个分支时的默认合并策略。

ours
这解决任意数量的头，但合并的结果树始终是当前分支头的树，有效地忽略来自所有其他分支的所有更改。它用于取代旧的边路开发历史记录。请注意，这与递归合并策略的-Xours选项不同。

subtree
这是修改后的ort策略。当合并树A和B时，如果B对应于A的子树，则首先调整B以匹配A的树结构，而不是在相同级别读取树。此调整也对共同祖先树进行。

使用使用三方合并的策略（包括默认的ort）时，如果在两个分支上都进行了更改，但稍后在其中一个分支上撤消了更改，该更改将出现在合并结果中；有些人认为这种行为很困惑。这是因为在执行合并时，只考虑头部和合并基础，而不考虑单独的提交。因此，合并算法将撤消的更改视为根本没有更改，并替换为更改的版本。

默认行为

通常，人们在不提供任何参数的情况下使用git pull。传统上，这相当于说git pull origin。然而，当配置branch..remote存在时，并且处于分支上时，将使用该值而不是origin。

为了确定从何处获取URL以进行fetch操作，将查阅配置的remote..url的值；如果没有这样的变量，则使用$GIT_DIR/remotes/中的URL:行上的值。

为了确定在没有在命令行上提供任何refspec参数的情况下要获取的远程分支（并可选地存储在远程跟踪分支中），将查阅配置变量remote..fetch的值；如果没有，则查阅$GIT_DIR/remotes/，并使用其Pull:行。除了OPTIONS部分中描述的refspec格式之外，还可以使用类似以下的模式匹配refspec：

refs/heads/*:refs/remotes/origin/*

模式匹配的refspec必须具有非空的RHS（即必须将已获取的内容存储在远程跟踪分支中），其LHS和RHS必须以/*结尾。以上指定了所有远程分支都使用refs/remotes/origin/层次结构下的远程跟踪分支进行跟踪，名称相同。

在获取后确定要合并的远程分支的规则有些复杂，以便不会破坏向后兼容性。

如果在git pull命令的命令行上给出了显式refspecs，则所有这些都将被合并。

当在命令行上没有给出refspec时，git pull使用配置或$GIT_DIR/remotes/中的refspec。在这种情况下，将应用以下规则：

如果当前分支的branch..merge配置存在，则将其作为要合并的远程站点的分支名称。

如果refspec是模式匹配的，则不会合并任何内容。

否则，将合并第一个refspec的远程分支。

示例

更新从中克隆的存储库的远程跟踪分支，然后将其中一个合并到当前分支：

$ git pull
$ git pull origin

通常情况下，合并的分支是远程存储库的HEAD，但选择由branch..remote和branch..merge选项确定；有关详细信息，请参阅git-config[1]。

将远程分支next合并到当前分支中：

$ git pull origin next

这会在FETCH_HEAD中暂时留下next的副本，并更新远程跟踪分支origin/next。也可以通过执行fetch和merge来完成相同的操作：

$ git fetch origin
$ git merge origin/next

如果您尝试的pull导致复杂的冲突并且希望重新开始，您可以使用git reset进行恢复。

安全性

提取和推送协议不设计防止一方从另一个存储库窃取未打算共享的数据。如果您有需要保护免受恶意同行窃取的私有数据，则最好的选择是将其存储在另一个存储库中。这适用于客户端和服务器。特别地，服务器上的命名空间对于读取访问控制是无效的；您只应向可以信任具有对整个存储库的读取访问权限的客户端授予对命名空间的读取访问权限。

已知的攻击向量如下：

• 受害者发送“have”行，广告显示它拥有的对象ID，这些对象ID不是明确要共享的，但可以用于优化传输，如果对等方也拥有它们。攻击者选择要窃取的对象ID X，并发送对X的引用，但不需要发送X的内容，因为受害者已经拥有它。现在，受害者相信攻击者拥有X，并稍后将X的内容发送回攻击者。（这种攻击对于客户端对服务器执行最直接，在客户端具有访问权限的命名空间中创建对X的引用，然后将其获取。服务器对客户端执行此操作的最有可能方法是将X“合并”到公共分支中，并希望用户在不注意合并的情况下对此分支进行其他工作并将其推送回服务器。）
• 与＃1类似，攻击者选择要窃取的对象ID X。受害者发送一个攻击者已经拥有的对象Y，并且攻击者错误地声称拥有X而没有Y，因此受害者将Y作为相对于X的增量发送。增量向攻击者显示了X的与Y相似的区域。

BUGS

使用–recurse-submodules目前只能获取已检出子模块中的新提交。例如，如果上游在刚刚获取的超级项目的提交中添加了一个新的子模块，则无法获取该子模块，从而使得稍后在不必再次获取的情况下无法检出该子模块。预计将在将来的Git版本中修复这个问题。

官方链接

官方链接：Git Pull Documentation