很多人第一次在服务器上用 Git 和 GitHub，卡住的并不是“命令太多”，而是不知道整套流程到底在做什么。
如果把它想成一个简单的协作系统，其实就清楚了：
- 服务器是一台长期工作的机器
- Git 是版本记录工具
- GitHub 是远程仓库和同步中心
- SSH 是让服务器安全访问 GitHub 的方式
这篇文章想做的，就是把这几个环节串起来，形成一条适合个人项目的最小工作流。
为什么通常会先配置 SSH
服务器连接 GitHub，最常见的方式是走 SSH。可以把它想成“服务器拿着自己的钥匙去开 GitHub 的门”。
具体来说：
- 服务器本地保存私钥
- GitHub 记录公钥
- 之后服务器拉取或推送代码时，不需要每次重新输入账号密码
对长期维护的项目来说，这套方式通常比临时输密码更稳定，也更适合自动化。
第一步：在服务器上生成密钥
在服务器终端里执行：
ssh-keygen -t rsa -C "你的邮箱@example.com"如果过程中提示输入保存路径或密码短语，入门阶段通常直接按回车即可。生成完成后，默认会在 ~/.ssh/ 下得到一对密钥文件。
接着查看公钥内容：
cat ~/.ssh/id_rsa.pub你会看到一串以 ssh-rsa 开头的文本，把它完整复制下来。
第二步：把公钥交给 GitHub
在 GitHub 网页端进入：
Settings -> SSH and GPG keys -> New SSH key
然后：
Title填一个方便自己识别的名字，比如Server。Key粘贴刚才复制的公钥内容。- 保存。
做完后，回到服务器验证连接：
ssh -T [email protected]如果看到类似“成功认证”的提示，说明这台服务器已经能正常和 GitHub 通信。
第三步：创建并克隆仓库
如果仓库还没建好，可以先在 GitHub 上创建一个新的 repository。对个人项目来说，初始化时带一个 README 往往更顺手，因为这样仓库一开始就不是空的。
创建完成后，复制 SSH 地址，在服务器执行：
git clone [email protected]:用户名/项目名.git
cd 项目名这样仓库就会被拉到服务器本地，后续所有开发和发布都可以围绕这个目录展开。
第四步：理解 main 和开发分支
现在 GitHub 默认主分支通常叫 main。如果是个人维护的小项目，很多时候直接在 main 上开发就够了。
先查看当前分支：
git branch带 * 的就是当前所在分支。
如果你想把“试验中的修改”和“稳定版本”分开，也可以新建一个开发分支：
git checkout -b dev
git push -u origin dev不过对早期个人站点来说，流程越轻越容易坚持，所以不一定要一开始就把分支策略做得太复杂。
最常用的日常操作流
Git 最重要的一点是：它不会自动替你上传修改。你需要自己明确地告诉它“哪些改动要保存、要怎么命名、什么时候同步到远程仓库”。
最常用的四步是：
1. 查看状态
git status这一步用来确认哪些文件被改过、哪些文件还没被跟踪。
2. 添加到暂存区
git add .这表示把当前目录下的改动加入“准备提交”的集合。对于简单项目这是最省事的写法，但如果改动很多，也可以只添加具体文件。
3. 提交到本地仓库
git commit -m "这里写修改说明"这一步可以理解成“拍一张带注释的快照”。说明文字最好简短但具体，比如：
add new blog postupdate homepage introfix nginx deployment notes
4. 推送到 GitHub
git push这样本地提交才会被同步到远程仓库。
一套适合个人项目的最小心智模型
如果你不想一上来就记很多概念，可以只记住下面这条线：
- 用
ssh-keygen给服务器生成身份。 - 把公钥放到 GitHub。
- 用
git clone把仓库拉下来。 - 日常修改后执行
git status -> git add -> git commit -> git push。
对于个人网站、实验项目或研究记录站点，这已经足够支撑长期更新。
写在最后
Git 真正让人不舒服的地方，往往不是命令本身，而是刚开始不知道它每一步为什么存在。
一旦把它看成“记录版本、明确同步、降低混乱”的工具，而不是一堆需要死记硬背的指令，它就会顺很多。
对个人项目尤其如此：不需要一开始就追求完美的团队规范，先把最小流程跑顺，比一次学会所有高级操作更重要。