跳转到主要内容

首页留言板登录

Bithu咖啡馆

关于技术、代码和一切之间的事情。

页面

关于留言板标签

订阅

Next.jsReact前端架构性能优化Web 安全开源

© 2026 Bithu咖啡馆。保留所有权利。

Git 高级工作流实战：从 Rebase 到 Cherry-Pick 的进阶之路 — Bithu咖啡馆

目录

引言
一、Rebase vs Merge：两种整合策略的深度对比
Merge：保留完整历史的整合
Rebase：重写历史的线性整合
黄金法则与实战选择
交互式 Rebase：历史的编辑工具
对最近的 5 个提交进行交互式变基
可用的操作指令:
pick = 保留该提交
reword = 保留提交但修改提交信息
edit = 保留提交但暂停以便修改代码
squash = 将该提交合并到前一个提交中
fixup = 同 squash，但丢弃该提交的提交信息
drop = 删除该提交
二、Commit Message 规范化：Conventional Commits
Conventional Commits 规范
提交信息的结构化优势
使用 standard-version 根据 commit 历史自动生成版本日志
.github/workflows/deploy.yml
只有 feat 和 fix 提交触发部署，docs 提交则跳过
编写高质量提交信息的原则
好的提交信息
差的提交信息
三、Git Hooks：自动化质量守护
常用的 Git Hooks
使用 Husky 管理 Git Hooks（Next.js 项目）
只对暂存区的文件运行 lint，提高速度
只运行单元测试，集成测试太重不适合每次推送都跑
lint-staged 配置
自定义 Hook 实战：禁止提交调试代码
.husky/pre-commit 中的额外检查
检查暂存区中是否包含 console.log、debugger 等调试代码
四、Cherry-Pick：精准摘樱桃的艺术
基本用法
将指定的提交应用到当前分支
选择多个不连续的提交
选择一串连续的提交（左开右闭）
典型场景
如果在 main 上修复了一个安全漏洞（commit D），
需要将修复同步到仍在维护的旧版本分支：
你本该在 feature/auth 上提交，却不小心提交到了 main
先记录下那个提交的 hash
切换到正确的分支，把提交摘过来
回到 main，移除错误的提交
Cherry-Pick 冲突解决
如果出现冲突:
1. 手动解决冲突文件
2. 标记为已解决
3. 继续 cherry-pick（不要使用 git commit）
如果想放弃本次 cherry-pick
Cherry-Pick 的注意事项
五、复杂冲突的解决思路
冲突的底层机制
解决冲突的系统性方法
查看所有冲突文件
查看冲突的三方对比（base / ours / theirs）
使用可视化工具更直观
VS Code 内置了三方合并编辑器，强烈推荐
冲突是因为双方都在 Base 的基础上做了不同的修改
Git 不知道应该选 Ours 还是 Theirs
完全接受当前分支的版本
完全接受合并进来的分支的版本
手动合并（最常见）—— 在编辑器中处理 <<<<<<< 标记，保留需要的代码
减少冲突面的实践
冲突解决后的验证
冲突解决后，务必运行测试
立即运行测试套件
检查合并结果是否符合预期
六、高级技巧与常见陷阱
Git Reflog：你的后悔药
查看 HEAD 的移动历史
输出示例:
abc1234 HEAD@{0}: commit: feat: add login page
def5678 HEAD@{1}: rebase (finish): returning to refs/heads/main
ghi9012 HEAD@{2}: reset: moving to HEAD~3
恢复到误操作之前的状态
Git Bisect：二分法定位 Bug
开始二分查找
标记当前版本有问题
标记一个月前的版本没问题
Git 会自动切换到一个中间的提交
此时运行测试：
如果测试通过，标记为 good
如果测试失败，标记为 bad
重复以上步骤，直到 Git 定位到引入 bug 的提交
结束后退出 bisect 模式
如果有一个能判断 bug 是否存在的脚本
常见陷阱
危险操作
...但别的同事已经基于原来的提交开始了工作
七、推荐的分支策略
GitHub Flow（适合持续部署的团队）
Git Flow（适合有固定发布周期的团队）
结语

Git版本控制工作流DevOps团队协作

Git 高级工作流实战：从 Rebase 到 Cherry-Pick 的进阶之路

2026年7月6日0 次阅读约 25 分钟阅读