Git 分支：master vs. origin/master vs. remotes/origin/master答案

【问题标题】：Git branching: master vs. origin/master vs. remotes/origin/masterGit 分支：master vs. origin/master vs. remotes/origin/master
【发布时间】：2012-05-22 05:31:32
【问题描述】：

我认为我理解 git 的基本概念是正确的。

我已经设置并克隆了一个远程存储库。我还创建了一个服务器端空存储库，并将我的本地存储库链接到它。

我的问题是我不明白：

origin/master 与 remotes/origin/master

据我了解，master是本地分支，remotes/origin/master是远程分支。

但是origin/master到底是什么？

【问题讨论】：

@ChristopherWallace：您的编辑引发了关于元数据的两个问题：“Do we really need an [origin] tag?”和“What is the true [Master]?”。
@Deduplicator 有问题吗？
@ChristopherWallace：嗯，许多人似乎认为这两个标签（您创建的标签和您刚刚添加的标签）都很糟糕。我碰巧同意，但也许你有一些东西要添加到没有考虑的链接讨论中。如果不是，似乎是这样。
In Git, what is the difference between origin/master vs origin master?的可能重复
跟进问题：为什么.git/refs/origin/master 会偏离.git/refs/remotes/origin/master？这件事现在发生在我身上，我被甩了。

标签： git git-remote

【解决方案1】：

克隆一个远程存储库并运行git branch -a（以显示 git 知道的所有分支）。它可能看起来像这样：

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

这里，master 是本地存储库中的一个分支。 remotes/origin/master 是名为 master 的远程分支上名为 origin 的分支。您可以将其称为 origin/master，如下所示：

git diff origin/master..master

您也可以将其称为remotes/origin/master：

git diff remotes/origin/master..master

这些只是引用同一事物的两种不同方式（顺便提一下，这两个命令的意思是“显示远程master 分支和我的master 分支之间的变化）。

remotes/origin/HEAD 是名为origin 的遥控器的default branch。这让您可以简单地说 origin 而不是 origin/master。

【讨论】：

好答案。我认为git branch -a 将远程分支显示为remotes/origin/master 部分是因为底层引用存储在.git/refs/remotes/origin 中（如果尚未打包）。在我看来，git branch -a 的输出可能会更清晰，也许是通过使用斜杠以外的其他方式将远程名称与分支名称分开。
另请注意，git branch -r 仅显示远程分支，将仅显示分支为 origin/master，因为不需要 remotes/ 前缀。
@misterbiscuit：是的。输出比澄清更令人困惑。非常感谢，对我的问题的一个很好的回答，给了我正确的提示
如果我查看git log 我看到commit fa9sd8jasdf98 (HEAD -> master)，这是什么意思？在这种情况下，什么是 HEAD？我以为我目前是“大师”并致力于origin/master。我想我搞混了，有人可以帮助calrify吗？编辑更新：我想我明白了，假设 HEAD 当前指向 master 分支是否正确，这意味着我目前正在提交 master 分支？
但是，我对这个答案有点困惑。如果有人更改了远程 master 分支并且我们还没有获取它，那么 remotes/origin/master 是否与 origin/master 不同？

【解决方案2】：

像我这样的傻瓜的简短回答（从 Torek 偷来的）：

origin/master 是“我上次检查时主人在哪里”
master 是“根据我一直在做的事情，master 在哪里”

【讨论】：

origin/master = 远程机器的备份，上次检查时更新 master = 您的 origin/master 副本

【解决方案3】：

从技术上讲，您的 Git 存储库中实际上根本没有任何“远程”的东西¹，只有本地名称应该与另一个名称相对应，不同的回购。名为 origin/whatever 的那些最初将与您克隆的 repo 中的那些匹配：

git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...

制作另一个 repo 的本地副本。在此过程中，它会记录那里的所有分支，以及那些引用的提交，并将它们以 refs/remotes/origin/ 的名称粘贴到您的本地存储库中。

根据您在git fetch 之前的时间或相当于更新“我的what's some.where.out.there 的副本”，他们可能会改变他们的分支，创建新的分支，并删除一些。当您执行git fetch（或git pull，这实际上是获取加合并）时，您的回购将复制他们的新工作并根据需要更改所有refs/remotes/origin/<name> 条目。正是 fetching 的那一刻让一切都匹配（嗯，那个，以及最初的克隆，还有一些 pushing 的情况——基本上只要 Git 有机会检查——但请参阅下面的警告）。

Git 通常让您将自己的refs/heads/<name> 称为<name>，将远程的称为origin/<name>，这一切都可以正常工作，因为很明显哪个是哪个。有时可以创建自己的分支名称，使其不明显，但在它发生之前不要担心。 :-) 只需给 Git 一个使其显而易见的最短名称，它就会从那里开始：origin/master 是“我上次检查时主人在哪里”，master 是“主人在这里基于我一直在做什么”。运行 git fetch 以根据需要在“master 在哪里”更新 Git。

