my_meeting/Git版本控制入门.md

280 lines
5.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Git 版本控制入门
这份文档是给当前项目准备的 Git 使用速查,适合从“手动打压缩包备份”过渡到“用 Git 管理版本”。
## Git 是什么
Git 可以理解成一个更聪明的项目快照系统。
和手动保存 `xxx_final.zip`、`xxx_最终版.zip` 相比Git 可以:
- 记录每次修改
- 给每次修改写说明
- 查看具体改了哪些文件、哪几行
- 随时回退到任意历史版本
- 开分支做实验,不影响主线
- 配合 GitHub / GitLab 做远程备份
## 第一次开始使用
### 1. 确认已经安装 Git
在终端执行:
```bash
git --version
```
如果能看到版本号,说明已经安装完成。
### 2. 进入项目目录
例如当前项目:
```bash
cd d:\github_project\meeting
```
### 3. 初始化 Git 仓库
```bash
git init
```
执行后,项目根目录会出现一个 `.git` 目录,用来保存版本历史。
### 4. 配置用户名和邮箱
这一步通常只需要做一次:
```bash
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
```
### 5. 创建 `.gitignore`
`.gitignore` 用来告诉 Git 哪些文件不需要纳入版本控制,比如缓存、临时文件、依赖目录、构建产物等。
常见示例:
```gitignore
__pycache__/
*.pyc
.venv/
node_modules/
dist/
build/
.env
```
### 6. 进行第一次提交
```bash
git add .
git commit -m "初始提交"
```
这一步相当于把当前项目拍了一张“可追踪的快照”。
## 日常最小工作流
平时开发时,建议按下面顺序操作:
### 1. 写代码
完成一个小功能、一个修复,或者一组相关修改。
### 2. 查看当前状态
```bash
git status
```
这个命令会告诉你:
- 哪些文件被修改了
- 哪些文件还没加入暂存区
- 哪些文件准备提交
### 3. 查看具体改了什么
```bash
git diff
```
如果你已经执行过 `git add`,想看暂存区里的内容,可以用:
```bash
git diff --cached
```
### 4. 添加到暂存区
添加所有改动:
```bash
git add .
```
如果你只想提交某一个文件:
```bash
git add 文件名
```
### 5. 提交一个版本
```bash
git commit -m "修复会议摘要生成错误"
```
建议提交说明写清楚“这次做了什么”,以后回看会非常省心。
## 最常用命令速查
```bash
git init
git status
git diff
git diff --cached
git add .
git add 文件名
git commit -m "提交说明"
git log --oneline
git checkout -b 新分支名
```
各命令含义:
- `git init`:初始化仓库
- `git status`:查看当前状态
- `git diff`:查看未暂存的改动
- `git diff --cached`:查看已暂存但未提交的改动
- `git add .`:把当前目录中的改动加入暂存区
- `git commit -m "说明"`:提交一个版本
- `git log --oneline`:简洁查看提交历史
- `git checkout -b 新分支名`:创建并切换到新分支
## 什么时候提交比较合适
推荐在下面这些时机提交:
- 完成一个小功能
- 修复一个明确的问题
- 做完一次重构
- 修改前先做一次提交,方便之后回退
不建议把很多不相关的改动堆到一次提交里。
## 提交说明怎么写
尽量写得具体一点,避免只写“修改”“更新”“调整”。
好的例子:
- `初始化会议摘要脚本`
- `修复提示词加载路径错误`
- `新增前端导出 Markdown 功能`
- `优化配置文件读取逻辑`
不太好的例子:
- `修改`
- `更新`
- `test`
- `111`
## 查看历史版本
查看提交历史:
```bash
git log --oneline
```
你会看到类似:
```text
abc1234 修复会议摘要生成错误
def5678 初始提交
```
前面的短串是提交 ID可以用来定位历史版本。
## 分支有什么用
如果你想尝试一个新功能,但又怕把当前稳定版本改坏,可以新建分支:
```bash
git checkout -b new-feature
```
这样你就在一个独立分支里开发,主线不会受影响。
等实验成功后,再考虑合并回主分支。
## Git 和压缩包备份的区别
你以前的方式:
- 手动复制项目
- 手动压缩
- 手动命名
- 很难看出两个版本之间具体差了什么
Git 的方式:
- 自动记录版本历史
- 可以精确查看每次改动
- 不需要保存一堆重复压缩包
- 回退、对比、分支都更方便
## 给新手的几个重要提醒
### 1. Git 不是自动保存
你必须执行 `git commit`,这次版本才会进入历史记录。
### 2. 先学最常用的几个命令就够了
先熟悉这些:
- `git status`
- `git diff`
- `git add`
- `git commit`
- `git log --oneline`
### 3. 不要把不该提交的东西也提交进去
例如:
- 虚拟环境
- 缓存文件
- 构建产物
- 私密配置
这些应该放进 `.gitignore`
## 推荐你现在就用的流程
如果你的项目已经开始用 Git之后每次开发可以直接按这个顺序走
```bash
git status
git diff
git add .
git commit -m "这次修改的内容"
```
例如:
```bash
git add .
git commit -m "优化会议摘要输出格式"
```
## 一句话总结
压缩包备份适合偶尔存档Git 更适合持续开发。
如果你经常改代码、修问题、加功能,用 Git 会比手动打压缩包轻松很多,也安全很多。