Git与SSH实战：大文件传输优化与Git LFS配置指南

在日常开发和服务器运维中，Git 和 SSH 几乎是绕不开的两个基础工具。Git 负责把代码和历史记录管得明明白白，SSH 则负责从本地连到远程服务器、拉代码、执行命令、传文件。我日常最常做的事就是：本地改代码、用 Git 提交、通过 SSH 登录服务器部署；偶尔还要把几十 GB 的数据集或日志快速传到服务器上。这篇文章把我这些年积累下来的 Git 常用命令、SSH 密钥配置，以及大文件传输时常用的优化方案和 Git LFS 用法一并整理出来，给有同样需求的朋友做个参考。

先说一个核心观点：工具本身不难，难的是把工作流理顺。代码用 Git 管，远程访问靠 SSH，大文件传输用 rsync over SSH，仓库内的大文件交给 Git LFS——这套组合我用了很多年，踩过的坑也都消化成了自己的操作习惯。下面逐个展开。

1. 日常开发里绕不开的Git高频命令

先讲 Git。不管你是前端、后端还是搞算法的，Git 的日常使用其实就集中在那么几个操作上。我不打算把官方文档搬过来，直接按场景拆解。

1.1 从克隆仓库到第一次提交

先装好 Git。Linux 上 Debian/Ubuntu 执行apt install git，CentOS 执行yum install git；macOS 可以用brew install git；Windows 直接下载 Git for Windows 安装包，一路下一步即可。装完用git --version验证。

拿到一个项目，最常用的肯定是克隆：

git clone <url> # 指定目录 git clone <url> my-project

如果项目比较深、历史很久，一次性拉全量历史会慢，可以用浅克隆，只取最近一次提交：

git clone --depth 1 <url>

新项目的话，先git init初始化，然后写代码。写完之后的提交链路一般是：

git add . # 把变更加入暂存区 git commit -m "提交说明" # 把暂存区内容提交到本地仓库 git push origin <branch> # 推到远程分支

很多人刚开始会把add和commit搞混，简单理解：add是挑货，把想提交的文件先放到购物车；commit是结算，给这次变更打一个快照并写上说明。每次提交都应该是一个逻辑完整的变更，而不是"改了一半"的中间态。

提交信息也有讲究。别写"update"或者"修改"，尽量说清楚做了什么。比如fix: 修复用户登录接口空指针异常，这样无论是自己回看历史还是同事 review，都省力很多。

1.2 分支管理：合并与会话中的冲突解决

分支是 Git 比较核心的设计。常用操作：

git branch # 查看本地分支 git branch -r # 查看远程分支 git checkout -b feature/xxx # 创建并切换分支 git checkout main / git switch main # 切换已有分支 git branch -d feature/xxx # 删除本地分支 git push origin --delete feature/xxx # 删除远程分支

合并分支最常用的是git merge。举个例子，在 main 分支上执行git merge feature/login，就是把 login 分支的提交合进来。合并完如果有冲突，Git 会在冲突文件里用<<<<<<<、=======、>>>>>>>标出双方改动，手工解决后执行git add再git commit即可。

这里提醒一句：多人协作的项目，合并之前先把 main 更新到最新，git pull origin main或者先git fetch再merge，这样能少很多无谓的冲突。一个大特性合入 main 之前，最好在分支上先git merge main把主干的更新吸收过来，本地测试通过再提 Merge Request。这个习惯帮我少处理了很多冲突现场的烂摊子。

至于rebase，它是把当前分支的提交"垫"到目标分支的最新提交之后，历史更线性。但它会改写提交记录，刚上手的新手先别在公共分支上使用rebase，否则很容易把队友的提交搞乱。

1.3 撤销操作：那些需要"后悔药"的时刻

Git 的权限很大，所以后悔药分好几档：

