Git
Git PR 使用 Squash and Merge 前，什么时候应该 Rebase？
先说结论
在 GitHub 中使用 Squash and Merge 合并 PR，并不意味着每个 PR 都必须先执行 rebase。
两者解决的问题不同：
rebase：把当前分支重新接到目标分支最新提交之后，必要时顺便整理提交顺序。Squash and Merge：合并 PR 时，把 PR 中的多个提交压缩成目标分支上的一个提交。
所以，是否需要 rebase，主要看分支是否落后、是否出现冲突、是否需要在合并前验证最新代码，而不是看 PR 里有多少个 commit。
一个常见的误区
很多人看到 PR 里有这样的提交记录：
feat: add login page
fix: adjust login style
fix: handle empty password
WIP
于是认为合并前必须执行：
其实，如果仓库最终使用 Squash and Merge，GitHub 会在合并时把这些提交压成一个提交。上面的提交历史虽然不够整齐，但通常不会污染 develop 或 main 分支。
为了整理提交信息而 rebase，属于可选操作；为了让 PR 基于最新目标分支并通过测试，才是更常见、更有实际价值的 rebase 场景。
什么时候应该在合并前 Rebase？
1. 目标分支已经有较多新提交
假设你的 PR 是从 develop 创建的：
数据库
数据库结构版本管理
为什么数据库也需要版本管理？
假设你开发新功能时，在本地执行了：
ALTER TABLE users ADD COLUMN nickname VARCHAR(100);
代码提交并部署到测试环境后，接口却报错：
column "nickname" does not exist
原因很简单：代码进入了 Git，修改数据库的 SQL 却只存在于你的电脑里。
如果数据库变更依靠聊天记录或人工执行，我们就很难回答：
- 哪些环境执行过这条 SQL？
- 新环境应该按什么顺序初始化？
- 测试库和生产库的结构是否一致？
- 三个月前为什么增加了这个字段？
解决办法是 DB Migration（数据库迁移）：把每次数据库结构变化写成带版本号的文件，提交到 Git，再由工具按顺序执行。
Migration 是怎样工作的？
可以把 Migration 理解成“数据库的 Git Commit”：
20260724100000 创建 users 表
20260724103000 增加 nickname 字段
20260724110000 创建邮箱索引
迁移工具会：
- 读取 Migration 目录；
- 查询数据库已经执行的版本；
- 按顺序执行尚未执行的文件；
- 记录成功执行的版本。
几个容易混淆的概念：
| 概念 | 用途 |
|---|
| Migration | 记录数据库如何一步步变化 |
| Schema 快照 | 展示数据库当前的完整结构 |
| 数据备份 | 在数据损坏或丢失后恢复 |
Migration 不能代替备份。执行 DROP COLUMN 后，Down Migration 也不一定能找回已经删除的数据。
ORM 自动建表也不完全等于版本管理。ORM 可以帮助生成 Migration，但共享环境最好执行已经生成、评审并提交到 Git 的确定性 SQL，而不是在应用启动时临时修改数据库。
Git
Git Worktree 实战指南：平行开发的秘密武器
前言
你是否经历过这样的场景？
当你正在为某个功能跑漫长的测试时，突然来了一个紧急的 bug 要修复，但你又不能随便动工作区的代码，因为测试还在进行。此时只能无奈地切换分支，导致 node_modules 需要重新安装，编译需要重新进行…
Git Worktree 就是来解决这个问题的。它允许你在同一个 Git 仓库中同时维护多个工作目录，每个目录可以检出不同的分支，彼此独立。
这篇文章将从理论到实战，深入讲解如何使用 Git Worktree 来优化你的开发流程。
什么是 Git Worktree？
基本概念
Git Worktree（工作树）是一个 Git 特性，允许你在同一个 Git 仓库中创建多个工作目录。
在没有 Worktree 之前：
- 一个仓库 = 一个工作目录
- 切换分支会改变当前工作目录的文件状态
- 如果当前工作目录有未提交的改动，切换分支可能很困难
有了 Worktree 之后：
- 一个仓库 = 多个独立的工作目录
- 每个工作目录可以检出不同的分支
- 多个目录可以同时进行开发，互不影响
工作树 vs 传统分支
常见误解： 工作树是对分支的替代
正确理解： 工作树是对分支的一种**“文件系统视图”**
- 分支：Git 中用来隔离开发路线的概念，存储在
.git/refs/heads/ 中 - 工作树：只是物理上创建了一个新的目录，让你能同时看到/编辑多个分支
分支的数量和数目都不会因为创建工作树而改变，工作树只是给了你一个新的"窗口"去访问这些分支。
为什么需要 Git Worktree？
常见应用场景
1️⃣ 场景：修复紧急 bug，不中断当前工作
你正在 feature/new-api 分支上开发新功能，代码还未提交。突然生产环境爆出一个 bug，需要立即修复。
传统做法：
# 代码还没 commit，必须先 stash
git stash
# 切回 main 分支
git checkout main
# 修复 bug，提交
git commit -m "fix: xxx"
# 切回开发分支
git checkout feature/new-api
# 恢复代码
git stash pop
问题：如果项目很大（如前端项目有巨大的 node_modules），即使只是切换分支也要重新安装依赖！