上周和同事一起联调接口我这边还在等服务重新编译同事已经把新的测试包发到群里了。原本以为他手速快后来一聊才发现真正的差距不在打字速度而在于有没有把每天重复的操作沉淀成“一键完成”。这些事情很少会写进官方文档大部分时候是你踩过几次坑、看过几次别人操作之后才慢慢领悟的。今天就借这篇文章把这类“知道的人效率翻倍、不知道的人还在硬扛”的开发技巧整理出来不讨论大而全的理论全是能直接复制到终端里跑的命令和脚本建议先收藏再跟着慢慢试。这类技巧有个共同特点单看每一个都很简单难的是不知道它们存在。一旦用起来日常开发中的很多重复动作都能被压缩到几秒钟内完成。这也是我写这篇文章的初衷既然自己花了不少时间摸索不如把这些经验整理成一份可以直接照着用的清单。文章会按终端效率、Git 操作、日志排查、脚本自动化四个方向展开每个技巧都会给出适用场景、示例命令和容易踩的坑。1. 背景为什么同样的需求别人总能更快交付做开发这行时间是最容易被忽略的成本。同一个需求两个人可能都用一个小时能做完但长期积累下来频繁切换分支、反复输入长命令、手动处理重复文件这些“琐碎时间”会造成巨大的效率差距。很多资深开发看起来处理问题很快并不是智商碾压而是他们把大量常规动作提前固化成了工具和命令遇到问题时只需要调取方案而不是临时思考怎么做。这篇文章不会讨论“代码怎么写更优雅”这类偏主观的话题而是聚焦在通用性很强、几乎任何项目都能直接用的效率技巧上。无论你是刚入行的新手还是已经工作几年的后端开发下面这些内容都值得花半小时过一遍。新手可以把它们当作“进阶操作手册”有经验的开发者也可以对照检查自己是否还有遗漏的盲区。需要提前说明的是文中命令以 Linux/macOS 下的 Bash 环境为准Windows 用户可以使用 Git Bash 或 WSL 来获得相同的体验。Git 相关命令建议使用 2.30 以上版本老版本部分功能会有差异具体版本可以根据自己项目环境调整。2. 环境准备这套技巧在什么条件下验证在开始之前先明确一下环境。下面命令全部在终端中执行如果你的系统是 Ubuntu、CentOS 或 macOS 的默认终端基本可以直接运行。Windows 用户强烈建议安装 Git Bash 或启用 WSL体验会接近 Linux 环境很多命令也才能正常生效。需要准备的工具有Git常用的版本管理工具建议 2.30 版本。Zsh 或 Bash终端解释器macOS 自带 ZshLinux 常用 Bash。tmux可选终端复用工具通过apt install tmux或brew install tmux安装。Shell 脚本执行权限后面会用到.sh脚本需要确保文件有执行权限。版本不需要完全一致重点是思路可以复用。比如git reflog命令在比较老的 Git 版本中就已经存在git switch则要求 2.23 以上版本如果你的 Git 版本过低可以继续使用git checkout替代。3. 第一类秘密终端与 Shell 效率技巧终端是开发者每天打交道最多的工具但很多人的使用方式还停留在“敲命令、等结果”的阶段。下面三个技巧能明显减少键盘输入量和操作步骤。3.1 用 alias 把高频命令压缩成短命令日常开发中总有一些命令长得又臭又长比如查看 Git 状态、查看当前目录文件、清理编译产物。每次敲一遍完整命令很浪费时间alias就是解决这个问题的标准方式。先来看一个最简单的例子alias gsgit status alias glgit log --oneline --graph alias gpgit pull alias gdgit diff把上面几行添加到~/.bashrcBash 用户或~/.zshrcZsh 用户中然后执行source ~/.bashrc或source ~/.zshrc让配置立即生效。之后输入gs就能直接查看仓库状态不再需要敲完整命令。需要注意的是alias只在当前 shell 会话中有效如果不写入配置文件重启终端后就会失效。另外alias 也存在覆盖系统命令的风险比如把ls别名为带-l参数的版本后有些需要原始行为的脚本可能会受影响。建议命名时使用独立的缩写不要覆盖常用原生命令。3.2 历史命令搜索与快速回放很多人的习惯是用方向键一条一条翻历史命令命令一多就特别低效。Bash 和 Zsh 都提供了逆序搜索功能按Ctrl R后输入关键词就能匹配最近的命令记录。# 输入 Ctrl R然后输入关键词例如 deploy # (reverse-i-search)deploy: ./deploy.sh production回车即可执行匹配到的命令继续按Ctrl R可以往上翻更早的记录。这个技巧在重复调试某个编译命令、重启某个服务时非常实用。除了搜索还有一些内建快捷变量值得记住!! # 上一条命令常用于权限不够时sudo !! !$ # 上一条命令的最后一个参数 !* # 上一条命令的所有参数举个例子你执行了docker rm container_abc提示权限不足这时输入sudo !!就可以直接重跑上一条命令并加上sudo省去重新复制粘贴的麻烦。3.3 用 tmux 管理多个终端会话tmux 是一个终端复用工具允许你在一个终端窗口里创建多个会话然后在不同窗格pane中并行操作。开发者用 tmux 的场景通常有两个一是在远程服务器上跑长时间任务避免断线导致任务中断二是在本地同时开编辑器、日志窗口和命令行减少窗口切换成本。常用命令如下tmux new -s dev # 创建名为 dev 的新会话 tmux ls # 查看当前所有会话 tmux attach -t dev # 重新连接到 dev 会话 tmux detach # 在会话内按 Ctrl b 然后按 d在会话内部Ctrl b是前缀键之后可以按水平分割窗格、按%垂直分割窗格。第一次使用 tmux 可能会觉得操作别扭但一旦习惯远程开发和服务器运维的效率提升非常明显。4. 第二类秘密Git 里那些不常用但能救命的命令Git 是每个开发者必备的技能但大多数人只用了add、commit、push、pull这几个基础命令。遇到提交历史写乱、代码误删、需要精准合并某个提交时就很容易卡住。下面这几个命令属于“关键时刻能救命”的类型。4.1 git reflog找回误删的提交场景你用git reset --hard回退了版本结果发现回退之前有几个提交已经被覆盖代码找不回来了。这时候千万不要慌git reflog可以查看 HEAD 指针最近的所有移动记录包括那些被 reset 掉的提交。git reflog输出类似a1b2c3d HEAD{0}: reset: moving to HEAD~2 e4f5g6h HEAD{1}: commit: 修复订单金额计算问题 i7j8k9l HEAD{2}: commit: 增加超时重试机制假设你后悔执行了 reset想恢复到e4f5g6h这个提交可以这样做git reset --hard e4f5g6h建议在执行git reset --hard之前先用git reflog记录当前 HEAD 位置或者直接用git log记下目标提交的 hash。提交被 reset 后并不会立刻消失Git 在定期清理前还会保留一段时间所以只要及时使用 reflog 就能找回。4.2 git stash临时保存未完成的工作场景你正在开发一个功能改了一半但线上突然出现紧急问题需要马上切分支修复。此时不能直接 commit 半成品也不能丢失当前改动git stash就是为这个场景设计的。git stash # 保存当前工作区改动 git stash list # 查看保存的改动列表 git stash pop # 恢复最近一次保存的改动 git stash apply stash{1} # 恢复指定保存项但不删除记录需要特别注意的是git stash默认不会保存新建的未跟踪文件。如果你有新建的文件需要一起保存需要加上-u参数git stash -u我见过很多同事在这个细节上吃亏切换分支后发现自己新建的工具类文件不见了还以为是 Git 出了问题。实际上没有加-u的话新文件并不在 Git 的暂存范围之内。4.3 git cherry-pick精准合并一个提交场景你在dev分支上提交了一个修复但test分支也需要同样的修复而两个分支的代码差异很大不能直接 merge。这时候可以用git cherry-pick把某一个提交单独摘过来。git checkout test git cherry-pick a1b2c3d如果有冲突Git 会停下来让你手动解决解决完之后用git cherry-pick --continue继续。如果发现问题想放弃这次合并可以用git cherry-pick --abort回到操作前的状态。这个命令在多人协作、多分支并行时特别实用能避免重复手改代码。4.4 交互式 rebase整理提交历史git rebase -i的全称是 interactive rebase它允许你对某一段提交历史进行交互式编辑包括合并提交、修改提交信息、删除提交等操作。最常用的场景是把多个临时提交合并成一个逻辑完整的提交。git rebase -i HEAD~3执行后会打开一个编辑界面里面会列出最近三个提交你可以在每个提交前面指定操作指令pick a1b2c3d 修复登录逻辑 squash e4f5g6h 修复登录逻辑的二次修改 squash i7j8k9l 修个手误把后面两个提交的pick改成squash或者简写s保存后 Git 会把这些提交压缩成一个并让你重新填写提交信息。这样最终推送到远程的提交历史会非常干净只有一两个有意义的提交而不是一堆“fix”、“update”、“改一下”。这里要强调交互式 rebase 只适合操作还未推送到远程的提交。如果你已经 push 到团队共享分支再 rebase 会重写历史导致其他同事的本地分支和远程分支不一致非常容易引发混乱。因此这项操作务必在本地分支上使用推送到远程之前确认清楚。5. 第三类秘密日志排查与线上问题定位线上问题的排查速度往往决定了一个开发的靠谱程度。与其盯着 IDE 的调试器反复打断点不如学会在日志文件里快速定位问题。下面几个命令组合是我日常排查问题最常用的。5.1 用 grep 精确过滤日志假设日志文件是app.log你只想查看包含“Exception”的行可以执行grep Exception app.log如果文件很大直接打开会很卡grep 会逐行匹配并输出结果。进一步的需求是不仅要看异常本身还要看异常前面几行的上下文。-B表示 before-A表示 after组合起来就是grep -B 5 -A 10 Exception app.log这条命令会输出异常前 5 行和后 10 行的内容足够你判断异常发生时的调用上下文。如果日志中有时间戳你还可以结合grep过滤某个时间段的数据比如先找出2025-06-18 10:00到10:10之间的日志grep 2025-06-18 10: app.log | grep -A 5 ERROR管道|把前一个命令的输出传给后一个命令这是 shell 组合能力的核心善用管道日志过滤可以无限扩展。5.2 用 awk 统计接口响应耗时有些日志会记录请求耗时比如形如cost123ms的字段。想快速统计所有请求的平均耗时可以直接用 awkgrep cost app.log | awk -Fcost {split($2, a, ms); sum a[1]; count} END {print avg cost:, sum/count, ms}这条命令的思路是先用 grep 筛选出包含耗时的行再用 awk 按cost切分字段提取耗时数值并累加。虽然 awk 的语法看起来有点复杂但它非常适合做日志级别的统计不用引入额外的分析工具。如果只是想看耗时最长的几个请求可以配合 sort 和 headgrep cost app.log | sed s/.*cost// | sed s/ms.*// | sort -n | tail -10这个组合会把每行的耗时提取出来按照数字从小到大排序最后输出耗时最长的 10 个数据。定位慢接口的时候非常高效。5.3 用 tail 实时跟踪日志线上服务出问题时最常用的命令之一就是tail -f它会持续输出文件新增的内容相当于实时查看日志流tail -f /opt/app/logs/app.log如果日志更新得太快想筛选只看 Error 级别的内容可以配合 greptail -f /opt/app/logs/app.log | grep ERROR这条命令会在终端里持续打印新出现的 ERROR 日志非常适合在报障时一边刷新请求一边定位错误。按Ctrl C退出。需要注意tail -f跟踪的是文件内容尾部如果日志文件被重新创建比如 logrotate 切分日志需要重新执行命令。使用tail -F大写可以自动跟踪文件重建更适合长时间挂着的场景。6. 第四类秘密把重复劳动写成脚本开发中最容易被忽视的提效手段就是把每天重复的操作固化成脚本。下面用一个实际项目里很常见的“部署脚本”来演示完整流程。6.1 一键部署脚本场景每次提交代码后需要登录服务器、拉取代码、重启服务、查看日志。这个流程完全可以写成一个脚本每次只需要执行一次命令。#!/bin/bash # 文件路径deploy.sh # 用法./deploy.sh production ENV$1 PROJECT_DIR/opt/projects/my-app BRANCHmaster if [ $ENV production ]; then BRANCHrelease fi echo 开始部署环境$ENV分支$BRANCH cd $PROJECT_DIR || exit 1 git pull origin $BRANCH || exit 1 # 项目是 Spring Boot 场景按需修改 mvn clean package -DskipTests || exit 1 # 重启服务使用 nohup 让进程在后台运行 nohup java -jar target/my-app.jar app.log 21 echo 部署完成PID$!使用前需要给脚本增加执行权限chmod x deploy.sh然后执行./deploy.sh production这个脚本看起来很简单但它包含了几点工程经验加了set -e之外的手动判断每个失败步骤都直接退出避免“服务没构建成功却假装部署好了”用nohup让 Java 进程在终端关闭后继续运行输出 PID 方便后续结束进程。6.2 定时清理日志脚本日志文件只会一直增长如果不定期清理很容易把磁盘写满。可以写一个简单的清理脚本然后交给 cron 定时执行#!/bin/bash # 文件路径clean-logs.sh LOG_DIR/opt/app/logs KEEP_DAYS7 find $LOG_DIR -name *.log -type f -mtime $KEEP_DAYS -delete echo 已清理 $LOG_DIR 下 $KEEP_DAYS 天前的日志文件在 crontab 中配置每天凌晨执行0 3 * * * /opt/scripts/clean-logs.sh /opt/scripts/clean-logs.log 21执行清理操作前最好先跑一遍find $LOG_DIR -name *.log -type f -mtime 7看看会选中哪些文件确认无误后再加-delete。线上环境的清理任务宁可多写一步确认也不要误删。6.3 批量替换文件内容有时候在多个配置文件中修改某个参数比如把所有http://localhost:8080改成http://api.example.com手动一个个改既慢又容易漏。可以用 sed 批量处理sed -i s#http://localhost:8080#http://api.example.com#g config/*.properties这里用#作为分隔符是为了避免字符串里的/和分隔符冲突。-i表示原地修改执行前建议先备份或者用-i.bak保留备份sed -i.bak s#http://localhost:8080#http://api.example.com#g config/*.properties这条命令会把每个.properties文件同时生成一个.bak备份文件确认替换无误后再手动删除备份。7. 常见问题与排查思路下面整理一些使用上述技巧时容易遇到的问题以及对应的排查方向。问题现象常见原因解决思路添加 alias 后新终端不生效未写入配置文件或未执行 source检查~/.bashrc/~/.zshrc执行source后重开终端git stash后新建文件不见了未加-u参数未跟踪文件没被保存使用git stash -u已有丢失可尝试git fsck --lost-found找回git rebase -i后远程分支对不上对已推送分支执行了 rebase确认 rebase 只用于本地未推送提交如已发生需要团队协调处理git reflog找不到旧提交提交已触发 Git 垃圾回收尽量在误操作后立刻使用 reflog不要等太久grep匹配不到内容日志文件编码或关键词不准确先用head -n 20 app.log看日志格式再调整关键词脚本执行提示 Permission denied脚本没有执行权限执行chmod x 脚本名sed -i后发现替换错误直接原地修改且未备份建议统一使用-i.bak替换前预先用不带-i的方式验证输出tmux 会话意外关闭导致任务中断服务器断网或 SSH 断开长任务建议在 tmux 中执行断线后重新 attach初次接触这些命令时不要急着在生产环境验证。最好的练习方式是本地搭一个测试仓库把git reset、git stash、git cherry-pick这些操作都演练一遍熟悉行为后再用于实际项目。尤其涉及删除、回退、批量替换的命令一定要先看输出、再执行写入。8. 最佳实践与工程建议技巧本身不难难的是掌握使用的边界和时机。这里给出几条实践建议帮助你把上面的内容安全地用在日常开发中。第一别追求“最短命令”。alias 能让命令变短是好事但如果起了一个别人完全看不懂的缩写等你休假回来自己都容易忘记含义。建议在设计 alias 时保留语义比如gco代表git checkout而不是随便用a、b这类无意义字母。必要时写注释说明用途。第二破坏性操作前先备份。执行git reset --hard、sed -i、rm这类命令前养成先备份或者先打印检查结果的习惯。写脚本时尽量让每一步失败都退出exit 1避免流程“看似成功、实际失败”。第三区分个人效率和团队规范。像git rebase -i、git push --force这类会改写历史的操作只能用在个人分支或明确允许的分支上。团队协作场景中提交历史的整洁需要所有成员约定一致而不是某一个人独自操作。第四日志和脚本要遵循最小权限原则。部署脚本中的服务器地址、账号密码、密钥等敏感信息不要硬编码在脚本里建议使用环境变量或专门的配置管理工具。清理脚本中的被删除路径用find指定清楚避免误删项目文件。第五把这些技巧逐步内化成自己的工具库。建议维护一个个人 dotfiles 仓库把.bashrc、alias 配置、常用脚本都放进去换电脑后一条命令就能恢复环境。这套做法长期带来的收益远大于第一次整理时投入的成本。9. 总结与后续学习方向这篇文章介绍的技巧核心并不是某一条命令本身而是“把重复动作自动化”的思路。从终端的 alias、历史搜索到 Git 的 reflog、stash、cherry-pick、rebase再到日志排查的 grep、awk、tail 和部署脚本每一个技巧都能单独节省几秒到几分钟但叠加起来就是每天至少半小时的效率差距。如果这是你第一次接触这些命令建议不要一次全部看完选择最贴合你日常工作的两三项先练起来。比如每天都要切分支、看状态的先把 alias 和Ctrl R用熟练经常上服务器查日志的先掌握 tail 加 grep负责发版部署的重点参考脚本那部分。下一步可以考虑的学习方向包括Shell 脚本的进阶语法条件判断、函数、循环、Git 钩子hook的自动化触发、以及 tmux 的更多进阶用法。技术工具的学习有一个共同规律就是只有真正在你自己的项目里跑通一遍知识才会变成经验。如果这篇文章里有哪些命令你之前没有接触过今天找个小项目试一下会有一种“原来还能这样”的感觉。希望这些“秘密”对你后续开发有所帮助。