关于git管理分支问题

环境部署

git练习在线网站:Learn Git Branching

GithubDesktop官网(可视化管理工具):Download GitHub Desktop | GitHub Desktop

汉化工具

Git 版本控制设计指南

版本号命名规范

版本号采用 X.Y.Z 的格式，遵循语义化版本规范：

• X: 主版本号 - 做了不兼容的API修改
• Y: 次版本号 - 做了向下兼容的功能性新增
• Z: 修订号 - 做了向下兼容的问题修正

示例说明

v1.0.0  # 第一个正式版本发布
v1.1.0  # 新增功能，如添加了自动校准功能
v1.1.1  # 修复bug，如修复了某个测量误差
v1.1.2  # 修复其他bug，如解决了内存泄漏问题
v1.2.0  # 新增功能，如添加了新的检测算法
v2.0.0  # 重大更新，如界面重构或核心算法改变

举个例子：假设线宽仪软件从v1.1.0升级到v1.2.0，是因为新增了多点测量功能，这属于功能性更新，因此增加次版本号。

分支管理策略

采用 Git Flow 工作流模型：

主要分支

• main (主分支)

  • 存储正式发布的版本
  • 只能从release或hotfix分支合并
  • 每个合并都要打标签(tag)

• develop (开发分支)

  • 最新的开发版本
  • 功能开发的基础分支
  • 包含已测试的稳定功能

支持分支

• feature/xxx (功能分支)

  • 命名规范：feature/功能名称
  • 从develop分支创建
  • 完成后合并回develop
  • 示例：feature/auto-calibration（自动校准功能）

• hotfix/xxx (紧急修复分支)

  • 命名规范：hotfix/问题描述
  • 从main分支创建
  • 完成后同时合并到main和develop
  • 示例：hotfix/measure-crash（测量崩溃修复）

• release/x.y.z (发布分支)

  • 命名规范：release/版本号
  • 从develop分支创建
  • 只修复bug，不添加新功能
  • 完成后合并到main和develop
  • 示例：release/1.2.0

实际应用举例

假设在开发线宽仪软件：

1. 日常开发在develop分支进行
2. 要开发新的缺陷检测算法：
   • 创建feature/defect-detection分支
   • 在该分支上开发和测试
   • 完成后合并回develop
3. 线上版本出现崩溃：
   • 从main创建hotfix/crash-fix
   • 快速修复并测试
   • 合并回main和develop
4. 准备发布新版本：
   • 从develop创建release/1.2.0
   • 进行最后的测试和bug修复
   • 最终合并到main和develop

这样的分支管理可以让多人协作更有序，也便于追踪问题和版本控制。

Git 常用命令速查表

基础命令

分支操作

远程操作

撤销与修改

高级操作

配置相关

实际应用举例

比如在线宽仪项目中：

# 开发新功能
git checkout -b feature/auto-measure
git add .
git commit -m "添加自动测量功能"
git push origin feature/auto-measure

# 合并到开发分支
git checkout develop
git merge feature/auto-measure
git push origin develop

# 紧急修复bug
git checkout -b hotfix/measure-crash
git commit -m "修复测量崩溃问题"
git checkout main
git merge hotfix/measure-crash
git tag -a v1.0.1 -m "修复版本"

这些命令涵盖了日常开发中90%的使用场景。根据具体情况，可以组合使用这些命令完成各种版本控制任务。

VS上Git管理分支

重置（Reset）：

• 软重置（–soft）：重置到指定的提交记录，保留工作区和暂存区的更改，只是将 HEAD 移动到指定的提交点。
• 保留重置（–mixed）：重置到指定的提交点，保留工作区的更改，但会取消暂存区中的更改（即 unstaged）。
• 删除重置（–hard）：重置到指定的提交点，工作区和暂存区的更改都会丢失，回退到提交点的状态。

例子:

假设你有三个提交：A -> B -> C，现在你觉得提交 C 有问题，想要回到 B。

• 软重置（–soft）：你运行 git reset --soft B，这样 Git 会将 C 视为未提交的更改，保留这些更改在工作区和暂存区，但 HEAD 指向 B，你可以再修改或提交这些更改。
• 保留重置（–mixed）：你运行 git reset --mixed B，这样 C 的更改仍在工作区，但 Git 会将这些更改从暂存区中移除（取消暂存）。你可以决定是否保留或修改这些更改再提交。
• 删除重置（–hard）：你运行 git reset --hard B，这样会彻底删除 C 的所有更改，Git 仓库会回到 B 的状态，C 中的所有工作内容都会丢失。

还原（Revert）：

还原操作是创建一个新的提交，用于撤销某个提交的更改。这个操作不会删除原有的提交记录，而是生成一个反向的提交，使得最终的效果与指定提交前一致。

• 常用于需要保留历史记录，同时撤销错误修改的场景。

例子:

假设你做了提交 A -> B -> C，并发现 B 有问题，但 C 没问题。

• 你运行 git revert B，Git 会创建一个新的提交 D，这个提交 D 是 B 的反向提交，撤销了 B 的更改，但保留了 C。所以你的提交历史变为 A -> B -> C -> D，最终的代码效果等同于没有 B。

挑拣（Cherry-pick）：

挑拣操作允许你从一个分支或提交中选择特定的提交并应用到当前分支。这适用于想要部分引入其他分支中的修改，而不需要全部合并的情况。

例子:

假设你有两个分支，master 分支上有 A -> B -> C，feature 分支上有 X -> Y -> Z。你发现 feature 分支中的提交 Y 对 master 分支很有用，但不想合并整个 feature 分支。

• 你可以运行 git cherry-pick Y，这样 Y 的更改会被应用到 master 分支，新的提交历史看起来像 A -> B -> C -> Y，你只引入了 Y，而不是整个 feature 分支。

签出（Checkout）：

签出操作用于切换到某个分支或特定的历史提交。它让你在不同的分支之间自由切换，或者查看某个历史版本的代码。

• 签出分支：git checkout <branch_name>，切换到指定的分支，工作区将更新为该分支的最新提交，HEAD 将指向该分支，之后的修改和提交都会记录在该分支上。
• 签出提交：git checkout <commit_hash>，切换到某个历史提交，这会进入头部分离状态，允许你查看或修改该版本的代码，但新的提交不会关联到任何分支。

例子:

假设你在 main 分支上工作，并提交了 A -> B -> C，你想查看某个历史版本。

• 签出分支：如果你需要切换到 main 分支的最新提交，可以运行 git checkout main。你会回到 main 分支的最新提交，并处于正常的工作状态。

• 签出提交：如果你想查看 B 提交的状态，运行 git checkout <B的哈希值>，你将进入头部分离状态，能够查看 B 的代码，但此时不属于任何分支。如果你需要保存任何修改，可以创建一个新分支。

  git checkout -b <new_branch>
  

• 从头部分离状态返回正常状态：如果你处于头部分离状态，想回到分支，只需运行 git checkout <branch_name>，例如 git checkout main，你会回到正常的分支工作状态。

总结：

• 重置（Reset）：用于回到某个提交点，可以选择保留或丢弃更改。
• 还原（Revert）：通过创建一个新的反向提交来撤销特定提交的更改。
• 挑拣（Cherry-pick）：选择性地将其他分支的某个提交应用到当前分支。
• 签出（Checkout）：切换到不同的分支或特定的提交，查看或修改代码。