用 Git 获取代码并保留部署版本

1. Git 管代码版本，不替代业务备份#

Git 适合保存程序、配置模板和文档的变更。数据库、用户上传、密钥和运行日志通常不应直接提交。部署前记录提交编号，出问题时才能知道线上到底运行哪一版。

git --version

没有 Git 时通过当前发行版的软件源安装。提交作者姓名和邮箱是代码记录信息，不是远程仓库登录凭据；不要把访问令牌写进仓库地址或配置截图。

2. 获取仓库后先看状态与来源#

从项目官方页面复制克隆地址，选择 HTTPS 或 SSH。私有仓库使用合适的受限凭据，部署机器通常只需读取权限。

git clone https://github.com/组织/仓库.git
cd 仓库
git remote -v
git status --short
git log -5 --oneline

组织和仓库是占位符，换成真实项目。下载代码不代表可以信任其中的安装脚本；执行前阅读 README、构建脚本和依赖来源。

3. 修改前创建自己的分支#

git switch -c site-change
git diff

完成修改后查看差异，再明确选择要提交的文件。避免不看内容就 git add .，尤其是目录中可能有 .env、备份和测试数据时。

git add 实际修改的文件
git diff --cached
git commit -m 'Describe the change'

.gitignore 只帮助忽略未跟踪文件，已经提交过的密钥不会因加入忽略规则自动消失。若密钥泄露，应先撤销并更换，再处理历史记录。

4. 更新前保留本地修改，部署固定版本#

git status --short
git fetch --tags origin
git log --oneline HEAD..origin/main

主分支未必叫 main，应使用仓库实际分支。工作区有修改时先提交到自己的分支或明确保存，不能用 reset --hard 把问题抹掉。

正式部署可以检出经过确认的 tag 或提交，在独立目录构建后切换。记录 git rev-parse HEAD，比“已拉最新代码”更容易复现。不要让线上目录中的用户上传跟着代码清理命令一起被删。

5. 回退与撤销要选择正确方式#

尚未共享的本地编辑，可先用 diff 逐项确认再恢复文件；已经共享的错误提交，通常使用 revert 产生反向提交，保留审查记录。重写共享历史和强制推送需要团队约定，不能当作普通撤销按钮。

回退代码后重新构建、重启必要服务并检查数据库兼容。Git 不会恢复数据库和外部服务状态，所以仍要有备份流程。应用部署继续看Node.js、Python或Compose。