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

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

概述

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

语法

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

描述

将远程存储库的更改合并到当前分支中。如果当前分支落后于远程分支，默认情况下会快进当前分支以匹配远程分支。如果当前分支和远程分支发生了分歧，用户需要使用–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
1
2
3
4
5

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

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

有关详细信息，请参阅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]

  声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Gausst松鼠会/article/detail/446613