GitHub 这个东西刚接触的时候大多数人都会经历一个挺尴尬的阶段账号注册完了首页一片空白仓库建了不知道往里放什么clone 下来的代码改了又不敢提交生怕把别人的东西搞坏。我见过不少同学本地代码写得挺溜一到要协作、要提 PR、要处理冲突的时候就卡壳最后干脆把整个文件夹打包发过去让对面自己合并。这种做法在小项目里勉强能糊弄一旦进了正经的多人协作场景基本就是灾难。这篇内容想聊的就是把 GitHub 从一个“代码托管网盘”真正用成协作工具的那条路径。核心关键词会围绕仓库管理、分支策略、提交规范、Pull Request 流程、冲突处理、Issue 跟踪、Actions 自动化这几块展开。适合两类人看一类是刚学会 git 基本命令、想把 GitHub 用明白的新手另一类是已经在用但总觉得流程别扭、想梳理一套稳定工作方式的人。下面这些内容不是命令手册的复述而是我在实际项目里踩过坑之后沉淀下来的做法包括一些文档里不会明说、但直接影响效率的细节。1. 先把仓库这层地基打对初始化与目录约定很多人建仓库就是网页上点两下名字随便起README 勾一下然后就开始往里塞文件。这个动作本身没错但仓库的“地基”如果一开始没打好后面改起来成本很高。仓库的初始化阶段有几个决策点值得认真对待它们决定了后续协作的顺畅程度。1.1 仓库命名与可见性别等到要公开时才后悔仓库命名看起来是小事实际上影响搜索和识别。我的习惯是用“小写字母 连字符”的组合比如>