• 还没add，想撤销工作区的修改：git checkout -- <file>，这个会把文件恢复到上一次提交或暂存区里的状态。
• 已经add了，想退出暂存区：git restore --staged <file>。
• 刚提交完，想撤回这次提交但保留文件改动：git reset --soft HEAD~1。
• 提交完的文件改动也想全部还原：git reset --hard HEAD~1。小心，这个命令会丢弃工作区里所有对应的变更，如果没有备份，改动的代码就找不回来了。
• 已经push到远程分支，想取消：优先用git revert <commit>。它会在历史里加一条反向提交，而不是删掉原来的提交，这样不会破坏被别人拉走的历史。

我见过很多人在reset --hard上吃过亏，所以个人建议：在提交之后、推送之前想撤销，用reset没问题；只要提交已经推送出去了，就用revert，不要去改写远程历史，除非团队就你一个人。

另外还有一个特别好用的临时保存命令：git stash。在代码改了一半、需要临时切到别的分支修 bug 时，git stash把当前改动存起来，切分支干完活再git stash pop恢复回来。带说明的话用git stash save "登录模块实现中"，查看列表用git stash list。

1.4 查看状态、日志与差异

这一块很多人容易忽略，但我觉得它是"用好 Git"的分水岭。光会用add、commit、push不叫会 Git，能随时读懂仓库状态才算。

• git status：看当前状态，哪个文件改了、哪个文件没跟踪，一目了然。
• git log --oneline --graph --decorate：看提交历史，加上--graph能显示分支拓扑，配合-10只看最近 10 条。
• git diff：看工作区里还没暂存的具体改动内容。
• git diff --cached：看已经暂存但还没提交的改动。

排查问题的时候，我会用git log -p <file>看某个文件的完整变更历史，用git blame <file>看每一行是谁、在哪个提交里改的。定位线上 bug 的来源，这两个命令能提供的线索价值非常高。

顺带提一个几乎人人在用的命令：git pull。它其实是git fetch加git merge的合体。如果你的本地分支和远程分支上游关系没配对，git pull会给你一堆提示，这时可以显式执行git pull origin main，或者设置上游分支：

git branch --set-upstream-to=origin/main main

一套 Git 日常命令就可以支撑大部分开发场景了。下面把 Git 和 SSH 串起来，解决最常见的认证和连接问题。

2. Git与SSH：密钥配置、认证失败与网络排查

Git 要连远程仓库，最常用的认证方式有两种：HTTPS 口令认证和 SSH 密钥认证。HTTPS 需要每次输账号密码（或配置凭据管理器），SSH 则是一次配置、长期免密。我推荐大家用 SSH，尤其是频繁推拉代码的场景，体验差距非常大。

2.1 SSH密钥的生成与配置流程

第一步，在本地生成密钥对。大部分 Linux/macOS 都自带 OpenSSH 客户端，Windows 10 以后也默认装了 OpenSSH。生成命令：

ssh-keygen -t rsa -b 4096 -C "你的邮箱或备注"

命令执行后会让你选择保存位置和 passphrase（私钥口令）。保存位置用默认的~/.ssh/id_rsa即可；passphrase 可选，如果设置了口令，每次使用私钥都要输入，除非用ssh-agent缓存。日常自己电脑上我一般留空，公司电脑建议设置口令再加 agent，多一层保险。

生成的公钥在~/.ssh/id_rsa.pub，查看：

cat ~/.ssh/id_rsa.pub

把公钥内容加到 Git 平台的 SSH keys 设置里。以 GitHub 为例，路径是 Settings -> SSH and GPG keys -> New SSH key。其他平台大同小异，都是把ssh-rsa AAAA...那一整行粘进去。

接下来让 Git 知道你用什么身份提交：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

然后测试连接：

ssh -T git@github.com

如果你用的是 Gitee 或者 GitLab，把域名换掉即可。首次连接时会出现 host key 询问，输入yes回车，之后会把指纹记录到~/.ssh/known_hosts。

到这里，SSH 密钥认证就算配好了。之后git clone git@github.com:user/repo.git就不会再问你密码。

有人嫌每次敲ssh -T git@github.com试连接麻烦，可以在~/.ssh/config里写一个别名：

Host github HostName github.com User git IdentityFile ~/.ssh/id_rsa ServerAliveInterval 60

这样可以直接用ssh github测试，git clone github:user/repo.git也能识别。ServerAliveInterval是保活参数，后面传大文件时还会提到。

