我是Git的新手，大多数时间我使用git pull origin <my-branch> 来获取远程仓库中的更改。
然而，随着我积累了一些经验，我发现使用git fetch更受欢迎。但是，在阅读了几个主题（例如What is the difference between 'git pull' and 'git fetch'?和Git: Fetch and merge, don’t pull）后，我感到困惑并且需要澄清一下是否有除了在获取更改之前检查更改之外的有效理由来使用git fetch。
总体思路是，
git pull相当于git fetch+git merge，但是肯定存在一些缺点等。
所以，请您解答以下问题：
1.我应该如何从远程更新本地分支？
2.就我所看到的，git pull origin <my-branch>和git pull origin之间的区别是，后者会获取除了<my-branch>以外的所有分支。这是真的吗？我应该选择哪个？
git fetch
git diff ...origin
使用git pull是安全的更新分支的方式。有时会出现冲突，这些情况属于边缘情况。最坏的情况是撤销git pull的更改。
如果您使用git pull origin而不指定“my-branch”，git会将该值填充为您当前使用的分支。
git fetch 然后 git merge，我如何避免使用 git pull 可能会遇到的冲突？ - user17862362git fetch确实会下载文件并将提交完整地更新到您的本地工作站，并更新远程分支（例如：origin/branch_name）；但它不会更改您的本地分支。 - LeGECgit pull 的潜在问题是，它可能会在不提前检查会发生什么的情况下（它一次运行 git fetch + git merge），破坏您的本地更改（如果有的话）。虽然通常这是您想要做的，但当事实证明这是错误的时候，撤消变得非常困难。 - LeGECgit pull之前强烈建议这样做），你可能会遇到你没有预料到的冲突，但至少你可以回滚到你仓库之前的状态。 - LeGECgit pull:
git pull运行git fetch，然后如果你想执行两个 Git 命令，并且 git pull 将要执行的第二个命令是你想要执行的命令，那么使用 git pull 是可以的。
我个人经常喜欢在fetch命令和其他命令之间 插入 一些 额外的 Git 命令。但当使用 git pull 时这是不可能做到的，因为它不会等待你。因此我通常避免使用 git pull。(特别是我经常想运行git log来看看我正在处理什么内容。)
我还发现对于新手来说，他们认为 git pull 是有点神奇的。通过使用分开的两个步骤，而不是使用 git pull，他们学会如何使用 Git。使用 git pull，他们就无法学习如何使用 Git。所以我鼓励新手使用分开的命令。这不仅有助于强调“Git 不是魔法”的部分，而且还有助于区分 git pull 运行的第二个命令是你自己选择的:
git pull 运行 git merge。git pull 运行 git rebase。这两个命令都是合并工作，但它们执行方式是非常不同的。如果您在自己的代码库中没有做任何工作，则与别人共享的工作内容是得到别人的工作，所以无论使用哪个命令都无关紧要。但是，如果您在自己的代码库中做了一些工作，则会有所不同。
当您将这两个命令分开时，其区别就更加明显了：
git merge 表示将我的工作与他们的工作合并： 将“nothing”与“something”合并=“something”；将“something”与“something else”合并=“some third thing”。git rebase 表示在他们的工作之上重新执行我的工作： 在“something”之上重新执行“nothing”=“something”，但是在其他的情况下，您可能会看到这个效果(如果不行，请查阅关于git rebase的相关信息)。针对您的具体问题：
我该如何从远程更新我的本地分支？git pull origin <my-branch>和git pull origin的区别在于，后者会获取除了<my-branch>以外的所有分支，大多数情况下是这样。这时我们真正需要将git pull分解成两个步骤，并观察它给出了什么。git pull时，可以提供选项。例如，以下两种调用git pull的方法都是有效的：git pull --rebase
git pull --ff-only
--rebase表示git pull应该在第二个命令中运行git rebase，而--ff-only表示git pull应该向第二个命令提供--ff-only选项，这意味着它应该运行git merge而不是git rebase。pull应该使用哪个第二个命令。其他选项被传递给第二个命令。还有一些选项被传递到第一个git fetch命令。这有点令人困惑，这也是学习git fetch 首先的又一个原因。<my-branch>。您提供的所有非选项参数都将传递给git fetch。通过-或--标识可将参数与选项区分开来。（单横线-选项是单个字母，例如-j或-4;双横线--选项是多个字母，例如--rebase和--show-forced-updates。）origin和<my-branch>这样的参数，它们将传递给git fetch，并影响git fetch的操作方式。没有参数时，git fetch将：
找到正确的远程连接（通常是 origin）：一个"remote"是一个简短的名称，用来访问另一个Git软件，这里会从另一个Git仓库读取内容。在这种情况下，你想要访问GitHub、Bitbucket或GitLab等平台上的某个Git软件，它们上面有你之前创建的Git仓库所在的Git仓库。现在你想要访问相同的Git仓库，并查看它们是否有任何你的Git仓库还没有的新提交。（那些提交是如何出现的？我们稍后再担心这个问题。）
调用该软件并连接到该仓库。该仓库有它的分支和它的提交。该仓库中的分支不是你的分支！他们是他们的分支。它们可能在其中存储了不同的提交哈希值。
根据存储在其各个分支名称中的哈希ID，确定它们有哪些提交，而你没有，并决定哪些提交是你想要在你的仓库中的。
如果你在git fetch命令中没有列出某些分支名称，则你的Git会默认更新所有分支的所有副本。因此，你的Git将检查它们的master或main、develop和feature/short或feature/long或feature/tall等分支。你的Git将确定它们是否有任何你没有的新提交，并将这些提交带到你的Git仓库中。
由于提交是用全局唯一标识符编号的，因此你的Git（你的运行在你的仓库上的软件）现在将拥有所有他们的提交，并使用相同的编号。你的Git还将拥有他们没有的全部自己的提交。现在，你的Git已经获得了所有他们的提交，你的Git将创建或更新所有你的远程跟踪名称：origin/main或origin/master代表他们的main或master，origin/develop代表他们的develop，以此类推。你的Git通过在每个他们的分支名称前添加remote名称 origin 来构建这些名称。
git fetch会更新所有这些远程跟踪分支，因为不带参数的git pull实际上是调用了不带参数的git fetch，所以你的所有origin/*名称都将得到更新。当使用一个参数时，像git pull origin，同样的事情会发生，只不过现在你明确地表达了你想要使用名称为origin的远程仓库。如果这是你唯一的远程仓库——这是一种典型的设置——那么这将完全相同；任何其他的名称，比如git fetch belgium或其他什么的，都将导致错误。git fetch origin develop，那么这告诉你的Git，对于这个git fetch操作，你希望你的Git访问他们的Git，查看它们的所有分支，但是限制更新只更新你的origin/develop所需的提交。如果他们的main有一个新提交，你不会更新你的origin/main。（你几乎肯定希望或必须稍后这样做，所以这并没有真正为你节省多少时间。实际上，由于Git优化获取的方式，这可能会导致稍后需要更多时间，而不是一次性完成所有操作。但如果你想要，这个选项是存在的。）git pull将所有参数传递下去，因此git pull origin develop指示你的git fetch步骤限制其自身到名为develop的远程分支。（同样的操作也会更新你的origin/develop）git fetch之后，无论它使用了什么额外的选项和参数，你的git pull现在运行了你选择的第二个命令。（你确定自己选择了一个吗？总是确保你知道Git将在这里运行哪个第二个命令！大多数人都会设置一个半永久的，这样他们就知道了。）第二个命令可以是：git rebase [options argument(s)]
git merge options argument(s)
Git 的 pull 命令 通常会在此处传递一些选项和/或参数。特别地，对于 git merge 命令，它会传递：
-m "merge branch '<branch>' of <url>"
设置合并信息，然后传递您引入的最新提交的原始哈希ID。对于rebase，它可能会传递--autostash，也可能会传递提交哈希ID（或者可以让rebase自行找出@{upstream}）。虽然您不需要了解所有这些内容，但值得记住的是，git pull为git merge功能提供了一些额外的操作，以设置合并消息。
这里还有一个最后的警告：
git pull origin br1 br2
对于新手来说，使用 不要使用 的方法是很诱人的。它运行了 git fetch origin br1 br2 然后运行一个 章鱼合并 (实际上是 HEAD, origin/br1 和 origin/br2 的合并)，除非你真的知道自己在做什么，否则你不想要一个章鱼合并。
如果你将 git pull 设置为 始终运行 git rebase，那么你自己运行 git fetch 然后再运行 git rebase 和只运行 git pull 没有太大区别。这是因为没有合并消息需要修改。但在执行此操作之前，请确保你知道 rebase 做了什么：rebase 比合并更加复杂。
如果你将 git pull 设置为 始终运行 git merge，则 pull 执行的抓取-合并操作具有一定的优点 (?) ，可以将合并消息设置为比两个单独的命令得到的默认消息略微好一些。比较：
merge branch 'smörgåsbord' of ssh://github.com/swedish/meatballs.git
vs:
merge branch 'origin/smörgåsbord'
两者都没有提供任何有用的信息，但有些人可能更喜欢其中一个。
小心使用 git pull <remote> <branch1> <branch2>，几乎肯定会出错（尽管如果你设置为rebase，这应该只会给你一个错误；在此情况下进行rebase没有意义）。
如果你想要在两个命令之间运行一个命令（例如git log），以便选择使用哪个第二个命令，则不能使用一次完成所有操作的 git pull。这就是我避免使用 git pull 的原因和时间。
除此之外，它们基本上是相同的东西，一旦你知道 git pull 只是为你运行两个Git命令。
fetch后跟随merge，或者在运行fetch时是否有设置可以自动执行merge？ - user17862362git merge 执行快进操作而不是合并，而 git fetch 可以执行快进操作。但在非常熟悉所有这些含义以及 Git 如何使用 refs 和 refspecs 之前，请勿执行此操作。我实际上喜欢 git pull 执行仅快进操作，当失败时则失败合并；自 Git 2.29 以来，现在有一个设置可以做到这一点，但在 2.34 之前它有些问题。因此，我通常不会在这里写关于它的内容：它太新了。 - torekgit fetch，那么我应该通过以下两个命令来使用它：git fetch origin <feature-branch>，然后（当我在这个特性分支上时）git merge <feature-branch>。这是正确的吗？ - user17862362git fetch，然后是 git merge。这取决于一个前提条件，即当前分支需要有Git所谓的上游(upstream)设置。如果没有，我建议使用git fetch(不带任何额外参数)和git merge origin/somebranch。请注意，在使用拆分变体时，您需要提供在另一个Git中看到的本地内存名称。在使用git pull origin somebranch变体时，您需要提供在另一个Git中看到的其他Git的名称。 - torek我并不是基于文档编写的，而是基于一些经验。虽然不多，但或许有所帮助。
通常情况下，单个存储库永远不会使用 fetch 命令，但如果你正在 fork 或者拥有多个远程存储库，则只有 fetch 有用或经常被使用。
git fetch + git merge 而不是 git pull？ - user17862362git config --global pull.rebase true
git config --global rebase.autoStash true
这样，在获取之后，简单的git pull会触发将我的本地提交变基到获取的远程分支之上。
我唯一看到的缺点是可能需要多次解决冲突，即在git pull之后再进行git pull。但如果您处于这种情况（相当罕见），那么git rerere就可以避免这种情况。
请参阅 "什么是git-rerere，它是如何工作的？"
关于优点：请参阅 "使用git pull --rebase是否比使用git pull --ff-only更好".
git pull，但在使用之前，您能否请明确一下这种方法可能存在的缺点？ - user17862362如果我要获取别人推送的新分支，我会使用git fetch。 假设我想查看Mary在她的featureB分支上的最新更改。
我会执行以下操作：
git checkout featureB
git pull origin featureB
这将获取featureB的最新元数据，并将其合并到我的当前featureB副本中。
但是，如果我从未拉取过featureB，则无法检出featureB。
如果我当前已经检出了自己的分支featureA，则不想执行git pull origin featureB，因为那会获取featureB，然后将其合并到我的featureA分支中。
因此，我这样做：
git fetch origin featherB
git checkout featureB
现在我在本地仓库中有一个名为featureB的分支。
既然我现在在本地仓库中有了featureB分支，下次想要从远程仓库更新它时就可以使用checkout命令。
假设我已经检出了featureA分支，现在想要获取featureB的最新版本。我可以执行以下操作：
git checkout featureB
git pull origin featureB
git pull在任何形式下都没有问题。你只需要了解它的作用，看它是否符合你当前的需求即可。 - Marek R