github代码托管

GitHub 的代码代码托管，本质上就是托管把 Git 仓库放到一台别人维护的服务器上。听起来没什么稀奇，代码但真正用过的托管人知道，它改变的代码不只是代码存放位置。

2008 年上线时，托管GitHub 并不是代码第一个代码托管平台。SourceForge 和 Google Code 已经跑了几年。托管区别在于，代码GitHub 把“社交”这件事塞进了版本控制里。托管你可以关注一个人，代码看他今天 push 了什么；可以给别人的托管仓库点 star，像收藏书签一样；可以 fork 一份代码，代码改完再发 pull request。托管这些动作现在看很平常，代码但在当时，代码协作第一次有了“公共广场”的感觉。

我自己的习惯是，每接手一个新项目，先看它的 commit 频率。如果最近半年只有零星几次提交，作者名字还集中在同一个人身上，那这个库大概率已经进入维护模式。反过来，如果 issue 区有人认真回复，pull request 里能看到 review 痕迹，哪怕代码写得一般，也值得多花点时间读一读。这种判断方式，比看 README 里写了多少功能要准得多。

GitHub 的仓库页面其实藏了不少信息。比如 Insights 标签下的 Pulse，能看到一段时间内的提交活跃度；Network 图可以直观地看出分支合并的节奏。有个做前端的朋友告诉我，他面试前会翻候选人的 GitHub 主页，不是看 star 数，而是看 commit message 写得清不清楚。那种“fix bug”“update”反复出现的，通常代码习惯也好不到哪去。

托管在 GitHub 上的代码，并不等于开源。私有仓库照样要付费，免费账户也能建私有库，只是协作者人数有限制。很多人搞混这一点，以为放上去就是公开的。实际上，仓库的可见性设置里，private 和 public 是两个完全不同的世界。我见过有人把公司内部工具误传到 public 仓库，第二天就被安全团队找上门。

另一个容易被忽略的是 .gitignore 文件。GitHub 在创建仓库时会让你选模板，但很多人直接跳过。结果 node_modules 或者 .env 文件被提交上去，轻则仓库体积暴涨，重则密钥泄露。这事我干过一回，把本地数据库密码推到了公开仓库，十分钟后收到一封自动扫描的警告邮件。从那以后，新建仓库第一件事就是检查忽略规则。

GitHub Actions 是后来加的功能，现在成了不少项目的 CI/CD 入口。写一个 YAML 文件，就能在每次 push 时跑测试、构建镜像、部署到服务器。免费额度对个人项目够用，私有仓库每月有 2000 分钟。不过 Actions 的调试体验一般，日志输出有时候绕得让人头疼。我通常会在本地先跑一遍同样的命令，确认没问题再写进 workflow。

代码托管这件事，说到底就是让协作有迹可循。谁改了哪一行，为什么改，什么时候改的，全在 commit 历史里。GitHub 把这个过程做得足够顺手，顺手到很多人忘了它只是一个托管平台。真正重要的东西——代码质量、文档、测试覆盖——它帮不了你。那些得自己来。