2.2 "Permission denied" 的排查路径

SSH 认证失败是最常见的问题之一，一般报错是Permission denied (publickey)或者git@github.com: Permission denied (publickey).。我排查的思路都是按顺序走：

1. 确认公钥是否真的加到了平台。核对一下，公钥内容要用cat显示的内容，不要手动截取，很容易漏中间部分。
2. 确认本地用的是哪个私钥。如果~/.ssh/下有多个密钥文件，Git 默认可能选错。用ssh -vT git@github.com查看输出，里面会显示尝试了哪个 IdentityFile。必要时用-i ~/.ssh/yourkey指定。
3. 确认仓库地址是不是 SSH 形式。用git remote -v看 remote 地址，如果显示的是https://，那就算 SSH 配好了，走的仍然是 HTTPS 认证。
4. 检查权限。服务端用户的.ssh目录权限、authorized_keys文件权限不对也会拒绝。本地私钥权限如果太开放（比如 644），SSH 会拒绝使用，一般要求 600。
5. 如果是公司自建的 Git 服务，防火墙或代理拦截也可能导致无法连接，这就不只是密钥问题了。

这里补充一个服务器端的权限要求：登录用户的.ssh目录要执行chmod 700 ~/.ssh，authorized_keys文件要chmod 600 ~/.ssh/authorized_keys。很多人配了公钥但忘了权限，老是遇到 Permission denied，就是卡在这一步。

2.3 连接超时、断开后的服务保活

还有一类问题是不报认证错，而是直接卡住或超时。可能是网络原因、对方 SSH 服务端口不通，或者是服务器的 sshd 服务没起来。

以自建 Linux 服务器为例，用 SSH 登录之后，很多人会遇到这样一个场景：在远程终端里启动了一个 node 服务，关了 SSH 窗口，服务也停了。这其实是因为进程是终端会话的子进程，终端断开后收到 SIGHUP 信号就退出了。解决方式有几种：

• 用nohup：nohup node app.js > app.log 2>&1 &，让进程忽略挂断信号。
• 用tmux或screen：先tmux new -s app，在里面启动服务，之后按Ctrl+b再按d脱离会话，服务继续跑。下次tmux attach -t app还能回去看日志。
• 最规范的是用systemd写一个 service 单元，让服务由系统托管，开机自启、异常重启都省心。

另外，通过 SSH 传大文件传着传着突然断开，那种挫败感我太懂了。下面重点讲rsync这个真正能救命的方案。

3. SSH传输大文件：三大痛点与两套优化方案

先讲清楚，这里说的"通过 SSH 传输大文件"，场景是：你已经能用 SSH 登录远程服务器，希望把本地的一个大文件（比如几个 GB 的数据集、日志包、虚拟机镜像）传到服务器上，或者从服务器下载下来。常见的工具是scp和sftp，但大家都知道，一旦文件上了 GB，速度慢、断线重传这些痛点就全部暴露了。

3.1 为什么传大文件会慢，慢在哪

先说scp。它基于 SSH 协议，本质上是在加密隧道里复制文件。影响速度的因素主要有三个：

1. 加密开销。SSH 默认使用的加密算法、MAC 算法有计算开销，在 CPU 不太行的机器上会明显影响吞吐。
2. 单连接限制。scp 是单条 TCP 连接，无法利用多线程并行传输，而且 TCP 的窗口和拥塞控制会限制在长肥网络的吞吐表现。
3. 无断点续传。传一半断了，scp只能从头再来。这是最让人崩溃的一点。

所以我的第一建议是：传输大文件别用 scp，改用rsync over SSH。它在底层仍然走 SSH 认证和加密，但多了增量同步、断点续传、多文件保留权限等能力，可以说为传输场景而生。

3.2 SSH配置参数调优

在讲 rsync 之前，先看看 SSH 这一层能优化的参数。这些配置写在客户端的~/.ssh/config里，或者直接用命令行参数传。

推荐的一组：

