版本控制基础：Git核心概念与工作流
聊FEP计算的版本控制，Git是绕不开的工具。我刚开始接触Git时，觉得它比SVN复杂很多——“不就是个版本管理吗，搞这么复杂干嘛？”直到我真正用起来，才发现自己当初的想法太天真了。
说白了，Git就是给项目拍快照的工具。每次提交都是一张完整的快照。这和SVN那种只记录差异的方式完全不同。你想想看，如果你在项目里改了个参数，想回到三天前的状态，Git可以直接跳到那个快照，速度快得惊人。
Git的三个核心区域
理解Git，必须先搞懂它的三个区域。我见过太多同事在这上面栽跟头。
| 区域 | 作用 | 存放位置 |
|---|---|---|
| 工作区（Working Directory） | 你实际编辑文件的地方 | 本地文件夹 |
| 暂存区（Staging Area / Index） | 下次要提交的文件列表 | .git/index |
| 本地仓库（Local Repository） | 存储所有提交历史的地方 | .git/objects |
每次修改文件，都在这三个区域里转一圈。我有个习惯——提交前一定会用git status看一眼暂存区，确保没有多提交或漏提交东西。
小技巧：我在项目中经常用 git add -p 来分块暂存改动。这样能把一个文件的多次修改拆成不同的提交，让历史记录更干净。
文件状态的生命周期
文件在Git里有四种状态，搞清楚它们，就能理解Git的运作逻辑了。
- 未跟踪（Untracked）：Git不认识的陌生文件
- 已修改（Modified）：文件被改了，但还没加到暂存区
- 已暂存（Staged）：文件在暂存区里，等着被提交
- 已提交（Committed）：文件已经安全地存在本地仓库里了
git status就是用来查看这些状态的。我每天至少跑十几遍这个命令，它快、准、不出错。
分支——平行宇宙
分支是Git最强大的功能之一。我把它理解为“平行宇宙”——你可以同时开发多个功能，互不干扰。
主干分支叫main或master。我习惯用main，感觉更现代一点。功能分支从主干分出来，开发完成后再合并回去。
核心操作命令：
# 创建并切换分支
git checkout -b feature/new-parameter
# 切回主干
git checkout main
# 合并分支
git merge feature/new-parameter
# 删除分支
git branch -d feature/new-parameter我曾经在合并分支时遇到过冲突，改了同一个文件的同一行代码。说实话，那时候挺慌的。后来学会了一个方法——用git mergetool配合可视化工具来解冲突，效率提升不少。
常见的Git工作流
工作流说白了就是团队协作的规矩。没有规矩，项目就会乱成麻。我见过最乱的项目，一个main分支上有20个人同时提交，每天都有冲突。
集中式工作流
适合小团队或单人项目。所有人在同一个main分支上开发。简单直接，但冲突风险高。
功能分支工作流
每个新功能都从main拉出一个独立分支。开发完再合并回去。这样主干永远是干净的。
我个人比较推荐这种方式。在FEP计算项目中，每个参数调优、每个新算法实现，都应该走功能分支。
Git Flow
这是更严格的工作流。有main、develop、feature、release、hotfix五种分支类型。
| 分支类型 | 用途 | 生命周期 |
|---|---|---|
| main | 发布版本 | 长期存在 |
| develop | 开发集成 | 长期存在 |
| feature | 开发新功能 | 开发完成后删除 |
| release | 准备发布 | 发布后合并删除 |
| hotfix | 修复线上Bug | 修复后合并删除 |
Git Flow适合发布节奏固定的大项目。但说实话，对FEP计算这种研究型项目来说，它可能太重了。我个人更推荐功能分支工作流，灵活而且够用。
避坑指南：我曾经在Git Flow里折腾了两个月，最后发现团队根本不需要release分支。每次发布前都要合并两次，麻烦得要命。所以工作流不是越复杂越好，适合团队节奏的才是最好。
远程仓库协作
本地仓库和远程仓库之间，通过remote连接。常见的远程仓库托管平台有GitHub、GitLab、Bitbucket。
基本操作就四个：
# 克隆远程仓库
git clone https://github.com/your-org/fep-project.git
# 拉取最新代码
git pull
# 推送本地提交
git push origin main
# 查看远程信息
git remote -v注意git pull其实是git fetch加git merge的组合命令。我习惯先git fetch看看远程有什么新东西，再决定怎么合并。这样更可控。
Git的底层逻辑——快照与差异
Git存储的是文件快照，不是差异。这是它和SVN最大的区别。每次提交，Git都把当前所有文件的完整副本存下来。可能会觉得这很浪费空间，但其实Git用了对象存储的优化手段——内容相同的文件只存一份。
我刚开始不相信这个说法。写了个测试，把一个大文件改了十个版本，每个版本只改了一行。结果整个仓库的大小只增加了几KB。
为什么会这样？因为Git按内容计算哈希值，内容不变的文件不会重新存储。这就是Git快照机制的聪明之处。既保留了完整版本信息，又不会浪费空间。
学习Git的捷径
想要学好Git，我个人有几个建议：
- 多练：在自己的测试仓库里随便折腾，搞不坏了再说
- 用好
git log：它能看到提交历史，alias一下更好用 - 理解
.gitignore：把编译产物、大型数据文件排除掉，仓库会轻很多 - 提交信息要写清楚：别写“fix bug”这种话，写“修复FEP计算中自由能差符号错误”才有意义
- 学会
git stash：临时切换分支时，没提交的改动可以暂存起来
Git不复杂，复杂的是你对版本管理的理解。搞清楚了它的三个区域、四个状态、分支机制和工作流，Git就是一个很顺手的工具。
图里展示了Git的核心工作流。从工作区到暂存区再到本地仓库，最后推送到远程仓库。右下角展示了文件的四种状态演化。你想想看，只要搞懂了这张图，Git的基本操作就没什么秘密了。