Git版本控制系统之分支与标签（版本）

目录

一、Git分支（Branch）

[1.1 分支作用](#1.1 分支作用)

[1.2 四种分支管理策略](#1.2 四种分支管理策略)

[1.3 使用案例](#1.3 使用案例)

[1.3.1 指令](#1.3.1 指令)

[1.3.2 结合应用场景使用](#1.3.2 结合应用场景使用)

二、Git标签（Tag）

[2.1 标签作用](#2.1 标签作用)

[2.2 标签规范](#2.2 标签规范)

[2.3 使用案例](#2.3 使用案例)

[2.3.1 指令](#2.3.1 指令)

[2.3.2 使用示例](#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 中，标签的命名规则相对灵活，但有一些推荐的约定和最佳实践：

1. 版本号： 最常见的标签是用于表示软件版本的。使用语义化版本号是一种常见的做法，其中版本号包括主版本号、次版本号和修订号，形式为 MAJOR.MINOR.PATCH。例如：v1.0.0。

2. 前缀： 通常，标签前面加上字母 'v' 作为版本的前缀是一种常见的做法。例如：v2.1.3。

3. 发布候选（Release Candidate）： 有时在软件发布前可能有一些预发布版本，可以使用 -rc 或其他类似的标记。例如：v1.0.0-rc。

4. 修订版或修复版本： 有时可能需要对某个版本进行修复，可以通过在版本号后添加修复版本号，如 v1.0.1。

5. 时间戳： 在某些情况下，可以使用时间戳作为标签，特别是在需要唯一性的情况下。例如：v20220101.

6. 语义化标签： 使用能够清晰表达标签目的的语义化标签。例如：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 标签，并将你的本地仓库切换到这个版本。