Host myserver HostName 192.168.1.100 User root Port 22 Compression yes Ciphers aes128-gcm@openssh.com ServerAliveInterval 30 ServerAliveCountMax 3 ControlMaster auto ControlPath ~/.ssh/controlmux/%r@%h:%p ControlPersist 10m

逐条解释：

• Compression yes：开启压缩。对文本类文件、代码、json 这类高冗余数据效果非常明显；对已经压缩过的图片、视频、压缩包，压缩反而浪费 CPU，这时可以把这里关掉。
• Ciphers aes128-gcm@openssh.com：把加密算法切到 AES-GCM。新版本 OpenSSH 默认已经比较高效，但如果你想榨干性能，可以显式指定。注意服务器端要支持该算法，老版本系统不一定支持。
• ServerAliveInterval 30：每 30 秒发一个心跳包，防止长时间没有数据传输，连接被路由器或防火墙掐断。
• ControlMaster和ControlPersist：连接复用。第一次连接后，后续同目标的 SSH 会话直接复用已有连接，省去握手和密钥交换的开销。传大量小文件时尤其有用。

举一个实际例子：我在局域网里传一个 4GB 的文本类日志文件，用 scp 默认参数大概要两三分钟，加上Compression yes和 AES-GCM 之后，能缩短到一分钟出头。如果是跨公网传输，TCP 单连接本身的带宽瓶颈才是主要矛盾，这部分优化只能减少 CPU 因素，不能让物理带宽变大，这个要有预期。

还有一个小细节：如果服务器把 SSH 端口改成了非 22 端口，记得在配置里写Port，否则连接永远超时或者报连接被拒。排查连接问题第一步就是确认端口通不通，可以用telnet 主机IP 端口或者nc -vz 主机IP 端口快速看。

3.3 rsync 断点续传：大文件传输的正确姿势

rsync 是我传大文件的首选。它和 scp 最大的区别是：它会对比本地和远端文件，只传输有差异的部分，并且支持中断后继续。传 20GB 的文件，断了网络，重新执行同样的命令，它会从断点继续，而不是重头再来。

最常用的命令：

rsync -avz --progress --partial /本地路径/文件 user@server:/远程路径/

参数含义：

• -a：归档模式，保留权限、时间戳、软链接等元数据。
• -v：显示过程。
• -z：传输时压缩（对文本类文件有明显收益）。
• --progress：显示进度和速率。
• --partial：关键参数。传输中断时保留已接收的部分文件；不加这个，中断后临时文件会被删除，续传就无从谈起。

这里给一个 scp 和 rsync 的直观对比：

如果传的是整个目录，注意路径末尾的斜杠。rsync -avz /src/ user@server:/data/表示把 src 目录里面的内容同步到 data 目录；rsync -avz /src user@server:/data/则是把 src 目录本身放到 data 目录下。斜杠差一个，目录层级完全不同。

还有一些参数按需添加：

• --bwlimit=5000：限制带宽为 5000 KB/s，避免传输占满带宽影响同网络里的其他服务。
• --delete：让远端目录和本地完全一致，删除本地已不存在但在远端存在的文件。这个参数很危险，一般建议先用--dry-run预览。
• -n或--dry-run：演练模式，只显示将要传输的文件列表，不实际传输。
• --exclude '*.tmp'：排除特定文件。

下载方向的 rsync 也很简单，把源和目标反过来即可：

rsync -avz --progress user@server:/远程路径/文件 /本地路径/

实际使用 rsync 有一个需要注意的点：如果两端文件差异很小，比如只改了一个字节，rsync 依然需要扫描整个文件块来计算差异，大文件首次扫描会有些耗时，但相比传输整个文件已经省很多了。rsync 的算法会按固定块大小对文件做分块校验，两端都要算一遍，CPU 也有一定开销。不过对绝大多数运维场景，收益远大于开销。

几个真实案例：

• 备份数据库导出文件：每天生成的 dump 文件大约 8GB。直接 scp 下载要 20 多分钟，断了就得重来。改成 rsync 增量同步，每天只传变更部分，几分钟搞定，断线了重跑一次能继续。
• 多台服务器同步静态资源：一台机器拉取构建产物，再 rsync 到内网多台机器。配合ControlMaster连接复用，整体时间从半小时降到几分钟。

