Git 工作流最佳实践：从独立开发到团队协作
广州的十一月依然带着些许闷热，宿舍里的风扇在头顶慢吞吞地转着。屏幕上的光打在键盘上，终端里正跳动着一行行 git rebase 的进程。
大四了，课表空旷得有些不真实。回想在广州商学院的这四年，很多个这样的夜晚，我都是在这个略显拥挤的四人寝室里，对着一块屏幕敲拭代码。拿了两次国奖，绩点停在 4.02，这些数字听起来或许有些重量，但在技术的世界里，它们不过是过去的切片。真正陪伴我度过漫长开发岁月的，是代码仓库里那一条条交错的分支，和无数个 commit 记录。
在日常开发中，Git 是我们最离不开的工具。但很多人，包括大一大二时的我，对 Git 的使用仅停留在 add、commit、push 这三板斧。那时候写代码像是在孤岛上建房子，Git 对我而言只是一个无限容量的云盘。直到大三那年，第一次参与多人协作的软件工程课设，看着队友一个 git push -f 把我熬夜写了整个周末的模块无情覆盖，我在屏幕前静坐了很久。
那是一种很无力的感觉。从那天起我意识到，写代码是一回事，把代码安全、优雅地融入团队，是另一回事。一旦遇到分支冲突或版本回退就手足无措，是因为我们缺少对工作流的敬畏。这几年在实际项目和实习中，我慢慢摸索并积累了一些 Git 的最佳实践，权当是对过去几年开发习惯的一次整理。
分支策略：从混沌到秩序
以前我们的仓库里总是塞满了 su-test、final-version 这样随意的分支，合并的时候全凭运气。后来才知道，分支管理是有范式的。
Git Flow
Git Flow 是最经典的分支模型。它看起来有些笨重，但对于有明确发版周期的项目来说，它能提供一种令人安心的秩序感。
main ─────────────────────────────────────
\ /
develop ──●───────────────●──
\ /
feature/xxx ─●─────●─
在这个模型里，每条分支都有自己的宿命。
main 分支是生产环境的倒影，它是神圣的，任何人都不应该直接在上面敲击键盘，它只接受来自其他分支的 merge。
develop 是开发主线，像是一个嘈杂但有序的车间，大家把完成的功能陆续合入这里。
而 feature/* 则是每个开发者的自留地。每当有新需求，我会从 develop 拉出一个 feature 分支，在这个平行的宇宙里犯错、重构，直到功能完备，再把它交还给主线。
Trunk-Based Development（主干开发）
后来接触到了一些更现代的团队，CI/CD 的基础设施很完善，Git Flow 就显得有些冗长了。这时候，主干开发成了一种更高效的选择。
# 小批量、高频率提交到 main
git checkout -b feat/small-change
# 几个小时内完成
git checkout main && git merge feat/small-change
不再有长生命周期的功能分支。拉出一个分支，写几个小时的代码，跑通自动化测试，然后迅速合入主干。这种小批量、高频率的提交方式，就像是细水长流，几乎消灭了那种几千行代码合并时带来的心惊肉跳的冲突。它要求开发者把大需求拆解得很细，这也是一种对工程能力的倒逼。
Commit Message 规范：写给未来的信
如果去翻看我大二时的 GitHub 仓库，会看到满屏的 update、fix bug，甚至还有毫无意义的 aaa。那时候觉得只要代码能跑就行，提交信息只是应付 Git 的必填项。
直到有一次，我需要在一个半年前的项目里找一个隐蔽的 bug 引入点。看着那些不知所云的提交记录，我体会到了什么叫“代码是写给人看的，只是恰好能被机器执行”。从那以后，我开始强迫自己使用 Conventional Commits 规范。
feat: 新增用户注册功能
fix: 修复登录页面样式错位
docs: 更新 API 文档
refactor: 重构权限校验逻辑
chore: 升级依赖版本
每次敲下 feat: 或者 refactor: 的时候，其实也是在给自己当下的工作做一个分类和总结。规范的提交历史，让整个仓库变得清晰可读。当团队里的其他人或者几个月后的自己通过 git log 回溯时，这些信息就像是路标，默默指引着方向。
实用技巧：在细节处保持体面
Git 的强大往往藏在那些不那么常用的命令里。掌握它们，能在很多尴尬的场景下保持开发者的体面。
交互式 Rebase
在本地开发时，为了防止代码丢失，我可能会做很多次琐碎的 commit，比如“尝试修复边界条件”、“再改一下文案”、“删掉多余的 console.log”。但如果把这些毫无营养的记录推送到远程，是对代码审查者的折磨。
在推送前，我会习惯性地整理提交历史：
git rebase -i HEAD~3
在弹出的交互式界面里，把后两次提交的 pick 改为 squash。那些琐碎的试错过程被悄无声息地揉进了一个完整的提交里。就像是打扫完房间后再请客人进来，这是一种对协作的尊重。
暂存工作区
这是我在宿舍里最常用的命令之一。有时候正沉浸在一个复杂的 feature 分支里写到一半，室友突然喊我帮他看一个 main 分支上紧急的线上 bug。
手头的代码还没写完，直接 commit 会污染历史，放弃修改又舍不得。这时候 stash 就是最好的避风港。
git stash push -m "临时保存：正在调试的功能"
敲下这行命令，工作区瞬间变得干净。切换到主分支，把 bug 修复完，然后再回到刚才的分支。
git stash list
git stash pop stash@{0}
未完成的代码重新回到屏幕上，就像什么都没发生过一样，思路得以无缝衔接。
Cherry-pick 精准移植
有时候不同分支之间会有一些微妙的交集。比如在 A 分支上顺手修复了一个工具类的拼写错误，而 B 分支正好也需要这个修复，但我并不想把整个 A 分支合并过来。
git cherry-pick abc123
输入那个特定的 commit hash，Git 就像一把精准的手术刀，把那一次修改单独摘取过来，缝合进当前的分支。这种精确控制代码流向的感觉，让人觉得踏实。
尾声
风扇还在转着，终端里的任务已经执行完毕，绿色的提示符安静地闪烁。
在三本院校读软件工程，很多时候是没有人带的，只能自己去碰壁，去翻文档，去开源社区里看别人是怎么做的。好的 Git 实践不仅是技术问题，更是团队协作习惯的体现。规范的分支策略和提交信息，能让代码审查更高效、问题追溯更快速。
大学四年快结束了，带不走宿舍里的任何东西，能带走的只有脑子里的思维方式，和 GitHub 绿色的提交图谱里，那些属于我自己的时间刻度。Git 见证了我从一个人单打独斗，到慢慢学会如何在这个庞大的数字世界里与他人协作。它记录了代码的更迭，也记录了人的成长。