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 /调试。
经过一番研究,我会使用git rename branch命令(我如何重命名本地Git分支?)。
这个命令是否保留分支层次?
我可以将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
。
你在谈论分支层次结构 。 实际上,分支层次结构是“未知”的。 它只是你合并的方式(哪一个分支进入哪一个分支),最终形成层次结构。
带图片的工作流示例
初始状态(仅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
,图形只会看起来像这样。 它使事情变得更加清晰,所以我认为合并不是快进 ,所以我们总是看到发生了什么,即使这些合并提交实际上是无用的。