4、Git基础操作(一):安装与配置、创建仓库、提交(commit)、查看历史(log)
好,咱们正式开始动手了。前面几章聊了版本管理为什么重要,也讲了 Git 的核心概念。这一章,咱们直接上机操作。你想想看,光学设计文件动辄几十兆,一个镜头结构改了又改,没有 Git 管着,迟早要出乱子。
我个人习惯,学任何工具都先搭好环境,再跑通最基础的那几个命令。Git 的基础操作其实就三板斧:装好、配好、提交一次看看。今天咱们就把这三板斧练熟。
本章核心目标:完成 Git 的安装与基础配置,创建第一个仓库,成功提交一次文件,并学会查看提交历史。
4.1 安装 Git:选对版本,少踩坑
Git 的安装其实不复杂,但不同操作系统有点小区别。我在项目中遇到过好几次,有人装了过时的版本,结果后面合并分支时各种报错。所以,版本很重要。
4.1.1 Windows 环境
- 去 Git 官网下载安装包,选 64-bit Git for Windows Setup。
- 安装时,大部分选项保持默认就行。但有一个地方我建议你改一下:
在 Choosing the default editor 这一步,默认是 Vim。如果你不熟悉 Vim,建议选 Nano 或者 Notepad++。不然你第一次提交时写注释,可能会卡在 Vim 里不知道怎么退出。 - 安装完成后,打开 Git Bash,输入
git --version验证。
4.1.2 macOS 环境
- macOS 可能自带了一个旧版 Git。我建议用 Homebrew 安装新版:
brew install git - 装完同样检查版本:
git --version。
4.1.3 Linux 环境
- Ubuntu/Debian:
sudo apt install git - CentOS/RHEL:
sudo yum install git
我的建议:尽量用 2.x 以上版本。2.23 版本之后引入了 git switch 和 git restore,比老版的 checkout 更直观。光学设计团队协作时,这些新命令能减少误操作。
4.2 第一次配置:告诉 Git 你是谁
装好 Git 之后,第一件事不是急着建仓库,而是配置身份。为什么?因为每次提交,Git 都会记录是谁做的修改。你想想看,如果团队里所有人都显示 "Unknown",那历史记录还有什么用?
配置分三个层级:系统级(system)、全局级(global)、仓库级(local)。咱们先配全局的,这样以后所有仓库都默认用这个身份。
# 配置用户名和邮箱(全局)
git config --global user.name "Zhang Wei"
git config --global user.email "zhangwei@optical.com"
# 查看配置
git config --list
我曾经犯过一个错:在公司电脑上配了个人邮箱,结果提交记录里邮箱是乱的,后面追溯时费了好大劲才改回来。所以,建议你一开始就分清楚:工作项目用公司邮箱,个人项目用私人邮箱。
| 配置层级 | 作用范围 | 配置命令 | 优先级 |
|---|---|---|---|
| system | 整个操作系统所有用户 | git config --system |
最低 |
| global | 当前用户的所有仓库 | git config --global |
中 |
| local | 当前仓库 | git config --local |
最高 |
注意:邮箱配置错了,提交历史里就会留下错误信息。虽然可以修改,但会影响到团队其他人的历史。最好一次配对。
4.3 创建仓库:让 Git 开始管你的文件
配置好了,接下来就是让 Git 接管你的项目。说白了,就是在一个文件夹里执行 git init,Git 就会在这个文件夹里创建一个隐藏的 .git 目录,所有版本信息都存在里面。
咱们模拟一个光学设计场景:你正在设计一个手机镜头,项目文件夹叫 phone_lens_v2。
# 创建项目文件夹
mkdir phone_lens_v2
cd phone_lens_v2
# 初始化 Git 仓库
git init
# 查看仓库状态
git status
执行 git status 后,你会看到类似这样的输出:
On branch master
No commits yet
nothing to commit (create/copy files and use "git add" to track)
嗯,这里要注意:Git 告诉你现在在 master 分支上,还没有任何提交。这就是一个空仓库的状态。
4.4 第一次提交:把文件交给 Git 管理
仓库建好了,但里面是空的。咱们得放点文件进去。假设你写了一个光学设计说明文件 design_notes.md,还有一份初始的 Zemax 文件 lens_initial.zmx。
Git 的提交分两步:暂存(add) 和 提交(commit)。为什么分两步?因为有时候你改了好几个文件,但只想把其中一部分提交,另一部分继续改。暂存区就是给你一个挑选的机会。
# 创建两个示例文件
echo "# Phone Lens Design v2" > design_notes.md
echo "Lens data placeholder" > lens_initial.zmx
# 把文件加入暂存区
git add design_notes.md
git add lens_initial.zmx
# 或者一次性添加所有改动
git add .
# 提交到仓库
git commit -m "feat: 初始化手机镜头v2项目,添加设计说明和初始镜头文件"
提交成功后,你会看到类似:
[master (root-commit) a1b2c3d] feat: 初始化手机镜头v2项目,添加设计说明和初始镜头文件
2 files changed, 2 insertions(+)
create mode 100644 design_notes.md
create mode 100644 lens_initial.zmx
这里 a1b2c3d 就是这次提交的唯一标识(SHA-1 哈希值的前7位)。以后你要回退到这次提交,就靠它了。
提交信息怎么写? 我建议用 约定式提交 的格式:类型: 简短描述。比如 feat: 表示新功能,fix: 表示修bug,docs: 表示文档更新。这样看历史记录时一目了然。
4.5 查看历史:看看你都干了什么
提交了几次之后,自然想看看之前都改过什么。这时候 git log 就派上用场了。
咱们再提交两次,模拟真实开发过程:
# 第二次提交:修改设计说明
echo "Updated: added initial MTF target" >> design_notes.md
git add design_notes.md
git commit -m "feat: 更新设计说明,添加MTF目标值"
# 第三次提交:添加公差分析文件
echo "Tolerance data" > tolerance_analysis.zmx
git add tolerance_analysis.zmx
git commit -m "feat: 添加公差分析初始文件"
现在查看历史:
git log
输出大概是这样:
commit c6d7e8f (HEAD -> master)
Author: Zhang Wei <zhangwei@optical.com>
Date: Mon Mar 10 14:30:00 2025 +0800
feat: 添加公差分析初始文件
commit b2c3d4e
Author: Zhang Wei <zhangwei@optical.com>
Date: Mon Mar 10 14:25:00 2025 +0800
feat: 更新设计说明,添加MTF目标值
commit a1b2c3d
Author: Zhang Wei <zhangwei@optical.com>
Date: Mon Mar 10 14:20:00 2025 +0800
feat: 初始化手机镜头v2项目,添加设计说明和初始镜头文件
你看,最新的提交在最上面。每次提交都有完整的作者、时间、描述。这就是 Git 给你留下的「开发日记」。
我个人常用的几个 log 参数:
git log --oneline:只看一行摘要,适合快速浏览。git log --graph:显示分支图,后面讲分支时会用到。git log -p:显示每次提交的具体改动内容,适合代码审查。
避坑指南:我曾经在项目里提交了一个几百兆的 Zemax 文件,结果仓库变得巨大无比。后来才知道,二进制文件(.zmx、.pdf、.exe)不适合用 Git 管理。Git 擅长管理文本文件,二进制文件每次修改都会存一份完整副本。建议用 .gitignore 把大文件排除在外,这个咱们后面会讲。
4.6 本章知识结构图
下面这张图帮你理清 Git 基础操作的流程:
4.7 本章小结
咱们这一章把 Git 最基础的操作过了一遍。你学会了:
- 在不同系统上安装 Git
- 配置用户名和邮箱
- 用
git init创建仓库 - 用
git add和git commit提交文件 - 用
git log查看提交历史
这些操作看起来简单,但它们是 Git 所有高级功能的基础。你想想看,分支、合并、回退,本质上都是在操作这些提交记录。基础打牢了,后面学什么都快。
练习建议:找个你正在做的光学设计项目,建一个 Git 仓库,把设计文档和初始镜头文件提交进去。然后改几次文件,每次提交都写清楚注释。一周后你再回头看 git log,你会感谢自己当初做了这件事。