警告：在 1.8.4 之前的 Git 版本中，git fetch 有一些模式不会更新“master 在那边”（更准确地说，模式不会更新任何远程跟踪分支）。运行git fetch origin，或git fetch --all，甚至只是git fetch，确实更新。运行git fetch origin master 没有。不幸的是，这种“不更新”模式是由普通的git pull触发的。（这主要只是一个小烦恼，在 Git 1.8.4 及更高版本中已修复。）

¹嗯，有一件事被称为“远程”。但这也是本地的！ origin 这个名字是 Git 所说的“远程”。它基本上只是您在克隆时使用的 URL 的简称。这也是origin/master 中的origin 的来源。 origin/master 这个名字叫做remote-tracking branch，有时会缩写为“remote branch”，尤其是在较旧或更非正式的文档中。

【讨论】：

对于像我这样的新手来说，非常棒的描述，谢谢！澄清了她为什么将origin/master 贴纸放在local 回购的图表上，而不是放在remote 上（我全心全意地向git 的新人推荐杰西卡·克尔的“Git Happens”演示文稿：vimeo.com/46010208。我是在 30:00 - 30:19 之间挠头。）

【解决方案4】：

我会尽量让@ErichBSchulz 的答案对初学者来说更简单：

origin/master是远程仓库master分支的状态
master 是本地仓库中 master 分支的状态

【讨论】：

不错的尝试，但恕我直言，没有last time I've checked 它失去了重点

【解决方案5】：

origin - 这是一个自定义且最常见的名称，用于指向远程。

$ git remote add origin @987654321@ --- 您将运行此命令将您的 github 项目链接到源。这里的来源是用户定义的。 您可以将其重命名为$ git remote rename old-name new-name

master - Git 中的默认分支名称是 master。对于远程和本地计算机。

origin/master - 这只是一个指向远程仓库中的 master 分支的指针。记得我说过 origin 指向远程。

$ git fetch origin - 将对象和引用从远程存储库下载到本地计算机 [origin/master]。这意味着它不会影响您的本地 master 分支，除非您使用 $ git merge origin/master 合并它们。请记住在运行此命令之前检查需要合并的正确分支

注意：获取的内容表示为远程分支。 Fetch 让您有机会在将更改集成到项目副本之前查看更改。显示你和远程之间的变化$git diff master..origin/master

【讨论】：

【解决方案6】：

一个澄清（也是让我困惑的一点）：

“remotes/origin/HEAD 是默认分支”并不正确。

remotes/origin/master 是远程存储库中的默认分支（您上次检查时）。 HEAD 不是分支，它只是指向一个分支。

将 HEAD 视为您的工作区域。当您以这种方式考虑时，“git checkout branchname”对于将工作区文件更改为特定分支的文件是有意义的。您将分支文件“签出”到您的工作区域。出于所有实际目的，HEAD 是您在工作区域中可见的内容。

【讨论】：

更准确地说，HEAD 是“指向分支的指针”（例如，本地仓库中的实际文件通常包含字符串 ref: refs/heads/master……除非它是“分离的”，即完全是另一回事）。但是，clone 解释“远程 HEAD”的方式存在某种错误：传输协议根本无法发送间接分支，只能发送原始 SHA-1，因此 git 有一个“主要是工作”。不过，每隔一段时间，就会有人偶然发现一个奇怪的案例。我有点希望 git 根本没有创建 remotes/origin/HEAD，尤其是当它出现错误时......

【解决方案7】：

我认为查看 .git 文件夹可能最好理解这个 git 斜杠符号。

例如，这是我的 .git 的一个略为缩写的树，用于 LibreOffice 源代码库。

在 linux 中sudo apt-get install tree 对查看此内容很有用。
在 Windows 中，我认为tree 命令可能仍然有效。

向下滚动并查看底部附近的 refs（又名“引用”）：

$ tree  
.  
├── branches  
├── config  
├── description  
├── FETCH_HEAD  
├── gitk.cache  
├── HEAD  
├── hooks  
│   ├── applypatch-msg.sample  
    ...
├── index  
├── info  
│   └── exclude  
├── logs  
│   ├── HEAD  
│   └── refs  
│       ├── heads  
│       │   ├── master  
│       │   └── remotes  
│       │       └── origin  
│       └── remotes  
│           └── origin  
│               ├── distro  
│               │   ├── cib  
│               │   │   └── libreoffice-6-0  
│               │   ├── collabora  
│               │   │   └── cp-6.0  
│               │   └── lhm  
│               │       └── libreoffice-5-2+backports  
│               ├── HEAD  
│               ├── libreoffice-6-2  
│               ├── master  
│               └── private  
│                   └── mst  
│                       └── sw_redlinehide_4a  
├── objects  
│   ├── info  
│   └── pack  
│       ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.idx  
│       ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.pack  
│       ├── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.idx  
│       └── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.pack  
├── ORIG_HEAD  
├── packed-refs  
└── refs  
    ├── heads  
    │   ├── master  
    │   └── remotes  
    │       └── origin  
    ├── remotes  
    │   └── origin  
    │       ├── distro  
    │       │   ├── cib  
    │       │   │   └── libreoffice-6-0  
    │       │   ├── collabora  
    │       │   │   └── cp-6.0  
    │       │   └── lhm  
    │       │       └── libreoffice-5-2+backports  
    │       ├── HEAD  
    │       ├── libreoffice-6-2  
    │       ├── master  
    │       └── private  
    │           └── mst  
    │               └── sw_redlinehide_4a  
    └── tags  
        └── libreoffice-6-2-branch-point  

