摘要“分支”是 Git 相比于 SVN 最革命性的特性。它让开发者可以同时在不同的工作流中自由切换互不干扰。很多初学者对分支感到恐惧觉得“合并”等于“冲突”冲突等于“灾难”。本篇将用通俗的“平行宇宙”比喻让你彻底理解分支的本质掌握git branch、git switch、git merge和git rebase通过刻意设计的冲突场景带你亲历冲突解决全流程。读完后你会爱上开分支的感觉也会明白那句名言“Git 分支就像呼吸一样轻松。”一、分支是什么一个提交图的故事在上一篇中我们知道每次git commit都会生成一个快照对象每个对象都包含一个指向其父提交的指针。当我们提交多次后历史就成了一条链A - B - C (main)main是默认分支名旧版叫master它实际上只是一个指向提交 C 的指针。创建一个新分支比如叫devGit 做的事情轻量到你无法想象它只是在.git/refs/heads/目录下写了一个 40 字节的文件内容是某个提交的哈希值。就这么简单A - B - C (main, dev)所以分支的本体就是一个可移动的指针指向某个提交对象。Git 把你每次切换分支后的新提交都挂在当前分支指针对应的链条上。这就像在科幻电影里打开了平行宇宙你可以在不同的宇宙中做完全不同的事情互不干扰最后还能把宇宙合并回来。二、创建与切换分支# 查看所有分支 git branch # 创建 dev 分支 git branch dev # 切换到 dev 分支旧式命令 git checkout dev git switch dev新版的 Git 推荐使用git switch来切换分支语义更清晰git checkout是一个承载太多功能的命令容易让人混淆。也可以一步到位创建并切换git switch -c feature-login现在你在feature-login分支上。做点事情echo 登录模块占位 login.py git add login.py git commit -m 开始开发登录模块查看历史图git log --oneline --graph --all你会看到feature-login分支比main多出一个提交。三、合并分支git merge功能开发完毕需要把feature-login的成果合并回main。先切回maingit switch -c main然后执行合并git merge feature-login如果main在分叉之后没有新的提交Git 会直接将main指针“快进”到feature-login的位置。这就是fast-forward 合并相当于把main这个标签往前一推不会产生新的合并提交。A - B - C - D (main, feature-login)如果你想保留分支的历史轨迹可以在合并时禁用快进git merge --no-ff feature-login这样会生成一个专门的“合并提交”merge commit记录下这次合并的发生。在很多团队协作中--no-ff是推荐做法能清晰地看到功能分支的存在。四、冲突是朋友不是敌人当两个分支同时修改了同一个文件的同一行Git 无法自动决定保留哪个版本这就产生了冲突conflict。我们来刻意制造一次冲突并亲手解决它。4.1 制造冲突在main分支创建一个config.pygit switch main echo database: mysql config.py git add config.py git commit -m 设置数据库为 MySQL然后切到feature-login分支也对config.py进行修改git switch feature-login echo database: postgresql config.py git add config.py git commit -m 设置数据库为 PostgreSQL现在main里是mysqlfeature-login里是postgresql。切回main合并git switch main git merge feature-loginGit 会报警4.2 查看冲突状态git status会告诉你config.py处于both modified状态。4.3 解决冲突用编辑器打开config.py你会看到 HEAD和之间的内容是你当前所在分支main的内容。和 feature-login之间的是被合并分支的内容。你需要手动决定最终留下什么。比如我们想让配置支持两种数据库可以改成database: mysql, postgresql删除掉冲突标记、、保存文件。4.4 完成合并提交git add config.py git commit -m 解决合并冲突同时支持 MySQL 和 PostgreSQL至此冲突解决完毕。可以在git log --graph中看到漂亮的合并历史。五、变基Rebase另一种合并方式除了merge还有一条路叫rebase变基。它的原理是将一个分支上的提交“挪到”另一个分支的顶端重演一遍形成一条笔直的提交历史。假设你在feature分支开发了 D 和 E 两次提交此时main分支又增加了 C1、C2。D---E feature / A---B---C1---C2 main执行git rebase main在feature分支下后会变成A---B---C1---C2---D---E featurerebase的优势在于历史更清晰像一条干净的直线。但它的黄金法则是不要对已经推送到公共仓库的提交执行 rebase因为rebase会改写提交哈希破坏协作者的本地历史。本地开发中如果希望保持整洁可以多用rebase如果在多人协作的分支上保守使用merge。六、分支管理策略与工作流学习分支操作后你需要一个指导原则来管理它们。业界最经典的是Git Flow与GitHub Flow。6.1 Git Flow适合有计划发布周期的项目。包含长期分支main随时可部署到生产环境。develop集成最新的开发成果。feature/*从 develop 分出完成后合并回 develop。release/*从 develop 分出用于发布前的测试和微调完成后合并到 main 和 develop。hotfix/*从 main 分出紧急修复生产问题完成后合并回 main 和 develop。6.2 GitHub Flow更适合持续部署的 Web 应用非常简单main总是可部署。开发新功能或修复 bug 时从main创建描述性的分支如fix-login-bug。在分支上开发完成后发起 Pull Request。讨论、审查代码后合并到main立即部署。无论采用哪种工作流核心思想都是让分支为你服务而不是成为负担。七、操作实践模拟一次完整的 Git Flow我们在本地模拟一个微型 Git Flow 流程# 初始化项目 mkdir gitflow-demo cd gitflow-demo git init echo v1.0 version.txt git add . git commit -m 初始提交 # 创建 develop 分支 git branch develop git switch develop # 创建一个 feature git switch -c feature/greeting echo hello greeting.txt git add . git commit -m 添加问候功能 # 合并回 develop git switch develop git merge --no-ff feature/greeting -m 合并问候功能 # 准备发布 git switch -c release/1.1 develop echo v1.1 version.txt git add . git commit -m 更新版本号至1.1 # 合并到 main 和 develop git switch main git merge --no-ff release/1.1 -m 发布 v1.1 git switch develop git merge --no-ff release/1.1 -m 同步发布改动 # 查看最终历史 git log --oneline --graph --all你会得到一个包含多个合并节点的漂亮历史图。总结分支是 Git 中最轻盈、最强大的机制只是一个指向提交的可移动指针。git branch创建分支git switch切换git merge合并git rebase变基。冲突的产生是因为两个分支修改了同一处内容手动解决冲突后git add并提交即可。黄金法则已推送的分支不要 rebase本地清洁强迫症可以用 rebase协作多用 merge。Git Flow 和 GitHub Flow 是两种主流分支策略根据团队情况选用。如果这篇文章帮你解决了实操上的困惑别忘记点击点赞、分享也可以留言告诉我你遇到的其它问题我会尽快回复。动手练习是掌握编程最快的方法请务必亲手敲一遍本文的所有示例代码并截图保存你的成果。你的关注是我坚持原创和细节共享的力量来源谢谢大家。
平行宇宙的魔法——Git 分支与合并的艺术
摘要“分支”是 Git 相比于 SVN 最革命性的特性。它让开发者可以同时在不同的工作流中自由切换互不干扰。很多初学者对分支感到恐惧觉得“合并”等于“冲突”冲突等于“灾难”。本篇将用通俗的“平行宇宙”比喻让你彻底理解分支的本质掌握git branch、git switch、git merge和git rebase通过刻意设计的冲突场景带你亲历冲突解决全流程。读完后你会爱上开分支的感觉也会明白那句名言“Git 分支就像呼吸一样轻松。”一、分支是什么一个提交图的故事在上一篇中我们知道每次git commit都会生成一个快照对象每个对象都包含一个指向其父提交的指针。当我们提交多次后历史就成了一条链A - B - C (main)main是默认分支名旧版叫master它实际上只是一个指向提交 C 的指针。创建一个新分支比如叫devGit 做的事情轻量到你无法想象它只是在.git/refs/heads/目录下写了一个 40 字节的文件内容是某个提交的哈希值。就这么简单A - B - C (main, dev)所以分支的本体就是一个可移动的指针指向某个提交对象。Git 把你每次切换分支后的新提交都挂在当前分支指针对应的链条上。这就像在科幻电影里打开了平行宇宙你可以在不同的宇宙中做完全不同的事情互不干扰最后还能把宇宙合并回来。二、创建与切换分支# 查看所有分支 git branch # 创建 dev 分支 git branch dev # 切换到 dev 分支旧式命令 git checkout dev git switch dev新版的 Git 推荐使用git switch来切换分支语义更清晰git checkout是一个承载太多功能的命令容易让人混淆。也可以一步到位创建并切换git switch -c feature-login现在你在feature-login分支上。做点事情echo 登录模块占位 login.py git add login.py git commit -m 开始开发登录模块查看历史图git log --oneline --graph --all你会看到feature-login分支比main多出一个提交。三、合并分支git merge功能开发完毕需要把feature-login的成果合并回main。先切回maingit switch -c main然后执行合并git merge feature-login如果main在分叉之后没有新的提交Git 会直接将main指针“快进”到feature-login的位置。这就是fast-forward 合并相当于把main这个标签往前一推不会产生新的合并提交。A - B - C - D (main, feature-login)如果你想保留分支的历史轨迹可以在合并时禁用快进git merge --no-ff feature-login这样会生成一个专门的“合并提交”merge commit记录下这次合并的发生。在很多团队协作中--no-ff是推荐做法能清晰地看到功能分支的存在。四、冲突是朋友不是敌人当两个分支同时修改了同一个文件的同一行Git 无法自动决定保留哪个版本这就产生了冲突conflict。我们来刻意制造一次冲突并亲手解决它。4.1 制造冲突在main分支创建一个config.pygit switch main echo database: mysql config.py git add config.py git commit -m 设置数据库为 MySQL然后切到feature-login分支也对config.py进行修改git switch feature-login echo database: postgresql config.py git add config.py git commit -m 设置数据库为 PostgreSQL现在main里是mysqlfeature-login里是postgresql。切回main合并git switch main git merge feature-loginGit 会报警4.2 查看冲突状态git status会告诉你config.py处于both modified状态。4.3 解决冲突用编辑器打开config.py你会看到 HEAD和之间的内容是你当前所在分支main的内容。和 feature-login之间的是被合并分支的内容。你需要手动决定最终留下什么。比如我们想让配置支持两种数据库可以改成database: mysql, postgresql删除掉冲突标记、、保存文件。4.4 完成合并提交git add config.py git commit -m 解决合并冲突同时支持 MySQL 和 PostgreSQL至此冲突解决完毕。可以在git log --graph中看到漂亮的合并历史。五、变基Rebase另一种合并方式除了merge还有一条路叫rebase变基。它的原理是将一个分支上的提交“挪到”另一个分支的顶端重演一遍形成一条笔直的提交历史。假设你在feature分支开发了 D 和 E 两次提交此时main分支又增加了 C1、C2。D---E feature / A---B---C1---C2 main执行git rebase main在feature分支下后会变成A---B---C1---C2---D---E featurerebase的优势在于历史更清晰像一条干净的直线。但它的黄金法则是不要对已经推送到公共仓库的提交执行 rebase因为rebase会改写提交哈希破坏协作者的本地历史。本地开发中如果希望保持整洁可以多用rebase如果在多人协作的分支上保守使用merge。六、分支管理策略与工作流学习分支操作后你需要一个指导原则来管理它们。业界最经典的是Git Flow与GitHub Flow。6.1 Git Flow适合有计划发布周期的项目。包含长期分支main随时可部署到生产环境。develop集成最新的开发成果。feature/*从 develop 分出完成后合并回 develop。release/*从 develop 分出用于发布前的测试和微调完成后合并到 main 和 develop。hotfix/*从 main 分出紧急修复生产问题完成后合并回 main 和 develop。6.2 GitHub Flow更适合持续部署的 Web 应用非常简单main总是可部署。开发新功能或修复 bug 时从main创建描述性的分支如fix-login-bug。在分支上开发完成后发起 Pull Request。讨论、审查代码后合并到main立即部署。无论采用哪种工作流核心思想都是让分支为你服务而不是成为负担。七、操作实践模拟一次完整的 Git Flow我们在本地模拟一个微型 Git Flow 流程# 初始化项目 mkdir gitflow-demo cd gitflow-demo git init echo v1.0 version.txt git add . git commit -m 初始提交 # 创建 develop 分支 git branch develop git switch develop # 创建一个 feature git switch -c feature/greeting echo hello greeting.txt git add . git commit -m 添加问候功能 # 合并回 develop git switch develop git merge --no-ff feature/greeting -m 合并问候功能 # 准备发布 git switch -c release/1.1 develop echo v1.1 version.txt git add . git commit -m 更新版本号至1.1 # 合并到 main 和 develop git switch main git merge --no-ff release/1.1 -m 发布 v1.1 git switch develop git merge --no-ff release/1.1 -m 同步发布改动 # 查看最终历史 git log --oneline --graph --all你会得到一个包含多个合并节点的漂亮历史图。总结分支是 Git 中最轻盈、最强大的机制只是一个指向提交的可移动指针。git branch创建分支git switch切换git merge合并git rebase变基。冲突的产生是因为两个分支修改了同一处内容手动解决冲突后git add并提交即可。黄金法则已推送的分支不要 rebase本地清洁强迫症可以用 rebase协作多用 merge。Git Flow 和 GitHub Flow 是两种主流分支策略根据团队情况选用。如果这篇文章帮你解决了实操上的困惑别忘记点击点赞、分享也可以留言告诉我你遇到的其它问题我会尽快回复。动手练习是掌握编程最快的方法请务必亲手敲一遍本文的所有示例代码并截图保存你的成果。你的关注是我坚持原创和细节共享的力量来源谢谢大家。
