mirror of
https://github.com/fofolee/uTools-Manuals.git
synced 2025-06-08 23:14:06 +08:00
22 lines
45 KiB
HTML
22 lines
45 KiB
HTML
<div class="c-markdown doc-markdown"><div class="doc-postil"><div class="c-markdown"><h2>Name</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>git-pull - 从另一个存储库或本地分支获取并与其集成</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>概要</h2></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git pull [options] [<repository> [<refspec>…]]</pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>描述</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>将远程存储库中的更改合并到当前分支中。在其默认模式下，<code>git pull</code>是<code>git fetch</code>后面的简写<code>git merge FETCH_HEAD</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>更确切地说，使用给定的参数<code>git pull</code>运行<code>git fetch</code>并调用<code>git merge</code>将检索到的分支头合并到当前分支中。与<code>--rebase</code>，它运行，<code>git rebase</code>而不是<code>git merge</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><repository> 应该是传递给 git-fetch [1]的远程仓库的名称。
|
||
|
||
<refspec> 可以为任意的远程参考（例如，标签的名称）或者甚至是具有相应远程跟踪分支的参考集合（例如，refs / heads / *：refs / remotes / origin / *）命名，但是通常它是远程存储库中分支的名称。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>从 git-branch [1]设置的当前分支的“remote”和“merge”配置中读取 <repository> 和 <branch> 的默认值<code>--track</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>假设存在以下历史记录并且当前分支是“ <code>master</code>”：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> A---B---C master on origin /
|
||
|
||
D---E---F---G master ^
|
||
|
||
origin/master in your repository</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>然后，“ <code>git pull</code>”将从远程<code>master</code>分支获取并重放更改，因为它从本地<code>master</code>（即<code>E</code>）分离，直到其当前的
|
||
|
||
commit（<code>C</code>），<code>master</code>并将结果记录在新的提交中以及两个父提交的名称和来自用户的描述更改的日志消息。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> A---B---C origin/master / \
|
||
|
||
D---E---F---G---H master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>有关详细信息，请参阅 git-merge [1]，包括如何呈现和处理冲突。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在 Git 1.7.0 或更高版本中，要取消冲突的合并，请使用<code>git reset --merge</code>。<strong>警告</strong>：在较旧版本的 Git 中，<code>git pull</code>不鼓励使用未提交的更改运行：尽管可能，但它会使您处于可能很难在冲突情况下退出的状态。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果任何远程更改与本地未提交的更改重叠，则合并将自动取消并且工作树不受影响。通常最好在使用 git-stash [1]提取或存储它们之前，先在工作顺序中进行任何本地更改。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>选项</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>-q --quiet</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这被传递给底层的 git-fetch，以便在传输过程中压制报告，并在合并过程中将潜在的 git-merge 压制成静噪输出。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-v --verbose</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Pass --verbose git-fetch 和 git-merge。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--no-递归-子模块= YES |on-demand| 无</p></div></div><div class="doc-postil"><div class="c-markdown"><p>该选项控制是否应该提取和更新所有已填充子模块的新提交（请参阅 git-config [1] 和 gitmodules [5]）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果校验通过 rebase 完成，则本地子模块提交也会重新发布。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果更新是通过合并完成的，则子模块冲突将被解析并检出。</p></div></div><div class="doc-postil"><div class="c-markdown"><h3>与合并有关的选项</h3></div></div><div class="doc-postil"><div class="c-markdown"><p>--commit --no-commit</p></div></div><div class="doc-postil"><div class="c-markdown"><p>执行合并然后提交结果。这个选项可以用来覆盖 --no-commit。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用 --no-commit 执行合并，但假装合并失败并且不自动提交，以使用户有机会在提交之前检查并进一步调整合并结果。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--edit -e --no-edit</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在提交成功的机械合并之前调用编辑器来进一步编辑自动生成的合并消息，以便用户可以解释并验证合并。<code>--no-edit</code>选项可用于接受自动生成的消息（这通常是不鼓励的）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>较旧的脚本可能取决于不允许用户编辑合并日志消息的历史行为。他们将在运行时看到编辑器打开<code>git merge</code>。为了更容易地将这些脚本调整为更新的行为，<code>GIT_MERGE_AUTOEDIT</code>可以将环境变量设置为<code>no</code>它们的开头。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--ff</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当合并解析为快进时，只更新分支指针，而不创建合并提交。这是默认行为。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--no-ff</p></div></div><div class="doc-postil"><div class="c-markdown"><p>即使合并解析为快进，也可以创建合并提交。这是合并注释（可能有符号）标记时的默认行为。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--ff-only</p></div></div><div class="doc-postil"><div class="c-markdown"><p>拒绝合并而后以非零状态退出，除非电流<code>HEAD</code>已经是最新的或合并可以解决为快进。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--log=<n> --no-log</p></div></div><div class="doc-postil"><div class="c-markdown"><p>除了分支名称之外，还可以用来自至多 <n> 实际提交的单行描述来填充日志消息。另请参阅 git-fmt-merge-msg [1]。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用 --no-log 不会列出要合并的实际提交的单行描述。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--stat -n --no-stat</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在合并结束时显示 diffstat。diffstat 也由配置选项 merge.stat 控制。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用 -n 或 --no-stat 不会在合并结束时显示 diffstat 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--squash --no-squash</p></div></div><div class="doc-postil"><div class="c-markdown"><p>生成工作树和索引状态，就像发生真正的合并（合并信息除外）一样，但实际上并未进行提交，移动<code>HEAD</code>或记录<code>$GIT_DIR/MERGE_HEAD</code>（以导致下一个<code>git commit</code>命令创建合并提交）。这允许您在当前分支上创建一个单独的提交，其效果与合并另一个分支相同（或者在章鱼的情况下更多）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>用 --no-squash 执行合并并提交结果。这个选项可以用来覆盖 --squash。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-s <strategy> --strategy=<strategy></p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用给定的合并策略; 可以多次提供，以按照他们应该尝试的顺序指定它们。如果没有<code>-s</code>选项，则使用内置策略列表（否则<code>git merge-recursive</code>合并单个头部时<code>git merge-octopus</code>）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-X <option> --strategy-option=<option></p></div></div><div class="doc-postil"><div class="c-markdown"><p>将合并策略特定选项传递给合并策略。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--verify-signatures --no-verify-signatures</p></div></div><div class="doc-postil"><div class="c-markdown"><p>验证被合并的分支的提示提交是否使用有效密钥签名，即具有有效 uid 的密钥：在默认信任模型中，这意味着签名密钥已由可信密钥签名。如果侧分支的提示提交未使用有效密钥进行签名，则会中止合并。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--summary --no-summary</p></div></div><div class="doc-postil"><div class="c-markdown"><p>同义词 --stat 和 --no-stat; 这些已被弃用，并将在未来被删除。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--allow-unrelated-histories</p></div></div><div class="doc-postil"><div class="c-markdown"><p>默认情况下，<code>git merge</code>命令拒绝合并不共享上代的历史记录。在合并两个独立开始他们的生活的项目的历史时，可以使用此选项来覆盖此安全性。由于这是非常罕见的情况，因此默认情况下不存在配置变量，因此不会添加该变量。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-r --rebase = false | true | preserve | interactive</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果为 true，则在获取后重新绑定上游分支顶部的当前分支。如果存在与上游分支相对应的远程跟踪分支，并且上游分支自上次获取后重新分配，则重新分配使用该信息以避免重新分配非本地更改。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>设置为保留时，使用<code>--preserve-merges</code>传递给选项的
|
||
|
||
rebase，<code>git rebase</code>以便本地创建的合并提交不会变平。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果为 false，则将当前分支合并到上游分支中。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当<code>interactive</code> ，使得交互模式重新调整。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果你想让<code>git pull</code>经常使用 <code>--rebase</code>而不是合并，看pull.rebase，branch.<name>.rebase 和branch.autoSetupRebase在 git-config [1]，</p><p><br/></p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>Note</p></div></th><th style="text-align: left;"><div class="table-header"><p>This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase1 carefully.</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>--no-rebase</p></div></div><div class="doc-postil"><div class="c-markdown"><p>早先覆盖--rebase。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--autostash --no-autostash</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在开始 rebase 之前，如果需要，将局部修改存储（请参阅 git-stash [1]），并在完成时应用存储条目。<code>--no-autostash</code>可以覆盖<code>rebase.autoStash</code>配置变量（请参阅 git-config [1]）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>该选项仅在使用“--rebase”时有效。</p></div></div><div class="doc-postil"><div class="c-markdown"><h3>与 <strong>fetch </strong>相关的选项</h3></div></div><div class="doc-postil"><div class="c-markdown"><p>--all</p></div></div><div class="doc-postil"><div class="c-markdown"><p>取回所有远端。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-a --append</p></div></div><div class="doc-postil"><div class="c-markdown"><p>追加 refs 的 ref 名称和对象名称到现有的内容<code>.git/FETCH_HEAD</code>。如果没有这个选项，旧的数据<code>.git/FETCH_HEAD</code>将被覆盖。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--depth=<depth></p></div></div><div class="doc-postil"><div class="c-markdown"><p>将提取限制为从每个远程分支历史记录的提示中指定的提交数量。如果获取到由<code>git clone</code>创建的 --depth=<depth> 选项（请参阅 git-clone [1]），请将历史记录加深或缩短为指定的提交数。深化提交的标签不会被提取。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--deepen=<depth></p></div></div><div class="doc-postil"><div class="c-markdown"><p>与 --depth 相似，只是它指定了来自当前浅层边界而不是每个远程分支历史记录的提示的提交数。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--shallow-since=<date></p></div></div><div class="doc-postil"><div class="c-markdown"><p>加深或缩短浅储存库的历史记录以在 <date> 之后包含所有可访问的提交。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--shallow-exclude=<revision></p></div></div><div class="doc-postil"><div class="c-markdown"><p>加深或缩短浅储存库的历史记录以排除可从指定远程分支或标记访问的提交。该选项可以多次指定。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--unshallow</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果源存储库已完成，请将浅层存储库转换为完整存储库，以消除浅存储库施加的所有限制。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果源存储库较浅，则尽可能多地获取，以便当前存储库具有与源存储库相同的历史记录。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--update-shallow</p></div></div><div class="doc-postil"><div class="c-markdown"><p>默认情况下，从浅仓库中获取时，<code>git fetch</code>拒绝需要更新 .git / shallow 的引用。该选项更新 .git / shallow 并接受此类参考。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-f --force</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当<code>git fetch</code>与<code><rbranch>:<lbranch></code> refspec 一起使用时，它拒绝更新本地分支<code><lbranch></code>，除非<code><rbranch></code>获取的远程分支是后代<code><lbranch></code>。该选项将覆盖该检查。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-k --keep</p></div></div><div class="doc-postil"><div class="c-markdown"><p>持续下载的包。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--no-tags</p></div></div><div class="doc-postil"><div class="c-markdown"><p>默认情况下，指向从远程存储库下载的对象的标签将在本地获取并存储。该选项将禁用此自动标记。远程的默认行为可以通过远程。<name> .tagOpt 设置指定。请参阅 git-config [1]。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-u --update-head-ok</p></div></div><div class="doc-postil"><div class="c-markdown"><p>默认情况下<code>git fetch</code>拒绝更新对应于当前分支的前端。此标志禁用检查。这纯粹是供内部使用<code>git pull</code>来沟通<code>git fetch</code>，除非你是该项目的拥有者，否则你不应该使用它。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--upload-pack <upload-pack></p></div></div><div class="doc-postil"><div class="c-markdown"><p>当给出并且从中获取的存储库被处理时<code>git fetch-pack</code>，<code>--exec=<upload-pack></code>被传递给该命令以指定在另一端运行的命令的非默认路径。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--progress</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当连接到终端时，默认情况下，标准错误流中会报告进度状态，除非指定了 -q 。即使标准错误流未定向到终端，此标志也会强制进度状态。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-4 --ipv4</p></div></div><div class="doc-postil"><div class="c-markdown"><p>仅使用 IPv4 地址，忽略 IPv6 地址。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-6 --ipv6</p></div></div><div class="doc-postil"><div class="c-markdown"><p>仅使用 IPv6 地址，忽略 IPv4 地址。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><repository></p></div></div><div class="doc-postil"><div class="c-markdown"><p>作为提取或拉取操作源的“远程”存储库。此参数可以是 URL（请参阅下面的 GIT URLS 部分）或远程名称（请参阅下面的
|
||
|
||
REMOTES 部分）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><refspec></p></div></div><div class="doc-postil"><div class="c-markdown"><p>指定要获取哪些引用以及哪些本地引用要更新。当命令行中没有
|
||
|
||
<refspec> 时，<code>remote.<repository>.fetch</code>取而代之的是从变量中读取（参见 git-fetch [1]）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一个 <refspec> 参数的格式是一个可选的 plus <code>+</code>，后跟 source <src>，后跟一个冒号<code>:</code>，后跟目标 ref <dst>。当
|
||
|
||
<dst> 为空时，可以省略冒号。<src> 通常是 ref，但它也可以是拼写完整的十六进制对象名称。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>tag <tag></code>意味着与<code>refs/tags/<tag>:refs/tags/<tag></code>相同; 它请求将所有内容都提取到给定的标签。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>匹配 <src> 的远程 ref 被取出，如果 <dst> 不是空字符串，匹配它的本地引用使用 <src> 进行快速转发。如果使用可选的 plus <code>+</code>，即使不引起快速更新，本地 ref 也会被更新。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>Note</p></div></th><th style="text-align: left;"><div class="table-header"><p>When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that its new tip will not be descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched). You would want to use the + sign to indicate non-fast-forward updates will be needed for such branches. There is no way to determine or declare that a branch will be made available in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch.</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>Note</p></div></th><th style="text-align: left;"><div class="table-header"><p>There is a difference between listing multiple <refspec> directly on git pull command line and having multiple remote.<repository>.fetch entries in your configuration for a <repository> and running a git pull command without any explicit <refspec> parameters. <refspec>s listed explicitly on the command line are always merged into the current branch after fetching. In other words, if you list more than one remote ref, git pull will create an Octopus merge. On the other hand, if you do not list any explicit <refspec> parameter on the command line, git pull will fetch all the <refspec>s it finds in the remote.<repository>.fetch configuration and merge only the first <refspec> found into the current branch. This is because making an Octopus from remote refs is rarely done, while keeping track of multiple remote heads in one-go by fetching more than one is often useful.</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><h2>Git 网址</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>通常，URL 包含有关传输协议，远程服务器地址和存储库路径的信息。根据传输协议，这些信息可能不存在。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Git 支持 ssh，git，http 和 https 协议（另外，ftp 和 ftps 可用于提取，但效率低下，不推荐使用;不要使用它）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>本地传输（即 git：// URL）不进行身份验证，因此在不安全的网络上应谨慎使用。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>以下语法可以与它们一起使用：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>ssh://user@host.xz:port/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>git://host.xz:port/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>https://host.xz:port/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>ftps://host.xz:port/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>ssh 协议也可以使用另一种类似 scp 的语法：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>user@host.xz：path / to / repo.git /只有在第一个冒号前没有斜线时才能识别此语法。这有助于区分包含冒号的本地路径。例如，本地路径<code>foo:bar</code>可以被指定为绝对路径或<code>./foo:bar</code>避免被误解为 ssh url。ssh 和 git 协议还支持〜用户名扩展：</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>ssh://user@host.xz:port/~user/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>git://host.xz:port/~user/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>user@host.xz:/~user/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>对于本地支持的本地存储库，可以使用以下语法：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>/path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>file:///path/to/repo.git/</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>这两种语法大多是相同的，除了克隆时，前者意味着 --local 选项。有关详细信息，请参阅 git-clone [1]。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当 Git 不知道如何处理某个传输协议时，它会尝试使用<code>remote-<transport></code>远程助手（如果存在）。要显式请求远程助手，可以使用以下语法：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p><transport>::<address>where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers[1] for details.If there are a large number of similarly-named remote repositories and you want to use a different format for them (such that the URLs you use will be rewritten into URLs that work), you can create a configuration section of the form: [url "<actual url base>"]
|
||
|
||
insteadOf = <other url base>For example, with this: [url "git://git.host.xz/"]
|
||
|
||
insteadOf = host.xz:/path/to/
|
||
|
||
insteadOf = work:a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".If you want to rewrite URLs for push only, you can create a configuration section of the form: [url "<actual url base>"]
|
||
|
||
pushInsteadOf = <other url base>For example, with this: [url "ssh://example.org/"]
|
||
|
||
pushInsteadOf = git://example.org/a URL like "git://example.org/path/to/repo.git" will be rewritten to "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL.RemotesThe name of one of the following can be used instead of a URL as <code><repository></code> argument:</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>a remote in the Git configuration file: <code>$GIT_DIR/config</code>,</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>a file in the <code>$GIT_DIR/remotes</code> directory, or</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>a file in the <code>$GIT_DIR/branches</code> directory.</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default.</p></div></div><div class="doc-postil"><div class="c-markdown"><h3>Named remote in configuration file</h3></div></div><div class="doc-postil"><div class="c-markdown"><p>You can choose to provide the name of a remote which you had previously configured using git-remote[1], git-config[1] or even by a manual edit to the <code>$GIT_DIR/config</code> file. The URL of this remote will be used to access the repository. The refspec of this remote will be used by default when you do not provide a refspec on the command line. The entry in the config file would appear like this:</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> [remote "<name>"]
|
||
|
||
url = <url>
|
||
|
||
pushurl = <pushurl>
|
||
|
||
push = <refspec>
|
||
|
||
fetch = <refspec></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>The <code><pushurl></code> is used for pushes only. It is optional and defaults to <code><url></code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><h3>Named file in <code>$GIT_DIR/remotes</code></h3></div></div><div class="doc-postil"><div class="c-markdown"><p>You can choose to provide the name of a file in <code>$GIT_DIR/remotes</code>. The URL in this file will be used to access the repository. The refspec in this file will be used as default when you do not provide a refspec on the command line. This file should have the following format:</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> URL: one of the above URL format
|
||
|
||
Push: <refspec>
|
||
|
||
Pull: <refspec></pre></div></div><div class="doc-postil"><div class="c-markdown"><p><code>Push:</code> lines are used by <code>git push</code> and <code>Pull:</code> lines are used by <code>git pull</code> and <code>git fetch</code>. Multiple <code>Push:</code> and <code>Pull:</code> lines may be specified for additional branch mappings.</p></div></div><div class="doc-postil"><div class="c-markdown"><h3>Named file in <code>$GIT_DIR/branches</code></h3></div></div><div class="doc-postil"><div class="c-markdown"><p>You can choose to provide the name of a file in <code>$GIT_DIR/branches</code>. The URL in this file will be used to access the repository. This file should have the following format:</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> <url>#<head></pre></div></div><div class="doc-postil"><div class="c-markdown"><p><code><url></code> is required; <code>#<head></code> is optional.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Depending on the operation, git will use one of the following refspecs, if you don’t provide one on the command line. <code><branch></code> is the name of this file in <code>$GIT_DIR/branches</code> and <code><head></code> defaults to <code>master</code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>git fetch uses:</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> refs/heads/<head>:refs/heads/<branch></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>git push uses:</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> HEAD:refs/heads/<head></pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>Merge strategies</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>The merge mechanism (<code>git merge</code> and <code>git pull</code> commands) allows the backend <code>merge strategies</code> to be chosen with <code>-s</code> option. Some strategies can also take their own options, which can be passed by giving <code>-X<option></code> arguments to <code>git merge</code> and/or <code>git pull</code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>resolve</p></div></div><div class="doc-postil"><div class="c-markdown"><p>This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>recursive</p></div></div><div class="doc-postil"><div class="c-markdown"><p>This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>The <code>recursive</code> strategy can take the following options:</p></div></div><div class="doc-postil"><div class="c-markdown"><p>ours</p></div></div><div class="doc-postil"><div class="c-markdown"><p>This option forces conflicting hunks to be auto-resolved cleanly by favoring <code>our</code> version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>This should not be confused with the <code>ours</code> merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring <code>our</code> history contains all that happened in it.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>theirs</p></div></div><div class="doc-postil"><div class="c-markdown"><p>This is the opposite of <code>ours</code>; note that, unlike <code>ours</code>, there is no <code>theirs</code> merge stragegy to confuse this merge option with.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>patience</p></div></div><div class="doc-postil"><div class="c-markdown"><p>With this option, <code>merge-recursive</code> spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e.g., braces from distinct functions). Use this when the branches to be merged have diverged wildly. See also git-diff[1] <code>--patience</code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>diff-algorithm=patience|minimal|histogram|myers</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Tells <code>merge-recursive</code> to use a different diff algorithm, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff[1] <code>--diff-algorithm</code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>ignore-space-change ignore-all-space ignore-space-at-eol</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] <code>-b</code>, <code>-w</code>, and <code>--ignore-space-at-eol</code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>If <code>their</code> version only introduces whitespace changes to a line, <code>our</code> version is used;</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>If <code>our</code> version introduces whitespace changes but <code>their</code> version includes a substantial change, <code>their</code> version is used;</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>Otherwise, the merge proceeds in the usual way. renormalize This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details. no-renormalize Disables the <code>renormalize</code> option. This overrides the <code>merge.renormalize</code> configuration variable. no-renames Turn off rename detection. See also git-diff[1] <code>--no-renames</code>. find-renames=<n> Turn on rename detection, optionally setting the similarity threshold. This is the default. See also git-diff[1] <code>--find-renames</code>. rename-threshold=<n> Deprecated synonym for <code>find-renames=<n></code>. subtree=<path> This option is a more advanced form of <code>subtree</code> strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match. octopus This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch. ours This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the <code>recursive</code> merge strategy. subtree This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.With the strategies that use 3-way merge (including the default, <code>recursive</code>), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.Default behaviourOften people use <code>git pull</code> without giving any parameter. Traditionally, this has been equivalent to saying <code>git pull origin</code>. However, when configuration <code>branch.<name>.remote</code> is present while on branch <code><name></code>, that value is used instead of <code>origin</code>.In order to determine what URL to use to fetch from, the value of the configuration <code>remote.<origin>.url</code> is consulted and if there is not any such variable, the value on the <code>URL:</code> line in <code>$GIT_DIR/remotes/<origin></code> is used.In order to determine what remote branches to fetch (and optionally store in the remote-tracking branches) when the command is run without any refspec parameters on the command line, values of the configuration variable <code>remote.<origin>.fetch</code> are consulted, and if there aren’t any, <code>$GIT_DIR/remotes/<origin></code> is consulted and its <code>Pull:</code> lines are used. In addition to the refspec formats described in the OPTIONS section, you can have a globbing refspec that looks like this:refs/heads/*:refs/remotes/origin/*A globbing refspec must have a non-empty RHS (i.e. must store what were fetched in remote-tracking branches), and its LHS and RHS must end with <code>/*</code>. The above specifies that all remote branches are tracked using remote-tracking branches in <code>refs/remotes/origin/</code> hierarchy under the same name.The rule to determine which remote branch to merge after fetching is a bit involved, in order not to break backward compatibility.If explicit refspecs were given on the command line of <code>git pull</code>, they are all merged.When no refspec was given on the command line, then <code>git pull</code> uses the refspec from the configuration or <code>$GIT_DIR/remotes/<origin></code>. In such cases, the following rules apply:</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>If <code>branch.<name>.merge</code> configuration for the current branch <code><name></code> exists, that is the name of the branch at the remote site that is merged.</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>If the refspec is a globbing one, nothing is merged.</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>Otherwise the remote branch of the first refspec is merged.</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><h2>Examples</h2></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>Update the remote-tracking branches for the repository you cloned from, then merge one of them into your current branch:
|
||
|
||
$ git pull $ git pull originNormally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch.<name>.remote and branch.<name>.merge options; see git-config[1] for details.</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>Merge into the current branch the remote branch <code>next</code>:</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>$ git pull origin next</p></div></div><div class="doc-postil"><div class="c-markdown"><p>This leaves a copy of <code>next</code> temporarily in FETCH_HEAD, but does not update any remote-tracking branches. Using remote-tracking branches, the same can be done by invoking fetch and merge:</p></div></div><div class="doc-postil"><div class="c-markdown"><p>$ git fetch origin $ git merge origin/next</p></div></div><div class="doc-postil"><div class="c-markdown"><p>If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with <code>git reset</code>.</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>Security</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers. In particular, namespaces on a server are not effective for read access control; you should only grant read access to a namespace to clients that you would trust with read access to the entire repository.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>The known attack vectors are as follows:</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>The victim sends "have" lines advertising the IDs of objects it has that are not explicitly intended to be shared but can be used to optimize the transfer if the peer also has them. The attacker chooses an object ID X to steal and sends a ref to X, but isn’t required to send the content of X because the victim already has it. Now the victim believes that the attacker has X, and it sends the content of X back to the attacker later. (This attack is most straightforward for a client to perform on a server, by creating a ref to X in the namespace the client has access to and then fetching it. The most likely way for a server to perform it on a client is to "merge" X into a public branch and hope that the user does additional work on this branch and pushes it back to the server without noticing the merge.)</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>As in #1, the attacker chooses an object ID X to steal. The victim sends an object Y that the attacker already has, and the attacker falsely claims to have X and not Y, so the victim sends Y as a delta against X. The delta reveals regions of X that are similar to Y to the attacker.</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><h2>Bugs</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself can not be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version.</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>See also</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>git-fetch[1], git-merge[1], git-config[1]</p></div></div></div> |