手写代码老炮儿的 Git 技巧：从 Springboot 到区块链，我的综合生存指南
去年双11大促前夜，我们组的测试群里突然炸了：“线上订单服务挂了！回滚！快回滚！”
我手一抖，差点把刚泡好的枸杞茶泼到键盘上。运维小哥在隔壁工位吼：“谁动了 prod 分支？怎么 merge 了个 feature 分支进去？！”
那一刻，我真的想砸电脑——不是因为 Bug，而是因为我居然没用好 Git。
大家好，我是老陈，在这个以“敏捷”为名、实则天天赶 deadline 的后端组干了快两年。平时写 Springboot 写得手都酸了，最近被领导“委婉建议”学点 AI 和区块链（说是为了“技术前瞻性布局”）。但我骨子里还是个手写代码的老派程序员——能手敲就绝不 copy-paste，能本地调试就绝不依赖 AI 补全（虽然最近偷偷试了 GitHub Copilot，真香……但打死不承认）。
今天这篇不是什么高深原理，就是我这两年踩坑、背锅、深夜加班后总结出的一套 Git 实战技巧。尤其适合像我这种既要维护传统 Springboot 项目，又要硬着头皮搞点区块链 PoC（Proof of Concept）的“综合型打工人”。
为什么 Git 这么简单的东西，我们总能搞砸？
先说个真实场景：上周五晚上 9 点，产品经理突然甩来一个需求：“明天上线前加个用户积分功能，很简单，就一个字段。”
我心想：行吧，开个新分支 feature/user-points，改完推上去，PR 一提，完事。
结果呢？
我本地还在 dev 分支，手滑直接 commit 了，没切分支。更惨的是，我 pull 了一下远程 dev，发现同事刚合了一个大改动，冲突一堆。我一着急，git add . + git commit -m "fix" 直接糊上去。第二天 code review 的时候，组长看着我 PR 里混着三个不同功能的改动，眼神都空了。
“你这代码，是拿脚写的吧？”
其实问题不在 Git 难，而在于 我们太依赖“直觉操作”。
尤其是在多项目并行、技术栈杂糅（比如一边调 Springboot 接口，一边研究 Hyperledger Fabric）的时候，分支管理一乱，整个人就崩了。
技术选型对比：别让 Git 成为你项目的“单点故障”
很多人觉得 Git 就是个工具，无所谓怎么用。但在我参与过的项目里，Git 工作流的选择直接影响了交付效率，甚至线上稳定性。
下面是我对比过几种常见 Git 工作流后的真实感受：
| 工作流类型 | 适用场景 | 优点 | 缺点（血泪教训） |
|---|---|---|---|
| Centralized（集中式） | 小团队、内部工具 | 简单，上手快 | 分支混乱，容易误操作主干 |
| Feature Branch | 中小型业务（如 Springboot） | 功能隔离清晰 | 合并冲突频繁，CI/CD 配置复杂 |
| GitFlow | 有严格发布周期的项目 | 版本管理规范 | 流程太重，小功能也要走 release |
| Trunk-Based | 高频部署（如互联网大厂） | 快速集成，减少长生命周期分支 | 对测试覆盖要求极高，新人易翻车 |
我们组目前用的是 Feature Branch + PR Review 模式，主要跑 Springboot 微服务。但最近搞区块链 PoC 时，发现这套流程在“实验性开发”场景下特别难受——经常要快速验证一个 idea，开分支、提 PR、等 review，黄花菜都凉了。
于是我们做了一次“综合”调整：核心业务用 Feature Branch，实验性模块（如智能合约模拟）用本地临时分支 + force push 到个人命名空间。比如：
# 区块链实验分支，只推到自己的 remote namespace
git checkout -b exp/smart-contract-v2
git push origin exp/smart-contract-v2:refs/heads/exp/chen/smart-contract-v2
这样既不影响主干，又能保留历史记录。等 PoC 验证通过，再按标准流程开正式 feature 分支。
我的 Git 技巧清单：从“救火”到“防火”
1. 别再 git add . 了！学会精准提交
我以前也觉得 git add . 很爽，直到有一次把本地测试配置文件（含数据库密码）提交上去，被安全扫描告警，全员邮件通报……
现在我强制自己用 git add -p（interactive staging）：
git add -p
# 然后按提示选择 y/n/e 等，逐块确认变更
它会把 diff 拆成“hunk”，让你决定哪些块进暂存区。虽然慢一点，但避免了“不小心提交了 node_modules”或者“log 文件被加进去”这种社死现场。
小技巧：配合
git config --global core.editor vim，用 Vim 查看差异更高效（别笑，手写党都懂）。
2. 分支命名规范：别让队友猜你在干啥
我们组吃过亏：有人开分支叫 fix，有人叫 update，还有人叫 try……最后合并时根本不知道哪个是哪个。
现在强制规范：
feat/user-login→ 新功能fix/order-timeout→ Bug 修复exp/blockchain-sync→ 实验性（仅限 PoC）hotfix/prod-crash→ 紧急线上修复
特别注意：区块链相关的分支一定要标 exp/ 或 poc/，否则哪天有人误合到生产环境，那可不是丢工作的问题了——区块链一旦上链，改都改不了！
3. Rebase vs Merge：别再制造“毛线团”历史了
Springboot 项目还好，但区块链项目里，commit 历史一旦乱了，追溯交易逻辑简直噩梦。
我现在的原则：
- 本地分支开发时，用 rebase 保持线性历史
- 合并到主干时，用 merge 保留上下文
比如：
# 在 feature 分支上开发
git checkout feat/payment
# 定期同步 dev 最新代码（保持基于最新基线）
git fetch origin
git rebase origin/dev
# 开发完成，准备 PR
git checkout dev
git merge --no-ff feat/payment # --no-ff 保留分支结构
这样 Git 历史既干净（rebase 避免中间合并点），又有可追溯性（merge commit 明确功能边界）。
吐槽：有些新人喜欢
git pull，其实就是fetch + merge，很容易产生无意义的合并提交。我建议 alias 成git pull --rebase。
4. 利用 .gitignore 的“分层策略”
Springboot 项目有 application-local.yml，区块链项目有 wallet.dat，前端还有 node_modules…….gitignore 写不好，仓库体积爆炸。
我的做法是：
- 全局 ignore：
git config --global core.excludesfile ~/.gitignore_global - 项目级 ignore：每个 repo 自己的
.gitignore - 临时 ignore：
echo "temp.log" >> .git/info/exclude（只影响当前 repo，不提交）
例如我的全局 ignore：
# IDE
.idea/
.vscode/
# Logs
*.log
# OS
.DS_Store
Thumbs.db
# Blockchain temp
wallets/
keystore/
这样就不会每次新建项目都要复制粘贴一遍。
5. 救命命令：当你已经搞砸了
别慌，Git 几乎都能救回来。分享几个我深夜保命的命令：
场景1：刚 commit，发现写错了 message
git commit --amend -m "正确的提交信息"
场景2：push 之后才发现 commit 有问题（还没人 pull）
# 修改代码后
git add .
git commit --amend
git push --force-with-lease # 比 --force 更安全！
⚠️ 注意：
--force-with-lease会检查远程分支是否被别人更新过，避免覆盖他人代码。
场景3：误删了分支？
git reflog # 查看 HEAD 历史
git checkout -b recovery-branch <commit-hash>
上次我不小心 git branch -D exp/smart-contract，靠这招找回了三天的工作。
综合项目中的 Git 实践：Springboot + 区块链的“混合开发”挑战
最近我们在做一个“积分上链”PoC：用户在 Springboot 应用中获得积分，通过 API 触发智能合约写入区块链。
问题来了：两个技术栈，两套代码库，怎么协同开发？
我们的方案：
- 主应用（Springboot）：严格遵守 Feature Branch + PR + 自动化测试
- 区块链模块（Fabric Chaincode）：独立 repo，使用
exp/分支快速迭代 - 集成层：通过 Git Submodule 或 CI 脚本动态拉取指定版本的 chaincode
关键点在于 版本对齐。我们在 Springboot 的 application.yml 里加了个配置：
blockchain:
chaincode:
version: "v0.3.1-exp" # 对应 blockchain repo 的 tag
然后 CI 流程会自动校验该 tag 是否存在。这样即使区块链那边还在疯狂改，主应用也能锁定稳定版本。
顺便吐槽：产品经理以为“上链”就是点个按钮，结果我们光调通 Springboot 调用 Fabric SDK 就花了两周，还因为 TLS 证书配错导致节点连不上……那晚我对着
x509: certificate signed by unknown authority报错喝了三杯咖啡。
最后一点心得：工具再强，不如流程靠谱
我知道现在有很多 AI 辅助工具能自动生成 commit message，甚至自动 resolve conflict。我也试过，确实省时间。但 Git 的本质不是“怎么操作”，而是 协作契约。
- 一个清晰的 commit history，是给未来自己和队友的礼物；
- 一个规范的分支策略，是避免线上事故的第一道防线；
- 一次认真的 code review，可能就拦住了一个会导致区块链 fork 的 bug。
所以，哪怕我现在偶尔用 Copilot 写个 util 方法，但在 Git 操作上，我还是那个手写 commit message、逐行检查 diff 的老古董。
毕竟，代码可以重写，但 commit 历史一旦污染，就像区块链一样——不可篡改，只能 hard fork。
如果你也在维护一个“既要 Springboot 稳定交付，又要区块链技术尝鲜”的综合项目，希望这些血泪经验能帮你少熬几个夜。
如果觉得有用，欢迎在评论区聊聊你的 Git 翻车现场——让我们一起在“手写代码”的路上，优雅地活下去。
（完）
P.S. 上周终于把双11的事故复盘报告交了，结论第一条：“加强 Git 操作培训”。我默默把本文链接附在了附件里……
评论 0