Git 分支管理常见三种方式
- TBD(Trunk-based development、单主干)
1、所有团队成员都在单个主干分支上进行开发。
2、发布时,先考虑使用标签 Tag, 如果打标签不能满足要求,则从主干创建发布分支。
3、 Bug在主干上修复,然后挑选时机发布到 发布分支上
- GitHub flow
GitHub使用的一种简单流程,使用两类分支,Master、代码修改分支,主要对应GitHub的pull、request功能。
1、master分支
包含稳定的代码,该分支已经或即将被部署到生产环境,分支的作用是提供一个稳定可靠的代码基础。任何开发人员都不允许把未测试或未审查的代码直接提交到 master 分支。
2、代码修改分支
当需要进行任何修改时(包括 bug 修复、hotfix、新功能开发等),总是从 master 分支创建新分支。
3、分支合并流程
当新分支中的代码全部完成之后,通过 GitHub 提交一个新的 pull request。团队中的其他人员会对代码进行审查,提出相关的修改意见。由持续集成服务器对新分支进行自动化测试。当代码通过自动化测试和代码审查之后,该分支的代码被合并到 master 分支。再从 master 分支部署到生产环境。
- git-flow
目前流传最广的 Git 分支管理实践,围绕的核心概念是版本发布(release)。git-flow 流程中包含 5 类分支,分别是 master、develop、feature、release 和 hotfix。
1.Master 分支中包含的是可以部署到生产环境中的代码,这一点和 GitHub flow 是相同的
2. develop 分支中包含的是下个版本需要发布的内容。当 develop 分支集成了足够的新功能和 bug 修复代码之后,通过一个发布流程来完成新版本的发布。发布完成之后,develop 分支的代码会被合并到 master 分支中。
3. feature、release和 hotfix为均为临时分支,只在需要时才从 develop 或 master 分支创建,在完成之后合并到 develop 或 master 分支。合并完成之后该分支被删除。
分支类型 | 命名规范 | 创建自 | 合并到 | 说明 |
---|---|---|---|---|
feature | feature/* | develop | develop | 新功能 |
release | release/* | develop | develop和master | 一次新版本的发布 |
hotfix | hotfix/* | master | develop和master | 生产环境中发现的紧急 bug 的修复 |
- 小结
- 如果发布周期较长,则 git-flow 是最好的选择。git-flow 可以很好地解决新功能开发、版本发布、生产系统维护等问题;
2.如果发布周期较短,则 TBD 和 GitHub flow 都是不错的选择
Git 分支创建、合并与删除
- 创建分支
git branch dev --------------创建dev分支
git checkout dev -----------切换到dev分支(或者: git switch dev)
git checkout -b dev -------创建并切换到dev分支(或者: git switch -c dev)
- 合并分支
git merge dev --------------合并dev分支到当前分支
- 删除分支
git branch -d dev -----------删除dev分支