Question

我对GIT十分了解，所以我可能会误解了我学到的一些东西。

我在Visual Studio 2017中使用GIT，并将其同步到VSTS中的帐户。我之前已经签出了一个分支-进行了一些已提交，合并并与master同步的更改。

现在-当我尝试从master检出新的本地分支时-新分支的显示在master分支下方。然后我检出，提交，合并和同步的其他分支显示在master分支上方。

也许没关系？但是我找不到描述这种行为的任何地方。我看起来好像新的老兄变成了新的基地？

我的问题是：为什么新分支以前显示在母版上方时却显示在母版下方？ Visual studio branch view

Answer 1

答案在Sami Kuhmonen's comment中：

我认为列表是按字母顺序排序的，并且没有显示分支之间如何相互关联的任何信息。

但是，值得补充的是，这里还有一些重要的事情要知道： Git分支没有任何固有的关系。没有其他分支的父分支。

>

造成这种混淆的原因是 commits do 具有父/子关系，从某种意义上说，分支由commit组成。因此看来分支机构也应该拥有它们。问题在于，当我们在这里说分支时，我们指的是分支名称，例如master和develop。这些名称只是Git为我们提供的用户可更改名称，以跟踪一个提交。每个分支名称记住的一个提交称为分支的 tip ：

A  <-B  <-C   <--master

每个实际的提交都有一个丑陋的哈希ID作为其真实名称，而人类无法使用这些哈希ID，因此我们使用名称master来记住提交C的哈希ID。提交C记住其父B的哈希ID，B记住其父A的哈希ID。（{A是这个微小的三提交存储库中的第一次提交，因此它没有父级，并且操作在这里停止：因为它是第一次，这就是历史的终结，以Git的倒向方式。）< / p>

要进行新的提交，Git会用新的唯一哈希ID来写出新的提交（我们将其称为D），然后将 name master更新为存储D的哈希ID。 D本身包含C的哈希ID，因此Git可以从C中找到D：

A--B--C--D   <-- master

一旦提交，就永远不能更改它（根本—更改任何内容都会为您提供 new 提交，并带有新的唯一哈希ID，因此旧的提交未更改！）。我们知道内部箭头始终指向后方，因此无需绘制这些箭头。但是，当我们创建一个新分支 name 时，我们最终得到两个指向同一提交的名称：

A--B--C   <-- master, develop (HEAD)

现在，我们需要在分支名称上附加HEAD，以便我们知道我们在哪个分支上！如果我们现在进行提交D，则移动的分支名称为develop：

A--B--C   <-- master
       \
        D   <-- develop (HEAD)

但是我们可以随时使用git reset来移动分支名称。例如，如果我们毕竟不喜欢D，并且想让develop从B开始，我们可以git reset使其看起来像这样：< / p>

A--B   <-- develop (HEAD)
    \
     C   <-- master
      \
       D  [abandoned, will go away in about a month]

如果我们现在进行新的提交E，则E的父级将是B，可见部分将如下所示：

A--B--E   <-- develop (HEAD)
    \
     C   <-- master

（提交D无法找到它-用Git术语来说是无法访问，因此我们无法通过常规方式看到它。）

结论

请记住，每个分支 name 只是一个指针，指向一（1）个提交，如上图所示。 Git使用 commits 来找到他们的父母，沿着“名字指向的地方”的链条追溯到历史。但是您会发现，当人们谈论Git中的“分支”时，他们通常不是指名称，而是通过从名称开始并向后移动而实现的提交。您必须从上下文中确定某人是指“名称”还是“提交集合”。有关此的更多信息，请参见What exactly do we mean by "branch"?

新的GIT分支成为新的基础还是我缺少什么？

1 个答案:

结论