git分支重命名是否会影响分支层次结构？

我正在从事一个由GIT管理的多分支项目

我们目前的工作流程是：

master
 |-> v1/master
     |-> v1/dev

注意：每个开发人员使用v1/dev的“fork”来实现任务。我们可能有从v1/dev继承的分支数

我们需要添加从v1/master继承的名为v1/debug的分支。 当前的v1/dev分支必须继承v1/debug

我们针对这一新的工作流程：

master
 |-> v1/master
     |-> v1/debug
         |-> v1/dev

注意：每个人都必须继续制作v1/dev的“fork”，以实现单元任务

---

我正在寻找添加中间分支v1/debug的解决方案

经过一些研究，我将使用git rename branch命令（）

此命令是否保留分支层次结构

我是否可以将v1/dev重命名为v1/debug，然后将新的v1/dev分支去掉，从而在当前v1/dev分支的当前开发分支结果中制造麻烦

---

开发人员能否在v1/debug中合并重命名的v1/dev的单元分支结果？

首先，不要重命名分支。您可以重命名本地分支，但这仅适用于您。记住git是一个分布式系统。人们有权使用与相关远程跟踪分支不同的名称命名其本地分支

例如，

v2/debug

可能是跟踪远程跟踪分支的本地分支的名称

origin/v1/master

（我知道，这没有意义，但因为git是一个分布式系统，人们可以在本地命名他们想要的东西

也不要远程重命名分支。这会搞乱一切，因为它不会更改同事的本地存储库。他们的本地分支将继续指向相同的远程跟踪分支（相同的名称）

您只需创建一个新分支，并使其在当前的

v1/master

点开始。 要创建并直接切换到它，请执行以下操作：

git checkout -b v1/debug v1/master

或仅创建它，但仍保留在当前分支上：

git branch v1/debug v1/master

分支是在本地创建的，仍然需要推送其他人才能看到它

以后，您只需更改合并工作流。从现在起，停止将

v1/dev

直接合并到

v1/master

，然后只将其合并到

v1/debug

。 并在代码库准备就绪时将

v1/debug

合并到

v1/master

你说的是分支层次结构。实际上，分支层次结构对git来说是“未知的”。这只是你合并（哪个分支到哪个分支）的方式，最终形成了层次结构

带有图片的工作流示例

初始状态（仅

v1/master

和

v1/dev

）。这里，假设

v1/dev

在

v1/master

之前提交1次。还假设我们当前在分支

v1/master

上。

运行

git branch v1/debug v1/master

。这只会创建指向当前由

v1/master

指向的同一提交的标签

分支

v1/dev

准备就绪后，将其合并到

v1/debug

中。运行

git checkout v1/debug&&git merge v1/dev

分支

v1/debug

准备就绪后，将其合并到

v1/master

中。运行

git checkout v1/master&&git merge v1/debug

。 从现在起，您所谓的“层次结构”开始清晰地出现。

在分支

v1/dev

上做一些工作。运行

git checkout v1/dev

并进行几次提交。

将其合并到

v1/debug

。运行

git checkout v1/debug&&git Merge v1/dev

将其合并到

v1/master

。运行

git checkout v1/master&&git Merge v1/debug

现在你有了3个清晰的分支和想要的工作流

---

请注意，只有当您使用

git merge--no ff

时，图形才会像这样。它使图片中的内容更清晰，因此我假设合并是非快进的，因此我们总是可以看到发生了什么，即使这些合并提交实际上是无用的。

请注意：git中的分支只是开发st的标签你也可以将

v1/master

重命名为

foo

，

v1/debug

重命名为

bar

，将

v1/dev

重命名为

你想要的任何东西，

什么都不会改变…我在下面编辑了我的答案，添加了一个工作流示例的图片，允许你创建这个«中间分支». :)