Git

标题 Git Worktree 使用教程：同仓库并行开发多个分支 副标题 / 摘要 git worktree 让你在同一个 Git 仓库下，同时打开多个分支对应的工作目录，不用来回 checkout 和 stash。 本文覆盖常用命令、典型场景、常见坑，以及你最关心的 hotfix 分支创建方式（先进入 worktree 再建分支 / 一步建分支）。 目标读者 正在同时处理多个需求分支（feature / bugfix / hotfix）的开发者 经常需要切到 main 修紧急问题，但不想污染当前工作目录的人 需要对比不同分支代码、并行运行不同版本服务的工程师 背景 / 动机 很多人第一次遇到并行任务时，会用这套流程： git stash git checkout main # 修 bug git checkout feature/xxx git stash pop 这套流程不是不能用，但有几个问题： stash 容易忘记清理或弹错时机 来回切分支容易打断当前开发节奏 长时间运行测试/构建会占住当前工作目录 对比两个分支代码时不够直观 git worktree 的价值就是：在一个仓库里同时拥有多个工作目录，各做各的事，互不干扰。 核心概念 worktree（工作树）：同一仓库的一个额外工作目录 共享对象库：多个 worktree 共享同一套 Git 对象数据（不是多个独立 clone） 独立工作目录：每个 worktree 有自己的文件内容、当前分支、未提交修改 分支占用限制：同一分支不能同时被多个 worktree 检出（Git 会保护你） stash 是仓库级别：不是 worktree 级别，多个 worktree 共享同一个 stash 列表 结构示意（ASCII）： ...

副标题 / 摘要 Git 和 Mercurial 的合并之所以更顺畅，关键在于它们记录了提交图和父子关系。本文解释背后的模型差异。 目标读者 从 SVN/CVS 迁移到 Git 的团队 需要理解合并机制的工程师 关注协作效率的技术负责人 背景 / 动机 合并冲突是协作成本的重要来源。 不同版本控制系统的模型决定了合并难度。 核心概念 提交图（DAG）：记录提交之间关系 三方合并：基于共同祖先合并 分布式模型：每个节点都有完整历史 实践指南 / 步骤 理解 Git 的提交图结构 用短分支降低冲突范围 保持频繁合并或变基 在合并前跑测试 可运行示例 # 查看提交图 git log --graph --oneline --decorate 解释与原理 Git/Mercurial 记录完整提交图，可以精确找到共同祖先。 SVN/CVS 以目录为中心，合并信息不足导致冲突更难处理。 常见问题与注意事项 Git 合并就不会冲突吗？ 仍会冲突，但通常更容易定位与解决。 为什么三方合并重要？ 能识别共同祖先的差异，减少误合并。 如何减少合并成本？ 保持分支短小并频繁同步。 最佳实践与建议 采用短生命周期分支 频繁同步主干 合并后立即运行测试 小结 / 结论 分布式版本控制系统通过提交图让合并更精准。 理解底层模型能减少协作摩擦。 参考与延伸阅读 Pro Git Mercurial Concepts 元信息 阅读时长：6~8 分钟 标签：合并、Git、SVN SEO 关键词：Git 合并, SVN 合并 元描述：解释 Git/Mercurial 合并更容易的原因。 行动号召（CTA） 用 git log --graph 观察你项目的提交图，理解一次合并的祖先节点。

副标题 / 摘要 Git 分支“轻量”是它改变开发流程的关键。本文解释 Git 与 SVN 分支机制差异及其工程意义。 目标读者 需要理解版本控制差异的开发者 正在从 SVN 迁移到 Git 的团队 关注协作流程的技术负责人 背景 / 动机 分支成本直接影响团队协作方式。 理解机制差异能解释为什么 Git 工作流更灵活。 核心概念 Git 分支：指向提交的轻量指针 SVN 分支：基于目录拷贝的分支 合并成本：决定协作效率 实践指南 / 步骤 在 Git 中将分支作为日常操作 将功能开发放在短生命周期分支 用 PR 或 Merge Request 完成评审 建立清晰的分支命名规范 可运行示例 # Git 分支非常轻量 mkdir demo && cd demo git init git commit --allow-empty -m "init" git branch feature/login git switch feature/login 解释与原理 Git 分支是“指针”，创建成本极低。 SVN 分支是“目录复制”，创建和管理成本更高。 ...

