git从另一个分支分支分支

您好，我有两个并行的分支“dev”和“prod”，我想在本地开发分支中添加另一个本地分支，名为“issue22”（GitPro将其称为主题分支-其他人称之为功能分支）。因此，在终端，我用

git checkout -b issue22 dev

我认为这将“创建一个名为issue22的分支”，并从dev分支中的相同源代码开始。我期待着见到你

prod
dev
dev/issue22

但是当我发出命令时 吉特分行-a

相反，我明白了

prod
dev
issue22
remotes/origin/head -> origin/master
remotes/origin/dev
remotes/origin/prod

我应该使用什么命令来创建一个新分支，使“issue22”看起来像是一个与“dev”分支并行运行的主题/功能分支，并且看起来也源于dev分支

---

非常感谢

提交之间的父关系是存储库“结构”的基础。Git绝对可以实现这样的可视化。它是围绕Git设计的

下面是一个应该让您开始学习的示例：

首先，创建一个新存储库并添加一个空提交：

$ mkdir test-repo && cd test-repo
$ git init
$ git commit --allow-empty -m "Initial empty commit"

此时，您有一个分支和一个提交。您的网络将类似于

[master]  A

[master] [0.1]  A
                 \
[develop]         B---C---F---G---I
                       \         /
[issue22]               D---E---H

这里，

A

表示Git流站点右上角的蓝点

此提交缺少图表中的标记。让我们补充一下：

$ git tag -a 0.1

现在我们有了

[master] [0.1]  A

[master] [0.1]  A
                 \
[develop]         B---C

[master] [0.1]  A
                 \
[develop]         B---C
                       \
[issue22]               D

现在我们将创建

develope

分支：

$ git checkout -b develop

此时，我们尚未向

develop

添加任何不在

master

中的提交，因此分支指向完全相同的提交：

这里有点拥挤了。让我们为

develope

添加更多承诺：

$ # Hack, hack, hack...
$ git add somefile.txt otherfile.dat
$ git commit
$ # Hack, hack, hack...
$ git add foo.bar
$ git commit

现在我们的网络有点有趣了。当我们创建这两个新提交中的每一个时，我们的

develope

分支被更新为依次指向它们中的每一个。现在我们有了

[master] [0.1]  A

[master] [0.1]  A
                 \
[develop]         B---C

[master] [0.1]  A
                 \
[develop]         B---C
                       \
[issue22]               D

develope

此时实际上指向提交

C

，我们可以追溯

C

的祖先到提交

A

我们可以对一个新的分支机构

issue22

做同样的事情，尽管它不会被命名为

develope/issue22

，除非我们明确称之为：

$ git checkout -b issue22
$ # Hack, hack, hack...
$ git add foo.bar
$ git commit

现在我们有了

[master] [0.1]  A

[master] [0.1]  A
                 \
[develop]         B---C

[master] [0.1]  A
                 \
[develop]         B---C
                       \
[issue22]               D

issue22

由于

D

的母公司是

C

而从

develop

分支出来。我们可以在

develope

和

issue22

[master] [0.1]  A
                 \
[develop]         B---C---F---G
                       \
[issue22]               D---E---H

不改变这种关系。然后我们可以将

issue22

合并回

develope

（或者直接合并到

master

，尽管这不是“Git流方式”），并得到类似的结果

[master]  A

[master] [0.1]  A
                 \
[develop]         B---C---F---G---I
                       \         /
[issue22]               D---E---H

这个模型可以扩展到任意多个分支，只要稍加注意，就可以准确地重现Git流程图。分支在包含不同的提交之前不会“发散”

---

了解一点Git的内部工作可能会对您有所帮助。该网站是一个非常好的介绍。

您的术语非常混乱，请您编辑问题以显示确切的命令和输出，以及完全限定的分支机构名称和回购名称；因为您似乎在交替使用单词branch和repository，而事实并非如此。举个例子，您无法将分支添加到分支中。但是，您可以将分支添加到存储库中。请研究此网站-这是“当开始开发新功能时，从开发分支分支分支”的模型。据我所知，git的全部要点是分支分支。是的，git只看到“提交”——但我希望能够可视化并行运行的分支。我感谢您的意见，但我在问题中没有使用“存储库”这个词。我正在发布更多命令和输出…如果您使用分支可视化工具，如

gitk

或

git log--all--graph--decoration

，您应该会看到

issue22

和

dev

实际上位于同一位置。这是Git最接近“从另一个分支分支分支出来”的地方。然后，您可以在

issue22

中工作并提交到该分支。完成后，您可以合并到

dev

。谢谢@Chris-那么这是否意味着在使用git时不可能实现可视化？我这样问是因为我试图让我们的git分支看起来像这样（因为它读起来像一个分类层次结构）。相反，当我们创建“功能”和“热修复”分支时，没有层次结构。这就像你有一个目录C:\并且你必须把所有的文件夹（提交）都放在那里。我想要C:\Dev\fix1 C:\Prod\hotfix，而不是像C:\Prod C:\Dev C:\fix1这样的。谢谢。一个巧妙而透彻的回答。头脑冷静，知识渊博。你清楚地了解这一点，我很感谢你能与我沟通。非常感谢。