我是git的初学者，并尝试在Windows上使用它。
我在Bitbucket上建立了一个存储库。通过Bitbucket在线向主分支添加了三个文件（SAY A，B，C）。
现在我的本地PC上有文件夹，我使用git fetch来获取这三个文件。现在有三个文件位于本地存储库中。
现在，我在bitbucket上添加了另一个文件（SAY D），并更改了所有三个文件（A，B，C）的内容。
现在，如果我尝试通过git fetch MY_REMOTE master获取更改，我在本地没有任何更改。但
git pull MY_REMOTE master，我可以看到更改。 git checkout MY_REMOTE/master，我可以看到更改。
所以我有疑问，
git fetch只是将本地不存在的更改复制到本地存储，但本地存储更改了相同的副本。为什么git fetch无法在这里工作？
我不明白在本地做git checkout MY_REMOTE/master的目的。我为什么要那样做 ？
答案 0 :(得分：2)
使用＆＃34; git pull --rebase＆＃34;将您的更改从远程同步到本地。
这是git fetch的答案 git fetch实际上只从远程存储库下载新数据 - 但它并没有将任何这些新数据集成到您的工作文件中。 Fetch非常适合获取远程存储库中发生的所有事情的全新视图。
Git checkout，用于切换存储库的分支。 只需谷歌，您将获得大量信息：。
答案 1 :(得分：2)
正如您所提到的，git fetch只是将远程更改提取到本地计算机。它不适用它们。
git checkout MY_REMOTE/master将获取的更改应用于文件的本地副本。 警告：如果您的本地文件已被修改（并且未提交），则当您键入git checkout MY_REMOTE/master时，您的本地更改将会丢失。
同时应用远程和本地更改
git commit -a -m "my commit" git pull origin master 这将合并两个更改集（本地和远程）
或者，您可以使用pull --rebase origin master首先应用本地提交，然后应用远程提交。
答案 2 :(得分：1)
Git＆＃39; s fetch无法获得文件，但不是直接获取文件。
在某种程度上，Git根本不关心文件。 Git关心的是提交。然而，在我们进一步访问这个想法之前，我们应该回顾一些基本的Git定义。
Git存储库有三个主要部分：提交，索引和工作树。 （一些Git存储库将省略工作树，在较新版本的Git中，您可以拥有多个工作树，其中每个工作树都有自己的索引。但一般来说，每个工作树都有一个。）
commit 是一个快照：一个完整的 set 文件。它不仅仅是一个文件，它也不是某些文件中的差异：它是一个独立的东西，包含所有文件你决定以他们保存时的形式保存在该提交中。提交也是永久性的，不变的。与所有Git对象一样，它具有唯一标识符：3313b78c145ba9212272b5318c111cde12bfef4a。存储后，您永远不能在提交中更改任何。如果您尝试，您将获得提交的副本，并进行更改，并且副本具有新的不同ID。您可以（有时）完全删除提交，但您无法对其进行更改，只能将其中的大部分内容（除了当前更改的部分之外的所有内容）复制到新的不同内容之外 - ID提交。
Git，真的关心提交。它很难确保你永远不会失去一个。它更关心索引和工作树：它们既不是永久性的，也不是不变的。提交的优点是显而易见的，但它们的缺点也是显而易见的：它们存储在Git中 - 存储在存储库中 - 这种形式是计算机上没有其他任何东西可以处理的。
工作树与此相反：它以一种计算机上的所有其他形式可以处理的形式，并且它可以处理它。非常无常和多变的。这是你完成所有工作的地方。它有文件，而不是神秘的Git对象。这是您阅读，编写和编辑文件的地方。
Git的索引最初对大多数人来说是非常神秘的（这对我而言），并且它最终会遇到很多复杂的曲折。有些软件试图完全隐藏索引，但这并不是一个好主意。从某种意义上说，索引实际上非常简单：Git让你构建下一次提交。索引开始匹配当前提交，然后您git add现有文件的新版本或全新文件到索引，以复制新的。然后当您运行时git commit，Git现在在索引中提供了一个新的提交。这使得永久，不变的快照。索引（也称为临时区域）就是您安排（或者＃34; stage＆＃34;）文件的位置，以使它们尽可能地与快照相同。
每次提交还会记录其前任的ID或 parent ，commit。一旦开始使用历史记录，这就变得至关重要。历史由提交本身形成，通过这个＆＃34;我的父母是......＆＃34;信息。
分支名称master只是通过其ID识别该分支上的最新提交。 Git称之为分支的 tip 。这个最新的提交会记住它的父级，并且该父级会记住它自己的父级（最新提交的祖父母），依此类推。 Git还有其他实体做同样的事情：记住一个特定的提交ID。最重要的两个是标记和远程跟踪分支。
存储库包含提交，其中包含快照，它们构成了所有提交的历史记录。 分支名称 master在master上找到最新提交。而且，虽然提交包含文件，但它们本身并不是文件：它们包含整套文件，全部作为一个集合。
存储库有一个索引，它是内部Git提交表单和工作树形式之间的中介，大多数存储库都有一个工作树，可以让你进入提交状态。将文件作为文件。
git checkout做什么 git checkout命令主要将提交复制到索引和工作树中，以便您可以在所有提交的历史记录中移动并查看工作树中的相应快照。它还会调整Git调用HEAD的内容。
名称HEAD，在Git中，始终通过其ID引用当前提交，但它以两种不同的方式之一进行。您可以在分支上＃34;在这种情况下，名称HEAD只包含分支的名称。然后是分支名称，它将Git作为当前提交的ID。或者，您可以拥有一个＆＃34;分离的HEAD＆＃34;，在这种情况下，名称HEAD会记录当前提交的ID。
如果你给git checkout一个分支名称 - 例如git checkout master - 它会把你＆＃34;放在分支上＆＃34;它会检查提示提交，因为这样做了存储在分支名称中的ID，它将分支名称放在HEAD中。如果您为git checkout提供原始提交ID，标记名称或远程跟踪分支名称，它会找到相应的ID，检出该提交，并将ID放入HEAD。
git fetch - 和git push - 做什么以上所有步骤都完全适用于您自己的存储库。但是Git并不仅限于一个存储库。在你选择的明确定义的时间，你可以告诉你的Git通常通过互联网调用另一个Git，并与其他Git进行一些对话。
git fetch和git push都是这样做的。他们在某个URL的另一端调用了其他一些Git。 URL通常存储在名称下，称为远程。最常见的一个 - 通常是任何给定存储库中唯一的远程 - 是origin（因为git clone为您设置了一个）。
但请记住，Git主要关注提交。所以，当你的Git调用另一个Git时，他们的对话主要是关于提交。当然，它们确实需要一种方法来查找这些提交的ID，为此它们通常以一些分支名称开头。这通常是Git如何启动所有内容：获取分支名称，或者只是名称HEAD，并找到提交ID。使用该提交。然后，如果合适，请转到该提交的父级并使用 提交执行某些操作，依此类推。
fetch进程特别获取另一个Git中所有分支的列表。然后它获取那些在它自己的存储库中没有的那些分支中的所有提交。这些提交带有任何必要的快照文件，几乎都是一种副作用。最后，您的Git使用他们的Git的分支名称并重命名，将这些分支名称转换为您自己的远程跟踪分支名称。
如果遥控器名为origin，则他们的（来源）主人成为您的origin/master。除了你已经拥有的提交，你得到他们所有的提交。你已经拥有的，你已经拥有的。你的Git可以确定你拥有它们，因为你有ID。每个提交的ID对于该提交是唯一的，并且提交是永久性且不变的 - 因此，如果您具有相同的 ID，则两者必须具有相同的提交
你的Git和他们的Git非常相似地使用git push，但是在另一个方向，并且有一个转折：你的Git给你他们的承诺 - 你拥有的那些他们没有，即 - 然后要求他们设置他们的 master，或者你正在推动的任何分支，设置为提示提交，与你的提示相同的提交> master。此处没有重命名：您要求他们将master与master完全相同。
当您git fetch时，您的Git 会重命名他们的分支名称，因此将它们全部整理起来是安全的。无论他们对他们的分支做了什么，这个都不能影响你自己的分支名称。但是当你git push时，你让你的Git要求他们设置他们的分支名称，而根本没有重命名。如果他们不喜欢所要求的设置，他们可以说＆＃34;不，我不会设置＆＃34;他们可以拒绝您的推送。这对于抓取并不会发生，而这就是你的初始问题所在。
git pull = git fetch +其他获取只会让你获得新的提交。 因为 git fetch从不触及您自己的分支，您通常需要第二步。
这里的主要问题是正确的第二步取决于你带来了什么提交，以及你已经拥有的提交。有两个主要选项：git merge和git rebase。你可以对Git进行编程，让git pull做任何一个。默认为git merge。
再一次，＆＃34;对＆＃34;命令取决于您在分支中拥有的内容，获取时从远程获取的内容以及您希望如何工作。实际上，大多数人在这里主要想要git rebase，但git pull默认运行git merge。在许多情况下，两个命令最终会做同样的事情，因此默认情况下错误的命令并不重要。但我建议新手避免git pull，因为它确实默认为大多数人不想要的命令，并且因为当出现问题时 - 他们总是最终做到 - 从问题中恢复取决于您知道自己运行了git rebase或git merge。如果你真的直接使用它们，你就会知道。
答案 3 :(得分：0)
确保添加所有文件并提交。
git add . && git commit -m "<your_message>"
还要检查coc-setting.json中的任何设置