副标题 / 摘要 GitFlow 强调多分支与发布管理，GitHub Flow 强调持续集成与快速迭代。本文对比二者并给出选型建议。 目标读者 负责团队协作流程的技术负责人 需要选择 Git 工作流的团队 希望提升发布效率的工程师 背景 / 动机 工作流决定协作效率。 选错工作流会导致发布迟缓、分支混乱与冲突高发。 核心概念 GitFlow：feature/develop/release/hotfix 多分支模型 GitHub Flow：短分支 + PR + main 始终可部署 CI/CD：自动化测试与交付 实践指南 / 步骤 评估发布频率：频繁发布更适合 GitHub Flow 评估团队规模：大型团队可能偏 GitFlow 统一分支命名与合并规范 强制 CI 通过再合并 设定回滚与热修策略 可运行示例 # GitHub Flow 的典型流程 git checkout -b feature/payment # 开发并提交 git push origin feature/payment # 提 PR -> CI 通过 -> 合并到 main 解释与原理 GitFlow 适合发布周期长、需要严格版本管理的场景。 GitHub Flow 适合快速迭代、持续交付的场景。 ...

副标题 / 摘要 分布式版本控制把“历史”分散到每个开发者本地，带来更强的离线能力与分支灵活性，但也引入更高的协作复杂度。本文给出清晰对比。 目标读者 需要理解 Git / SVN 差异的工程师 负责制定团队工作流的技术负责人 正在从 SVN 迁移到 Git 的团队 背景 / 动机 版本控制不是工具问题，而是协作效率问题。 分布式与集中式的差异会直接影响团队工作流、代码评审与发布节奏。 核心概念 集中式 VCS：单一中央仓库（SVN） 分布式 VCS：每个开发者都有完整历史（Git） 分支模型：分支的创建、合并成本不同 实践指南 / 步骤 评估团队规模与协作模式 看是否需要离线工作 评估分支与合并频率 选择合适的工作流（GitFlow/GitHubFlow） 建立统一的代码评审与发布规范 可运行示例 比较 SVN 与 Git 的本地历史能力： # Git：离线查看历史 git log -5 # SVN：依赖服务器 svn log -l 5 解释与原理 分布式 VCS 把历史复制到本地，允许开发者离线查看与提交。 集中式 VCS 依赖中心仓库，操作更集中、权限更清晰，但分支成本高。 常见问题与注意事项 分布式 VCS 是否更安全？ 历史分散降低单点风险，但也需要更强的权限策略。 集中式 VCS 是否更简单？ 对小团队可能更简单，但扩展性差。 Git 学习成本高吗？ 相对高，但收益巨大。 ...

副标题 / 摘要 rebase 可以让提交历史更线性，但也会重写历史。本文解释它的价值、风险与使用边界。 目标读者 希望保持整洁提交历史的开发者 团队协作中经常处理冲突的人 需要制定 Git 规范的技术负责人 背景 / 动机 合并分支会产生大量 merge commit，让历史难以阅读。 rebase 能把分支“挪到”最新主线之上，形成更清晰的线性历史。 核心概念 rebase：把分支的提交“搬到”新基线 历史重写：提交哈希会变化 交互式 rebase：整理、合并提交 实践指南 / 步骤 仅对本地未推送的分支使用 rebase 拉取最新主线再 rebase 解决冲突并继续 必要时用交互式 rebase 压缩提交 公共分支禁止 rebase 可运行示例 # 在 feature 分支上 git fetch origin git rebase origin/main # 若冲突 # 解决后： git add . git rebase --continue 解释与原理 rebase 会“重放”每一个提交到新基线上，因此提交哈希会改变。 这让历史更整洁，但也意味着共享分支上会引发冲突与丢失提交的风险。 常见问题与注意事项 rebase 与 merge 有什么区别？ rebase 改写历史，merge 保留历史分叉。 ...