首先公网使用 FTP 部署程序是非常不科学的一种方式
- FTP 这种协议本身不安全
- 服务器上的代码不方便回滚
- 只适合 PHP 这种不需要重启的服务
但是没有办法，客户只给开放了 FTP 权限。我实在懒得说服对方。
使用 FileZilla 手动一个一个上传代码文件是一件让人崩溃的事情
- 如果一次特性发布涉及的文件过多，超过10个。一是容易遗漏文件，二是文件分布于多个目录，点击查找目录异常耗时
- 多个文件存在依赖关系时，如果手慢，发布了其中一个文件，但是其他文件在10秒钟之后才上传，那么用户就遭殃了，只能在这10秒钟内笑看错误页面
所以，自动化部署是必然的选择。原本打算自己写一个 shell 脚本来实现，后来发现需要考虑的情况还真不少，就在同事的推荐下尝试了 git-ftp
本地测试了一下非常靠谱。具体的使用流程
首先需要配置远端服务器 FTP 的参数, 打开项目根目录下的 .git/config, 添加
[git-ftp]
url = ftp://x.x.x.x/public_html
user = sunzhongwei
password = ftp_password
注意，public_html 为对应的远端代码根目录，如果不指定的话，可能会在 catchup 时报错
fatal: Could not upload file: '.git-ftp.log'., exiting...
fatal: Could not upload., exiting...
假设上次发布到 ftp 上的代码版本对应的 git tag 为 v5.50, 那么在对应的修改提交之后，给当前版本打上新 tag。
git tag v5.51
然后，将代码 checkout 到上一个版本
git checkout v5.50
git ftp catchup // 第一次使用 git-ftp 时需要使用，之后就不需要了
catchup 的作用是，标记上次更新到了哪次 commit。实现的原理是将本地 git HEAD 对应的 commit HASH 写入远端服务器 ftp 同步目录的 .git-ftp.log 文件。这样就可以在任意开发机上进行 git ftp push 操作了。
然后执行
git ftp push
实际上就是将
git diff v5.50 v5.51 --stat --name-only
的输出文件列表上传到了 ftp 上，同时将远端的 .git-ftp.log 中的提交记录更新。非常方便。
排查问题的小技巧
如果 catchup 失败，从默认给出的错误信息根本定位不了问题，或者说是 debug 信息就是错误的。可以在所有命令后面加上 -vv 来查看具体的 debug 信息, 例如
git ftp catchup -vv
-vv 的说明
-vv Be as verbose as possible. Useful for debug information.
关于作者 🌱
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式