rsync 没装的话，Debian/Ubuntu 用apt install rsync，CentOS 用yum install rsync。服务器端只需要 openssh-server 正常工作，不需要额外跑 rsync daemon，就能通过 SSH 隧道传输。

4. Git LFS：让大文件不拖垮仓库的专用工具

如果说 rsync 解决的是"文件传到服务器"的问题，那么 Git LFS（Large File Storage）解决的就是"大文件放进 Git 仓库"的问题。这两者经常被放在一起讨论，因为很多人上传几 GB 的模型文件、设计稿到 Git 仓库，结果仓库体积膨胀，clone 和 pull 慢到爆炸。Git LFS 就是干这个的。

4.1 Git LFS 的工作原理

普通 Git 仓库里，每次提交会在.git对象库里存一份文件快照。一个大文件哪怕只改了一点点，提交后也会在对象库里多一整个文件副本。历史一多，仓库就成了"胖子"，每次 clone 都要把这个胖子完整拉下来。

Git LFS 的思路是：把大文件本体从 Git 仓库里挪走，放到专门的文件存储服务上，Git 仓库里只保存一个几十到几百字节的指针文件。指针内容大概长这样：

version https://git-lfs.github.com/spec/v1 oid sha256:4d7a214b8b6ecf... size 123456789

clone 或者 checkout 的时候，Git LFS 根据指针文件里的 oid，从 LFS 存储服务器把真实文件取回本地。普通文件由 Git 管，大文件由 LFS 管，互不干扰。

这意味着远程仓库的 Git 数据量只和大文件的数量有关，和大文件的实际大小无关。别人 clone 仓库时，默认可以只拉指针不拉大文件，需要时再触发拉取，体验会好很多。

4.2 安装配置与基础命令

安装 Git LFS：

# Debian/Ubuntu apt install git-lfs # macOS brew install git-lfs

装完之后，在仓库里执行一次初始化：

git lfs install

这一步会把 Git LFS 的 filter 写进全局配置（~/.gitconfig），让 Git 在 add/checkout 时自动调用 LFS 处理。

然后指定哪些文件类型归 LFS 管：

git lfs track "*.psd" git lfs track "*.zip" git lfs track "models/*.bin"

它会修改仓库里的.gitattributes文件，把规则固化下来，这个文件本身要提交到仓库。

之后就是正常的 Git 流程：

git add . git commit -m "add large files" git push origin main

push 时 LFS 文件会自动传到 LFS 存储。查看仓库里已经有哪些文件被 LFS 管理：

git lfs ls-files

顺带提醒一个坑：GitHub、Gitee 这类平台对 LFS 都有容量限制，免费额度超了会直接拒绝上传。如果 push 报了一个batch response: Repository or file not found或者 403 错误，多半是额度或权限问题。要么升级套餐，要么换自建的 LFS 服务器（Gitea 和 GitLab 都支持内置 LFS 存储）。

4.3 clone 卡住的排查与应对

很多人反馈"git lfs clone 卡住"，这个我很熟。Git LFS 拉取大文件时默认会并发下载，如果文件特别大、网络不稳，卡住几乎是必然的。

Git LFS 2.x 之后，官方建议直接用普通git clone，不必再刻意用git lfs clone。但 clone 时的 LFS 拉取行为默认会把当前分支指向的所有 LFS 文件全部下载下来，如果仓库里 LFS 文件总大小有几十 GB，"卡住"就容易发生。

排查思路：

1. 先看是不是网络问题。git lfs env可以看当前 LFS 配置，git lfs logs last看最近的传输日志，有没有大量超时重连。
2. 控制并发数。命令行设置环境变量GIT_LFS_CONCURRENT_TRANSFERS=1，降低并发，减少断连概率。
3. 开启断点续传。Git LFS 对单个文件的上传下载本身支持断点续传，但如果进程被你 Ctrl+C 掉了，下次会从头开始。尽量让它自然重试。
4. clone 的时候先不拉 LFS。Git 有一个环境变量GIT_LFS_SKIP_SMUDGE=1，设置后 clone 只拉指针文件，不拉真实大文件。需要时再单独执行git lfs pull，这样至少仓库数据能立刻到位。

