`Remote/Feature` 与 `remote feature` 有何不同？
How is `Remote/Feature` Different from `remote feature`?
将master合并到feature分支的时候，我一直都是
git merge origin master
它一直运行良好。但是，我从外围知道语法 origin/master 也存在，以指定您要使用哪个遥控器（我认为）。然而今天早上，我想要一个干净的 master 版本，所以我删除了我的本地副本，然后 fetched。现在，当我执行 git merge origin master 时，我会收到消息
Did you mean this?
origin/master
我需要正斜杠吗？为什么 git 现在需要这个？使用和不使用有什么区别？
这东西非常混乱。如果同时编写了足够多的命令，Git 在这里可能会更加一致。他们不是——这些不同的操作在几年的时间里被放在一起——并且向后兼容性限制了 Git 作者。
让我们定义一些术语：
A remote 是一个短名称，如 origin。这个简称的目的是 several-fold:
它存储了一个URL，这样你就不用一直输入了。 URL 可能是 https://github.com/user/project.git 或 ssh://git@github.com/user/project.git 或更长的东西，但第一个远程名称几乎总是 origin 并且只有六个字母，因此更容易输入。
它充当 remote-tracking 名称的前缀.
一个遥控器总是代表一些其他Git。另一个 Git 是一个完整的 Git 存储库（尽管它通常是一个 --bare 存储库，这意味着它没有工作树）。
A 分支名称 是类似 master 或 topic 或 feature/short 或其他名称的名称。分支名称有一些限制——例如，它们不能包含两个或更多相邻的点，因此 hello.world 可以，但 well...yes 不行。
A remote-tracking name 是类似于 origin/master 或 origin/topic 的名称。它由两部分组成：一个 远程名称 ，如 origin，和一个 分支名称，如另一个 Git[=162] =].
当你的 Git 通过像 origin 这样的远程名称调用另一个 Git 时，你的 Git 会 Git 列出所有 其分支名称。这些分支名称对应于其他 Git 存储库中的特定提交。如果您还没有，您的 Git 将从 Git 获得这些提交。然后，您的 Git 将通过创建或更新 您的 他们的 分支 名称来记住 remote-tracking 个名字。因此，如果他们的 master 代表提交 a123456，您的 origin/master 现在也将更新为保持 a123456。
一般来说，Git 可以将分支名称如 master 或 remote-tracking 名称如 origin/master 转换为提交哈希 ID。 运行:
git rev-parse master
例如， 将显示您的 Git 现在对您的 master 的哈希 ID。
当你 运行 git merge——这是一个早期的命令，甚至早于像 origin 这样的远程名称的存在——你需要给它的是名称一个或多个提交。所以 git merge origin/master 在这里就足够了，因为 origin/master 命名了一个特定的提交。 git merge topic 也足够了，如果你有一个名为 topic 的分支，因为你的分支名称 topic 命名了一个特定的提交。
如果您给 git merge 两个或多个提交的名称，Git 将（好吧，有时会）执行 Git 所谓的 octopus 合并。例如：
git merge topic1 topic2 topic3
执行合并，将三个主题分支与您当前的分支（可能 master）合并。
如果你运行宁:
git checkout master
git merge origin master
您一直在要求 Git 进行这些章鱼合并之一。您要合并的提交是 origin.
现在，origin 本身不是 remote-tracking 名称。但是试试 运行ning:
git rev-parse origin
以及：
git rev-parse origin/master
您几乎肯定会看到这两个命令都会生成相同的 提交哈希 ID。原因是名称 origin 本身，当在 Git 需要分支或 remote-tracking 名称的地方使用时，会扩展为 origin/HEAD。然后，origin/HEAD 也被扩展，通常是 origin/master。所以这意味着 git merge origin/master master.
与此同时，您 已经独自 master 所以 git merge master 无论如何都不会做任何事情。所以这个特殊的“章鱼”合并折叠成你的 master 和你的 origin/master 的常规合并，这是你的 Git 对其他 Git 的 master.
一般来说，您应该在这里使用 git merge origin/master，明确而不依赖于 origin/HEAD 映射到 origin/master。此外，您可能想利用另一个 Git 功能，称为分支名称的 upstream setting，这样您就可以 运行 git merge（根本没有任何额外的名字）。但它一直有效，因为这里的 origin 扩展到 origin/HEAD，这意味着 origin/master，你的章鱼合并请求最终变成了更普通的合并。
请注意 git pull 命令完全不同：它是为了方便起见。它首先 运行s git fetch，然后 运行s 第二个 Git 命令。默认的第二个 Git 命令是 git merge。当它执行 git fetch 步骤时，它需要一个 remote——一个像 origin 这样的名字。所以 git pull origin master 中的 origin 是 git fetch。然后，当它执行第二步时，它需要知道您想要的分支的名称 与在另一个 Git 上看到的一样。因此 git pull origin master 中的 master 表示 master，正如在 origin 中看到的那样，您的 Git 记得是 origin/master 对于非pull 命令如 git merge.
这就是所有这些混乱的来源：git pull 早于遥控器，你曾经做过 git pull <em>url</em>大师。这里很明显 url 部分是为了到达其他一些 Git，然后 master 意味着他们的 master。遥控器——如 origin——不存在，因此 remote-tracking 名称如 origin/master 也不存在。现在他们这样做了，我们有我们的情况。
将master合并到feature分支的时候，我一直都是
git merge origin master
它一直运行良好。但是，我从外围知道语法 origin/master 也存在，以指定您要使用哪个遥控器（我认为）。然而今天早上，我想要一个干净的 master 版本，所以我删除了我的本地副本，然后 fetched。现在，当我执行 git merge origin master 时，我会收到消息
Did you mean this? origin/master
我需要正斜杠吗？为什么 git 现在需要这个？使用和不使用有什么区别？
这东西非常混乱。如果同时编写了足够多的命令，Git 在这里可能会更加一致。他们不是——这些不同的操作在几年的时间里被放在一起——并且向后兼容性限制了 Git 作者。
让我们定义一些术语：
A remote 是一个短名称，如
origin。这个简称的目的是 several-fold:它存储了一个URL，这样你就不用一直输入了。 URL 可能是
https://github.com/user/project.git或ssh://git@github.com/user/project.git或更长的东西，但第一个远程名称几乎总是origin并且只有六个字母，因此更容易输入。它充当 remote-tracking 名称的前缀.
一个遥控器总是代表一些其他Git。另一个 Git 是一个完整的 Git 存储库（尽管它通常是一个--bare存储库，这意味着它没有工作树）。A 分支名称 是类似
master或topic或feature/short或其他名称的名称。分支名称有一些限制——例如，它们不能包含两个或更多相邻的点，因此hello.world可以，但well...yes不行。A remote-tracking name 是类似于
origin/master或origin/topic的名称。它由两部分组成：一个 远程名称 ，如origin，和一个 分支名称，如另一个 Git[=162] =].
当你的 Git 通过像 origin 这样的远程名称调用另一个 Git 时，你的 Git 会 Git 列出所有 其分支名称。这些分支名称对应于其他 Git 存储库中的特定提交。如果您还没有，您的 Git 将从 Git 获得这些提交。然后，您的 Git 将通过创建或更新 您的 他们的 分支 名称来记住 remote-tracking 个名字。因此，如果他们的 master 代表提交 a123456，您的 origin/master 现在也将更新为保持 a123456。
一般来说，Git 可以将分支名称如 master 或 remote-tracking 名称如 origin/master 转换为提交哈希 ID。 运行:
git rev-parse master
将显示您的 Git 现在对您的 master 的哈希 ID。
当你 运行 git merge——这是一个早期的命令，甚至早于像 origin 这样的远程名称的存在——你需要给它的是名称一个或多个提交。所以 git merge origin/master 在这里就足够了，因为 origin/master 命名了一个特定的提交。 git merge topic 也足够了，如果你有一个名为 topic 的分支，因为你的分支名称 topic 命名了一个特定的提交。
如果您给 git merge 两个或多个提交的名称，Git 将（好吧，有时会）执行 Git 所谓的 octopus 合并。例如：
git merge topic1 topic2 topic3
执行合并，将三个主题分支与您当前的分支（可能 master）合并。
如果你运行宁:
git checkout master
git merge origin master
您一直在要求 Git 进行这些章鱼合并之一。您要合并的提交是 origin.
现在，origin 本身不是 remote-tracking 名称。但是试试 运行ning:
git rev-parse origin
以及：
git rev-parse origin/master
您几乎肯定会看到这两个命令都会生成相同的 提交哈希 ID。原因是名称 origin 本身，当在 Git 需要分支或 remote-tracking 名称的地方使用时，会扩展为 origin/HEAD。然后，origin/HEAD 也被扩展，通常是 origin/master。所以这意味着 git merge origin/master master.
与此同时，您 已经独自 master 所以 git merge master 无论如何都不会做任何事情。所以这个特殊的“章鱼”合并折叠成你的 master 和你的 origin/master 的常规合并，这是你的 Git 对其他 Git 的 master.
一般来说，您应该在这里使用 git merge origin/master，明确而不依赖于 origin/HEAD 映射到 origin/master。此外，您可能想利用另一个 Git 功能，称为分支名称的 upstream setting，这样您就可以 运行 git merge（根本没有任何额外的名字）。但它一直有效，因为这里的 origin 扩展到 origin/HEAD，这意味着 origin/master，你的章鱼合并请求最终变成了更普通的合并。
请注意 git pull 命令完全不同：它是为了方便起见。它首先 运行s git fetch，然后 运行s 第二个 Git 命令。默认的第二个 Git 命令是 git merge。当它执行 git fetch 步骤时，它需要一个 remote——一个像 origin 这样的名字。所以 git pull origin master 中的 origin 是 git fetch。然后，当它执行第二步时，它需要知道您想要的分支的名称 与在另一个 Git 上看到的一样。因此 git pull origin master 中的 master 表示 master，正如在 origin 中看到的那样，您的 Git 记得是 origin/master 对于非pull 命令如 git merge.
这就是所有这些混乱的来源：git pull 早于遥控器，你曾经做过 git pull <em>url</em>大师。这里很明显 url 部分是为了到达其他一些 Git，然后 master 意味着他们的 master。遥控器——如 origin——不存在，因此 remote-tracking 名称如 origin/master 也不存在。现在他们这样做了，我们有我们的情况。