git多分支管理

Git多分支管理

1. 分支命名规范：

   1. 主干分支master

   2. 开发分支dev

   3. 功能分支：feature/功能名（如feature/user-regist）

      修复分支：bugfix/问题编号（如bugfix/issue-456）

      发布分支：release/版本号（如release/v1.2.0）

      热修复分支：hotfix/紧急问题（如hotfix/login-error）

   Git 云仓库提价PR

   ​ 在此已gitee 为演示：

   

   ​

源分支表示我们开发代码的分支，目标分支表示将开发代码的分支要合并的分支

git issue 用于代码仓库记录问题

git tag git tag 本质是给代码仓库中的某个特定提交（commit）打上一个易记的 "标签"，可以把它理解为：

• 代码版本的 "里程碑"（比如发布 v1.0.0、v2.1.3 版本时打 tag）；
• 静态的 "快照"（tag 指向固定的 commit，不像分支可以继续提交代码，是只读的）；
• 版本追溯的 "锚点"（能快速定位到某个发布版本的代码，方便回滚、打包、排查问题）。

简单来说：分支用于 "动态开发"，tag 用于 "静态版本标记" 。比如你开发完 v1.0.0 版本并上线，给这个版本的最终 commit 打一个 v1.0.0 的 tag，后续无论分支怎么迭代，都能通过这个 tag 快速找回上线时的代码。

二、git tag 核心操作（实用版）

1. 查看已有的 tag

bash

运行

# 查看本地所有 tag（按创建时间排序）
git tag

# 查看指定匹配规则的 tag（比如只看 v1 开头的）
git tag -l "v1.*"

# 查看某个 tag 的详细信息（仅附注标签有效）
git show v1.0.0

2. 创建 tag（两种常用类型）

Git 有两种 tag，新手优先掌握附注标签（带说明，推荐），轻量标签仅作简单标记。

类型	特点	使用场景
附注标签	带作者、日期、备注，存储在 Git 数据库	正式发布版本（v1.0.0 等）
轻量标签	仅指向 commit 的引用，无额外信息	临时标记、内部测试版本

3. 推送 tag 到远程仓库

⚠️ 注意：创建的 tag 默认只保存在本地，需要手动推送到远程，否则团队成员看不到：

bash

运行

# 推送单个 tag 到远程
git push origin v1.0.0

# 推送本地所有未推送的 tag 到远程（批量推送）
git push origin --tags

通过tag 我们可以在代码仓库上去发布项目的版本

回退到历史提交版本（已 commit 未推送）

适用于：已经执行 git commit 但还没 git push，想回退到之前的某个提交（比如多提交了一次错误修改）。

步骤 1：找到目标提交的哈希值

bash

运行

# 查看提交日志，找到要回退的 commit 哈希（前7位即可）
git log --oneline
# 输出示例：
# a1b2c3d (HEAD -> main) 新增登录功能（错误提交）
# d4e5f6g 修复订单展示bug（目标回退版本）
# 9876543 (tag: v1.0.0) 发布v1.0.0版本

步骤 2：执行回退（3 种模式，优先用 --soft/--mixed）

回退模式	命令示例	效果（核心区别）
软回退（--soft）	git reset --soft d4e5f6g	保留工作区 + 暂存区修改，仅撤销提交
混合回退（--mixed）	git reset --mixed d4e5f6g	保留工作区修改，撤销暂存区 + 提交（默认模式）
硬回退（--hard）	git reset --hard d4e5f6g	工作区 + 暂存区 + 提交全部撤销，代码完全恢复到目标版本（无法恢复修改）

🔧 新手推荐：

• 想保留修改（只是撤销提交）：用 --soft；
• 想完全还原代码：确认修改无用后用 --hard。

---

场景 4：通过 Tag 回退到发布版本（最常用的生产回滚）

这是你之前关注的重点，整合简化版步骤（永久回退）：

bash

运行

# 1. 查看所有 Tag，找到目标版本（比如 v1.0.0）
git tag

# 2. 确保工作区干净（暂存未提交修改）
git stash

# 3. 切换到目标分支（比如 main），强制回退到 Tag 版本
git switch main
git reset --hard v1.0.0

# 4. 推送回退后的版本到远程（需强制推送，谨慎！）
git push -f origin main

# 5. （可选）恢复暂存的修改（若需要）
git stash pop

⚠️ 关键提醒：git push -f 会覆盖远程分支的提交历史，团队协作时必须提前沟通，避免他人代码丢失！

---

场景 5：回退已推送的远程版本（安全替代方案）

如果不想用 git push -f 覆盖远程历史（风险高），可通过「反向提交」回退（保留历史，更安全）：

bash

运行

# 1. 找到要回退的目标 commit 哈希（比如 d4e5f6g）
git log --oneline

# 2. 创建反向提交，抵消错误提交的修改
git revert d4e5f6g

# 3. 推送反向提交到远程（无需强制推送，安全）
git push origin main

✅ 效果：不会删除任何提交历史，而是新增一个 "撤销提交"，团队所有人拉取后即可同步回退状态，生产环境优先用这种方式！

---

误操作补救：恢复被回退的修改

如果不小心用 git reset --hard 删了重要修改，可通过 git reflog 恢复：

bash

运行

# 1. 查看所有 Git 操作日志（包括回退、提交、重置）
git reflog
# 输出示例：a1b2c3d HEAD@{0}: reset: moving to v1.0.0
#          d4e5f6g HEAD@{1}: commit: 新增登录功能（被回退的提交）

# 2. 恢复到被回退的提交
git reset --hard d4e5f6g

---

总结

1. 未提交修改：git checkout .（撤销工作区）/ git reset HEAD（撤销暂存）；
2. 已提交未推送：git reset --soft/--mixed/--hard 提交哈希（按需选择是否保留修改）；
3. 已推送 / 生产回滚：优先用 git revert（安全保留历史），确需覆盖用 git reset --hard + git push -f；
4. Tag 回退：git reset --hard + 强制推送（记得先 stash 备份）；
5. 误操作补救：git reflog 找到历史操作，用 git reset --hard 恢复。

核心原则：回退前先确认修改是否需要保留，生产环境避免用 --hard + 强制推送，优先用 git revert 保证历史可追溯。

如何通过 tag 回退到指定版本？

如何通过提交哈希回退到指定版本？

史），确需覆盖用 git reset --hard + git push -f；

4. Tag 回退：git reset --hard + 强制推送（记得先 stash 备份）；

5. 误操作补救：git reflog 找到历史操作，用 git reset --hard 恢复。

核心原则：回退前先确认修改是否需要保留，生产环境避免用 --hard + 强制推送，优先用 git revert 保证历史可追溯。

如何通过 tag 回退到指定版本？

如何通过提交哈希回退到指定版本？

如何在生产环境中安全地回退代码？