Git 分支的约束和管理
此内容尚不支持你的语言。
来源:dxyoo7
一、分支说明
- main
- 主分支,用作生产分支,里面的代码是准备部署到生产环境的。 main 永远处于稳定状态,这个分支代码可以随时用来部署。
- main 不提交代码,只合并代码。
- 合并代码到 main 的操作,由项目对应的集成管理员专人负责。
- 各分支要定期将 main 代码合并进来,避免后续分支合并到 main 时容易产生冲突,以减轻集成管理员的合并负担。
- 发版之前,要打 tag 。
- develop
- 从哪个分支分离开来: main
- 可以合并到哪个分支上:release
Develop(开发)分支,包含了项目最新的功能和代码,所有开发都在 develop 上进行。一般情况下小的修改直接在这个分支上提交代码。
- release
- 从哪个分支分离开来:develop
- 必须要合并到哪个分支上:develop 与 main
- 分支的命名规范:release-*
Release (发行)分支,是为发行正式的生产版本做准备。当开发的差不多了,准备发行就可以创建一个发行分支,在这个分支上可以做一些小的 bug 修复,准备发行的元数据,比如版本号,发行日期之类的。这时候,develop 分支可以继续接收新的提交,为下一个发行做准备。
- feat
- 从哪个分支分离开来:develop
- 必须要合并到哪个分支上:develop
- 分支的命名规范:除了 main ,develop,release-,或者 hotfix- 以外的名字都可以
Feature(功能) 分支,有时候也叫 Topic 分支。在这种分支上去开发新的功能。当开发功能的时候,这个功能属于哪个目标发行还不知道。功能如果一直在开发,对应的这个功能分支就可以一直存在,不过到最后还是要合并到 develop 分支上,或者如果不想要开发的这个功能了,可以直接扔掉它。 Feature 分支一般只在开发者的 repo 里,而不是在 origin 上。
- hotfix
- 从哪个分支分离开来: main
- 必须要合并到哪个分支上:develop 与 main
- 分支的命名规范:hotfix-*
当在生产版本上遇到 bug,你需要立即修复的时候,可以创建一个 Hotfix 分支,这个分支可以基于生产环境使用的对应的在 main 分支上的 tag 来创建。
- fix/bugfix
- 从哪个分支分离开来: main
- 必须要合并到哪个分支上:develop 与 main
- 分支的命名规范:hotfix-*
等同于hotfix,只是紧急性没有hotfix那么急迫。
如下图所示:
二、分支开发
新版本开始:每个人从最新develop上checkout一个本地分支做开发; 本阶段:禁止直接在develop上开发; 如预期需要协助,可以几个人协同一个远端分支开发;一般会在远端创建version-develop分支
- 开发周期:一个版本的迭代周期,我们分成3个里程碑(v1, v2, v3);
- v1版本:开发完成,会merge各自分支到develop;此时develop才进入下一个开发周期; 同时发布v1包给测试; v1的Bug,大家可以选择在develop上直接修改,或者继续在各自的本地分支上修改;
- v2、v3版本:建议还是在各自的本地分支上继续开发; 完成feature后,同样merge回develop;
三、分支操作参考
- main
- develop
- release
- feature
- hotfix
从 main 切出hotfix分支
git checkout main git pull origin main —rebase git checkout -b hotfix
main 合并分支hotfix
git checkout main git pull origin main —rebase git merge —no-ff hotfix git tag V1.1 git push origin main
develop合并分支hotfix
git checkout develop git pull origin develop —rebase git merge —no-ff hotfix git push origin develop
- bugfix
同 hotfix,但不一定是从 main 分支切出.