chituer 的博客

Git 的分支能力非常强，但很多团队把它用复杂了。 常见问题包括： 分支命名五花八门，时间久了没人看得懂 功能分支开太久，主线和分支越来越脱节 main、develop、test、release、backup、temp 一堆分支并存，但没人说得清边界 紧急修复、版本发布、日常开发混在一起，最后人人都觉得“分支很多，但流程并不稳” 所以这篇文章不打算只讲“Git 分支是什么”，而是重点讲： 分

很多人学 Git 最痛苦的时刻，不是不会提交，而是误操作之后那几分钟。 典型心跳加速现场包括： 刚执行完 reset --hard，发现本地改动没了 提交信息写错了，不知道怎么改 把分支删了，才发现里面还有没合并的提交 force push 之后，怀疑把同事的历史覆盖了 想撤销一次错误提交，但又不敢乱动公共分支 好消息是： Git 大多数时候并没有你想象中那么容易“彻底丢东西”。 坏消息是：

学 Git 时，很多人真正开始“害怕它”，往往不是在 commit、push 这些基础命令阶段，而是在第一次遇到冲突、第一次听说 rebase 的时候。 原因也很简单： 冲突一出现，文件里突然多出一堆奇怪标记 rebase 一做，提交历史看起来像被“重写”了 一不小心处理错，就担心代码丢了、历史乱了、同事分支也受影响 这篇文章专门解决这两个最常见、也最容易让人紧张的问题： 冲突到底是怎么产生

当一个项目从“个人写着玩”进入“多人协作、频繁提交、需要稳定上线”的阶段，手工构建、手工测试、手工发布很快就会变成瓶颈。 这时候，GitHub Actions 和 GitLab CI 的价值就会真正显现出来。 它们解决的核心问题不是“会不会写 YAML”，而是： 每次提交后，怎么自动检查代码质量 每次合并后，怎么自动构建产物 每次发布前，怎么自动执行一套稳定流程 出问题时，怎么让发布和回滚更可控

如果说前一篇《Git 从入门到精通》解决的是“Git 命令和底层概念”，那么这篇文章更关注一个现实问题： 真正到团队里，GitHub 和 GitLab 到底怎么用，才能把协作流程跑顺。 很多人会 Git 命令，但一到实际开发平台上就会遇到这些问题： 仓库怎么初始化更规范 分支怎么建，权限怎么控 Pull Request / Merge Request 怎么提才专业 Code Revie