组合操作大概是：

GIT_LFS_SKIP_SMUDGE=1 git clone git@github.com:user/repo.git cd repo git lfs pull

git lfs pull也支持只拉指定子目录或指定文件：git lfs pull -I "models/*.bin"。如果模型文件特别多、只想取其中一个模型，这个参数很实用。

还有个相关问题：如果你的仓库里已经不小心提交了大文件，想彻底清理历史，常规做法是用git filter-repo或 BFG 重写历史，然后把远程仓库强制推送。这会改历史，只适合在团队能接受的情况下操作，而且搞完之后所有人要重新 clone。对于新文件，从一开始就用 LFS 跟踪，才是省心的方案。

5. 把 Git、SSH 和高效传文件串起来的日常流程

工具单独讲完了，最后串一下我日常工作里真实在用的流程组合。这些细节是官方文档里不会写的，但实际用起来非常关键。

5.1 一个典型的部署/同步流程

假设本地项目里既有普通代码，又有几个 GB 的模型文件。我的一般流程：

1. 代码部分走 Git 常规流程：git add、git commit、git push。
2. 模型/大文件如果项目里必需，就用 Git LFS 跟踪，提交推到支持 LFS 的远端仓库。
3. 部署到服务器时，不一定每次从 Git 拉。如果是内网服务器，直接用 rsync 把构建产物推过去：

rsync -avz --progress --partial ./dist user@server:/var/www/project/

4. 如果服务器需要通过 Git 更新代码，我会在服务器上git pull，大文件用git lfs pull按需拉取，避免把所有模型都甩到服务器上。

这里有一个经验：不要把服务器当作 Git 仓库的"消费者"来 Pull 大文件。很多部署场景里，服务器只需要最新一版的产物，不需要完整历史。更合理的做法是在本地或 CI 机器上构建好，再用 rsync 把产物同步过去。rsync 天然实现"只传变化的部分"，比在服务器上git pull重拉一遍所有变更要高效得多。

5.2 运维视角下的细节与教训

最后说几个我踩过的坑，希望能帮你少走弯路。

权限问题永远是第一位的。rsync 走 SSH 时，如果服务器端用户的~/.ssh/authorized_keys权限不对，你会一直看到Permission denied。服务器端检查一下：chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keys。本地私钥同理，chmod 600 ~/.ssh/id_rsa。

传输中断别急着重新 scp。先看看 rsync 有没有装，能不能直接续传。很多人在断线后下意识重跑 scp，白白浪费大量时间。用 rsync 只要记得加--partial，重跑一次即可。

大文件传完别忘了校验。文件几 GB 的传输过程中万一有静默损坏，解压或读取时才暴露问题成本更高。传输完跑一下md5sum或sha256sum对比两端校验值。rsync 本身基于校验和能保证一致性，但某些非文件复制场景（比如在目标上再处理过的文件）还是需要手动校验。

关于 SSH 连接断开导致服务停掉的问题，建议优先用 systemd 管理常驻服务。tmux适合调试场景，nohup适合临时任务，但 systemd 才能保证重启后自动拉起、崩溃后自动恢复。我在生产环境上基本不用前两种。

如果你经常要在多台机器之间传文件，记得在~/.ssh/config里把常用主机配置好别名，配合 ControlMaster 复用连接，整体体验会有一个质的提升。尤其是大量小文件的 rsync，连接复用能把耗时砍掉一半以上。

工具都是很成熟的东西，关键是把自己的工作流理清楚：代码用 Git 管，小文件随便 scp，大文件走 rsync，仓库里的大文件交给 Git LFS，常驻服务交给 systemd。这套组合我用了几年，省下的时间不是一点半点。最后再分享一个我自己的小习惯：每次传超大文件之前，我都会先看一眼目标磁盘空间还剩多少，别传着传着把磁盘写满了才发现，那比传输中断还要难处理。希望这篇整理对你有用。