你改完代码，git push。然后打开终端，ssh连上服务器，git pull，或者手动上传文件。一天重复几十次。有时候忘了部署，用户看到的是旧版本。
能不能做到：你本地git push，服务器自动更新？能。GitHub Actions就是干这个的。你写好一个配置文件，GitHub收到push后自动执行里面的命令——登录服务器、拉代码、重启服务。全自动。
今天带你配一个最简单的部署流程。
先看一个数据
GitHub Actions每月免费提供2000分钟运行时间。个人开发者、小团队根本用不完。私人仓库也免费。你不知道，就错过了这个免费的CI/CD工具。
这2000分钟，够你跑几千次部署。自动部署的成本为零。
GitHub Actions是什么？
GitHub Actions是GitHub自带的CI/CD工具。你的代码在GitHub上，Actions能在代码变动时自动触发任务。不需要买Jenkins服务器，不需要搭复杂的流水线。
核心概念：
- workflow：一个自动化流程，用YAML文件定义
- event：触发workflow的事件，比如
push、pull_request - job：一组步骤，在同一个runner里执行
- step：单个任务，比如执行命令、安装软件、跑脚本
- runner：执行任务的虚拟机，GitHub提供，免费的
第一步：准备服务器
在开始之前，确保你的服务器满足条件：
- 能通过SSH免密登录
- 部署脚本已经写好
配置SSH免密登录：把本地公钥加到服务器的~/.ssh/authorized_keys。测试一下ssh user@服务器IP能直接进去。
写一个部署脚本，放在项目根目录deploy.sh：
bash
#!/bin/bash cd /var/www/myapp || exit git pull origin main npm install # 或 composer install systemctl restart myapp
手动跑一次./deploy.sh，确保没问题。给执行权限chmod +x deploy.sh。
第二步：在GitHub仓库配置密钥
GitHub Actions要登录你的服务器，需要把私钥存在GitHub里。
生成SSH密钥（如果没有）：
bash
ssh-keygen -t ed25519 -C "github-actions"
把公钥加到服务器：
bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@服务器IP
把私钥存到GitHub：
- 打开你的GitHub仓库 → Settings → Secrets and variables → Actions
- 点击”New repository secret”
- Name填
SSH_PRIVATE_KEY - Secret里粘贴私钥内容（
~/.ssh/id_ed25519）
再把服务器用户名和IP存成另外两个secret：SERVER_USER、SERVER_HOST。
第三步：创建Actions配置文件
在你的项目根目录创建.github/workflows/deploy.yml：
yaml
name: Deploy to Server
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup SSH
run: |
mkdir -p ~/.ssh
echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ssh-keyscan -H ${{ secrets.SERVER_HOST }} >> ~/.ssh/known_hosts
- name: Deploy to Server
run: |
ssh ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} 'bash -s' < ./deploy.sh
这个YAML在每次push到main分支时触发。步骤是：拉代码、配SSH、登录服务器执行部署脚本。
第四步：提交测试
把配置文件提交到GitHub：
bash
git add .github/workflows/deploy.yml deploy.sh git commit -m "add GitHub Actions auto deploy" git push origin main
提交后，去GitHub仓库的Actions标签页，看到workflow正在运行。点进去能看到每一步的输出。
绿色对勾：成功。红色叉号：失败，点进去看哪一步报错。
第一次跑可能失败，常见原因：
- 私钥权限不对（要600）
- 服务器IP错了
- 部署脚本里路径不对
- 服务器上没有部署脚本需要的环境（git、npm等）
看日志，逐项排查。
其他常用事件
push到特定分支是最常用的。其他常用触发条件：
yaml
# 每天凌晨2点定时跑
on:
schedule:
- cron: '0 2 * * *'
# 手动触发（点按钮）
on:
workflow_dispatch:
# 标签推送时触发（比如发布新版本）
on:
push:
tags:
- 'v*'
进阶：多环境部署
你可能需要开发环境、生产环境分别部署。
用不同的配置文件，或者用GitHub Environments功能，设置不同的secret。在deploy.yml里指定环境：
yaml
jobs:
deploy-staging:
runs-on: ubuntu-latest
environment: staging
steps:
# staging的secret
生产环境可能需要审批才能部署，在Environment里配置。
真实案例
一个开源博客系统，作者每次在本地改完代码，要先登录到自己的演示服务器，git pull，再重启服务。做了GitHub Actions自动部署后，每当他合并PR到main分支，演示站自动更新。
他说：“演示站再也不用手动更新了。用户看到的总是最新版。我每天省下10分钟。”
排查技巧
workflow被触发了但没执行：检查on.push.branches里的分支名是否正确。
SSH连不上：手动用私钥登录服务器测试。如果用ssh -i 私钥文件 user@IP登录不了，公钥没配好。
命令找不到：runner里的环境可能缺软件。如果需要node、python，用actions/setup-node等官方action安装。
部署脚本没权限：确保脚本有执行权限，用chmod +x。或在SSH命令里用bash deploy.sh而不是./deploy.sh。
最后一句
GitHub Actions免费、简单、和你的代码仓库深度集成。不用运维新的服务，不用学复杂的流水线语法。
你的小团队，这几行YAML就够用了。不需要Jenkins，不需要自建任何东西。
第一次配置可能需要半小时，但之后每次push代码，自动部署。省下的时间，够你每天多睡一会儿。
去你的GitHub仓库点开Actions标签页，创建一个新workflow。从复制粘贴开始。你的第一次自动部署，就从今天开始。