丰田车营销网站建设的纲要计划书,百度资源平台链接提交,传播易网站开发方案,赣州市九一人才网手机版目录
一、Git分支#xff08;Branch#xff09;
1.1 分支作用
1.2 四种分支管理策略
1.3 使用案例
1.3.1 指令
1.3.2 结合应用场景使用 二、Git标签#xff08;Tag#xff09;
2.1 标签作用
2.2 标签规范
2.3 使用案例
2.3.1 指令
2.3.2 使用示例 一、Git分支Branch
1.1 分支作用
1.2 四种分支管理策略
1.3 使用案例
1.3.1 指令
1.3.2 结合应用场景使用 二、Git标签Tag
2.1 标签作用
2.2 标签规范
2.3 使用案例
2.3.1 指令
2.3.2 使用示例 一、Git分支Branch 当我们谈论版本控制系统时分支是一个关键的概念。在 Git 中分支是用来处理不同代码线路的机制允许你在项目的不同部分之间工作而不影响主要代码线。 1.1 分支作用 分支是 Git 中用来处理项目中不同功能或特性的独立线路的工具。它允许你在不影响主要项目的同时进行开发、测试和实验。每个分支都是独立的修改一个分支不会影响其他分支。
应用场景
新功能开发 创建一个新的分支专注于新功能的开发而不会影响主分支通常是master。Bug 修复 如果在主分支上发现了 bug可以在一个新分支上进行修复而不会中断正在进行的开发。实验性开发 为了尝试一些实验性的想法可以创建一个分支在上面进行实验然后决定是否将其合并到主分支。 1.2 四种分支管理策略
在Git中分支有四个主要的环境通常被称为四种基本的分支管理策略
一、主分支Master/Main
作用 主分支通常是项目的主要分支包含了当前最稳定、可部署的代码。应用场景 当开发新功能或修复 bug 时通常从主分支创建新的分支进行工作。 二、开发分支Develop
作用 开发分支是用于集成各种功能的主分支。当一个开发周期结束时开发分支通常会合并到主分支形成一个稳定的版本。应用场景 在开发新功能时从主分支创建一个新的开发分支完成开发后再将其合并回开发分支。 三、特性分支Feature
作用 特性分支用于开发单个功能或特性。每个特性都有一个对应的特性分支使得功能的开发独立于主分支和其他特性。应用场景 当需要添加新功能时从开发分支创建一个新的特性分支完成开发后将其合并回开发分支。 四、发布分支Release
作用 发布分支用于准备发布新版本。在发布分支上进行最后的测试、文档更新和版本号增加等操作。应用场景 当开发周期结束时从开发分支创建一个新的发布分支准备发布。发布后将发布分支合并回主分支和开发分支。 这些环境提供了一种有效的方式来组织团队的工作流确保代码的稳定性和可维护性。使用这些环境可以清晰地了解每个分支的目的和状态从而更轻松地协作和集成代码。这种分支管理策略通常被称为Git Flow是一种在软件开发中广泛应用的工作流程。 1.3 使用案例
1.3.1 指令
# 查看本地分支
git branch # 创建新分支
git branch feature-branch# 切换到新分支
git checkout feature-branch# 或者一步到位创建切换
git checkout -b feature-branch# 合并分支到主分支
git checkout master
git merge feature-branch# 删除已合并的分支
git branch -d # 删除远程分支
git push origin --delete dev # 提交分支 如果远程没有这个分支他会自动创建这个分支
git push origin feature-branch
1.3.2 结合应用场景使用
主分支Master/Main 主分支是项目的默认分支通常包含了最新的稳定版本。在许多项目中主分支的名称是 master 或 main。 1、创建并切换分支你可以创建一个新的分支这个分支是从当前工作目录的状态创建的包含了当前工作目录中的所有文件和文件夹。 2、在分支上工作 在特定的分支上工作时你可以进行修改、添加新文件等操作。这些操作不会影响其他分支因为每个分支都有独立的工作目录。 测试新建的两个文件添加都暂存区再提交到本地仓库之后切换分支会是怎样的效果呢 切换到master之后原来添加的文件就消失了 3、提交分支 就可在gitee远程仓库中查看了 在此分支开发的代码与其他互不相干了若开发完成可与主分支进行合并 二、Git标签Tag
2.1 标签作用 标签是一个指向特定提交的引用通常用于标记版本发布。标签可以使你在不同版本之间轻松切换而不必记住各个提交的哈希值。
应用场景
版本发布 在发布一个稳定版本时可以为该提交打上标签以便将来可以轻松地找到和检出该版本。历史记录标记 在项目的关键点上打标签以便于回顾项目的历史记录。 2.2 标签规范
在 Git 中标签的命名规则相对灵活但有一些推荐的约定和最佳实践 版本号 最常见的标签是用于表示软件版本的。使用语义化版本号是一种常见的做法其中版本号包括主版本号、次版本号和修订号形式为 MAJOR.MINOR.PATCH。例如v1.0.0。 前缀 通常标签前面加上字母 v 作为版本的前缀是一种常见的做法。例如v2.1.3。 发布候选Release Candidate 有时在软件发布前可能有一些预发布版本可以使用 -rc 或其他类似的标记。例如v1.0.0-rc。 修订版或修复版本 有时可能需要对某个版本进行修复可以通过在版本号后添加修复版本号如 v1.0.1。 时间戳 在某些情况下可以使用时间戳作为标签特别是在需要唯一性的情况下。例如v20220101. 语义化标签 使用能够清晰表达标签目的的语义化标签。例如release-2.0, feature-new-login, 等。
注意事项
避免使用特殊字符空格或弱引用字符以免引起不必要的问题。标签名称对大小写敏感因此 v1.0 和 V1.0 是两个不同的标签。在使用标签时要保持一致性遵循项目内的约定。 总体而言标签的命名规则是由项目的团队来定义的。选择一种清晰、有意义、易于理解的命名约定对于项目的长期维护和协作是非常有帮助的。 2.3 使用案例
2.3.1 指令
# 列出所有标签
git tag# 添加标签
git tag v1.0.0# 附注标签 包含标签的名称、邮箱、日期和标签消息。它是一个更详细的标签类型。
git tag -a v1.0.0 -m Version 1.0.0# 删除标签
git tag -d v1.0.0# 删除远程标签已推送的标签
git push origin --delete v1.0.0# 推送标签
git push origin v1.0.0# 如果你有多个标签可以使用 --tags 选项一次性推送所有标签。
git push origin --tags 2.3.2 使用示例
这是一个简单的当前版本代码的标签推送 推送标签后其他团队成员可以通过拉取最新的标签来获取项目中的特定版本。例如
git pull origin v1.0.0.20231112_dev
这将获取远程仓库中的 v1.0 标签并将你的本地仓库切换到这个版本。
