问题：
我使用这些命令创建了两个新的分支。新分支GTEC-426-eth应该源自feature/eth_testing，而新分支GTEC-426-ksz应该源自feature/KSZ8851SNL_testing。
git worktree add -b GTEC-426-eth ../worktrees/GTEC-426-eth feature/eth_testing
git worktree add -b GTEC-426-ksz ../worktrees/GTEC-426-ksz feature/KSZ8851SNL_testing这些新的分支在完成更改后，会被推送到原点。
git push --set-upstream origin GTEC-426-eth
git push --set-upstream origin GTEC-426-ksz现在我正在检查Gitlab图，似乎这并没有添加新的分支，但重命名现有的分支......
这是从GTEC-426-ksz分支运行tig GIT客户端的图：
这是Gitlab上的GTEC-426-ksz分支图：
我做错了什么？
可能原因：
我在man git worktree中读到关于-b的内容：
-b <new-branch>, -B <new-branch>
With add, create a new branch named <new-branch> starting at <commit-ish>, and check out <new-branch> into the new working tree. If <commit-ish> is omitted, it defaults to HEAD. By default, -b refuses to create a new
branch if it already exists. -B overrides this safeguard, resetting <new-branch> to <commit-ish>.我正在使用Windows/WSL，我怀疑因为Windows在正常/大写字母方面有问题，它可能会将-b解释为-B...我不知道为什么会发生这种事...
1条答案
按热度按时间jtoj6r0c1#
我现在明白了所有git图尽可能使用横向节省空间。
让我们来看看之前GitLab中的Graph：
在这里，它看起来真的像分支
feature/eth_testing被重命名为GTEC-426-eth，但事实并非如此。分支feature/eth_testing和GTEC-426-eth实际上是两个不同的分支！所以像我这样的正常人会期望图的这一部分看起来像这样：这看起来更好，但看看它需要多少水平空间！这就是为什么为了保存水平空间，git在一条线上绘制一个图表，并标记每个分支的结束，如第一个图像所示。它将继续这样做，直到它可以-直到分支
feature/eth_testing上有另一个提交。当这种情况发生时，它将被迫移动GTEC-426-eth分支，并绘制一个像这样的图形：我通过在
feature/eth_testing上创建额外的commit来测试这一点，graph的行为确实像刚才描述的那样：**注意：**我还必须使用
tig --all而不是简单的tig来查看所有分支。