32 directories, 45 files

如果这样布置可能不会那么混乱，但事实并非如此：

repositories (i.e. independent trees)
├──local
│  └──master
│
└──origin1
│  └──master
└──origin2
   └──master

我们有三种基本类型的参考：heads、remotes和tags。

.git/refs/heads 持有我们本地的master。
.git/refs/remotes 可以容纳多个遥控器，虽然目前我们只有 origin。
李>
.git/refs/tags（在别处讨论）。

origin 因此，是我们唯一的远程。它拥有origin/master。

我们发现我们有 2 个HEADS（指向当前分支的指针）、一个本地和一个远程：

$ cat .git/HEAD                        #         local:  HEAD -> master
ref: refs/heads/master

$ cat .git/refs/remotes/origin/HEAD    # remote origin:  HEAD -> master
ref: refs/remotes/origin/master

如果您列出您的分支机构：

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/aoo/aw080
  remotes/origin/aoo/trunk
  remotes/origin/distro/capgemini/cg-4.1
  remotes/origin/distro/cib/libreoffice-5-0
  remotes/origin/distro/cib/libreoffice-5-1
  remotes/origin/distro/cib/libreoffice-5-2
  ...

列出的第一个分支 (master) 是唯一一个不是远程的。所以在这种情况下，我们有一个本地分支。我们将从这里开始我们自己的工作，为我们自己的新分支和后续提交。

接下来，您可能有许多远程跟踪分支，我们在这里做。您知道这些是远程跟踪分支，因为它们以“remotes/”为前缀。此处显示的用于远程命名的原点。

所以第二行是原点的当前分支指针。遥控器/来源：HEAD --指向--> master。这表明在远程存储库中，当前分支是他们名为master的分支，（不要与我们名为master的本地分支混淆）。
李>
在您的 .git/refs/ 树中找不到剩余的分支，但您可以在 .git/packed-refs 中找到它们。

当我们 git fetch 时，我们会将更改从远程存储库下载到我们的远程跟踪存储库中。

当我们 git merge 时，我们会将这个本地远程跟踪存储库中的更改合并到我们工作的本地分支或分支中，在这种情况下合并到我们的主分支中。

（当我们 git pull 我们在一个操作中完成这两个步骤。）

还值得注意的是，master 的这些 local 和 remote UUID 当前指向同一个节点（又名“提交”）：

$ cat refs/heads/master                   # local         master
1ca409292272632f443733450313de5a82c54a9c

$ cat refs/remotes/origin/master          # remote origin master
1ca409292272632f443733450313de5a82c54a9c

所以我们的本地master和远程的origin master指向同一个地方：

[local] master = [remote] origin master

最后，我觉得看看.git/packed-refs也很有用

$ cat packed-refs 
# pack-refs with: peeled fully-peeled 
3c1d4742e649fe9c8aed8c2817fe3e1f3364f298 refs/remotes/origin/aoo/aw080
e87c8b7922e9a73e0abb7f9a7a47c9ac3374a826 refs/remotes/origin/aoo/trunk
b70fdffb041c12f124dcc0822b61bf3450e53137 refs/remotes/origin/distro/capgemini/cg-4.1
5dbc3f1754809b9489faaf380b1a4bdbcfbb6205 refs/remotes/origin/distro/cib/libreoffice-5-0
cfdbc96ca47d68d6785fd21829a8d61f49d6e591 refs/remotes/origin/distro/cib/libreoffice-5-1
5189c8c47461ef09739086e55512fc6a10245273 refs/remotes/origin/distro/cib/libreoffice-5-2
3bee5917569ca8e6ee3b086458f5b1a917b88ca1 refs/remotes/origin/distro/cib/libreoffice-5-3
92fbe703f9ca480d3a2b8610d87e991c729edf77 refs/remotes/origin/distro/cib/libreoffice-5-4
05c0a5df66cc69d75280f05b804cf82f3387d42b refs/remotes/origin/distro/cib/libreoffice-6-0
7fe193e759b24b90852e6e327115b77114d7b119 refs/remotes/origin/distro/cib/libreoffice-6-1
8187f7aa413e7ef7b377eea2b057d336bf256867 refs/remotes/origin/distro/collabora/cd-5.3
7a6b608591e21ef61dc05cff9fc58da531035755 refs/remotes/origin/distro/collabora/cd-5.3-3.1
....

毫无疑问，这留下的问题多于答案，但我认为它可以开始帮助您回答自己关于什么是什么的问题。

【讨论】：