Git版本控制系统之分支与标签（版本）-编程知识

一、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