1. 这不是“学个命令”——为什么数据科学新人必须亲手搭起自己的 Git + GitHub 工作流
Git 和 GitHub，对很多刚接触数据科学的朋友来说，常被简化成“存代码的地方”或者“面试要写在简历上的技能”。但我在带过三十多个初学者项目、帮二十多位转行者打磨作品集后发现：真正卡住人的，从来不是
git push
怎么敲，而是根本不知道
该在哪个时间点、用什么逻辑、把哪类文件放进哪个状态里
。比如你训练完一个 LSTM 模型，
.h5
文件该直接
git add
吗？Jupyter Notebook 里混着输出图表和调试日志的单元格，提交前要不要清理？团队协作时，别人改了数据预处理函数，你本地跑不通了，是该
git pull
还是
git fetch && git merge
？这些都不是命令手册能回答的问题，而是每天真实发生的决策。
我见过太多人把整个
model/
目录拖进仓库，结果一次
git push
卡在上传 200MB 的
.pb
文件上；也见过有人把包含个人 API Key 的
config.py
提交到公开仓库，第二天就收到 GitHub 的安全警告邮件；更常见的是，三个人同时改同一个
README.md
，
git pull
后满屏红色冲突，最后干脆删掉重写——所有这些，根源都不在命令不熟，而在
缺乏一套可落地的、贴合数据科学工作节奏的版本控制心法
。这篇教程不讲“Git 是分布式 VCS”，也不复述官网定义。我要带你从零开始，用一个真实的股票预测项目（LSTM+GRU）为线索，手把手拆解：怎么初始化、怎么组织文件、怎么管理模型与数据、怎么分支协作、怎么应对日常报错。每一个命令背后，都解释清楚“为什么这一步不能跳”“如果跳了会埋什么雷”。你不需要记住所有参数，但你会建立起一种肌肉记忆式的判断力：看到某个文件类型，立刻知道它该进 staging 区还是该进
.gitignore
；遇到某个报错，不用百度，先看三秒
git status
就能定位问题层级。这才是新手最该拿走的东西——不是命令列表，而是判断逻辑。
2. 核心设计思路：为什么数据科学项目的 Git 流程必须“反常识”
2.1 普通开发 vs 数据科学：文件性质的根本差异
传统软件开发中，源码是核心资产，二进制文件（如编译后的
.exe
）是产物，通常被排除在版本库外。但数据科学项目里，
代码、数据、模型、可视化结果，四者同等重要且相互强依赖
。一个 Jupyter Notebook 的输出图表（
RNN.png
），直接由
LSTM_GRU.ipynb
中的代码生成，而代码又依赖
data/Mastercard_stock_history.csv
的内容，最终模型权重（
model/LSTM/saved_model.pb
）更是实验结果的终极体现。如果只管代码不管数据，同事 clone 下来根本跑不通；如果把原始 CSV 和模型权重全塞进 Git，仓库体积爆炸，克隆一次就要十分钟。这就是为什么照搬 Web 开发的 Git 流程，在数据科学场景下必然失效。
我的解决方案是： 按文件“可再生性”和“体积敏感度”分层管理 。
-
可再生、小体积
（如
.py脚本、.ipynb、.md文档）：直接纳入 Git，享受完整历史追溯。 -
不可再生、小体积
（如清洗后的
data/cleaned.csv、轻量级配置config.yaml）：纳入 Git，但需确保内容不含敏感信息。 -
不可再生、大体积
（如原始
data/raw/*.csv、模型权重model/*.pb、大型特征矩阵features.npy）： 绝不直接git add，必须用git-lfs或云存储 +.gitignore配合管理。 -
可再生、大体积
（如中间缓存
cache/*.pkl、临时绘图tmp/*.png）：一律加入.gitignore，靠代码重生成。
这个分层不是拍脑袋定的。举个实际例子：
Mastercard_stock_history.csv
原始文件约 12MB，但它是从 Yahoo Finance API 抓取的，只要
download_data.py
脚本存在，随时可重拉。所以它属于“可再生、大体积”，应放入
.gitignore
；而
data/processed/stock_features.csv
是经过标准化、滑动窗口处理后的结果，脚本运行耗时 8 分钟，且每次处理参数微调都会改变结果，属于“不可再生、小体积”，必须进 Git。这种判断，比死记
git add .
重要一百倍。
2.2 GitHub 不是网盘：远程仓库的核心价值在于“协作契约”
很多人把 GitHub 当成免费网盘，建个私有库把所有东西一扔了事。但这样做的后果是：当团队协作时，没人知道谁改了什么、为什么改、改得对不对。GitHub 真正的价值，在于它把 代码变更过程显性化、可审查、可追溯 。Pull Request（PR）不是“提交按钮”，而是 一次微型技术评审 ；Issue 不是“报错单”，而是 需求与问题的公共看板 ；Actions 不是“自动化开关”，而是 质量门禁的强制执行器 。
我在指导一个医疗影像项目时，团队曾因跳过 PR 直接
git push
到 main，导致一个关键的数据增强函数被覆盖，三天后才发现模型指标异常下跌。后来我们立下铁规：所有功能分支（feature branch）必须通过 PR 合并，且 PR 描述必须包含三项：① 修改了什么（如“重构
augment_image()
函数，新增旋转角度随机化”）；② 为什么改（如“原固定角度导致训练集多样性不足，验证集准确率波动超 5%”）；③ 如何验证（如“本地运行
test_augmentation.py
全部通过，新旧函数输出差异在容差范围内”）。这套流程看似多花 2 分钟，但换来的是协作零歧义、回滚有依据、新人上手快。所以本教程中，我会重点演示如何写一个“有信息量”的 PR 描述，而不是教你怎么点那个绿色 Merge 按钮。
2.3 “新手友好”的本质：降低认知负荷，而非简化技术
市面上很多入门教程为了“友好”，会说“先别管原理，照着敲就行”。但 Git 的状态机（Working Directory → Staging Area → Repository）一旦理解偏差，后续所有操作都会变成玄学。比如
git commit
为什么需要先
git add
？因为 Git 的设计哲学是：
提交必须是明确、可控、可复现的快照
。如果你改了 10 个文件，只想提交其中 3 个修复 bug 的，
git add
就是你画出的“本次提交边界线”。跳过这步直接
git commit -a
，等于把所有修改一股脑打包，下次想回滚某个特定修复时，就得在一堆无关变更里大海捞针。
所以本教程的“友好”，体现在：
-
所有命令都配
实时状态图解
（如
git status输出逐行解读）； -
关键操作必给
反例警示
（如“
git add .在数据目录下可能误加 500MB 日志文件”）； -
复杂概念用
生活类比
（Staging Area 就像超市结账台——你把选好的商品（文件）放上去，收银员（
git commit）才给你打小票（生成 commit hash），没放上去的商品（未add的修改）不会出现在小票上）； -
每个步骤都说明
下一步会触发什么连锁反应
（如“执行
git push origin readme:readme后，GitHub 会自动生成 PR 链接，这是你向团队发出的‘请审阅’信号”）。
这不是降低技术门槛，而是把隐性的认知负担，变成显性的、可练习的思维路径。
3. 实操全流程：从零搭建一个可协作的数据科学项目仓库
3.1 环境准备与安全基线：三步筑牢第一道防线
安装 Git 只是起点，真正的安全基线在初始化前就该设好。我见过太多人因为跳过这三步，在后续协作中反复踩坑。
第一步：全局身份认证（必须做，且只能做一次）
打开 PowerShell（Windows）或 Terminal（macOS/Linux），执行：
git config --global user.name "Your Real Name"
git config --global user.email "your.work.email@company.com"
注意：这里必须用 工作邮箱 ，而非 Gmail 或 QQ 邮箱。原因很简单：GitHub 会将 commit 作者邮箱与账户绑定，如果你用私人邮箱，未来换公司时，所有历史 commit 都会显示为“unverified”，影响作品集专业性。另外，
--global参数表示全局生效，避免每个项目重复设置。
第二步：启用自动换行符处理（Windows 用户必做）
git config --global core.autocrlf true
提示：Windows 默认用
CRLF（回车+换行）作为换行符，而 Linux/macOS 用LF（仅换行）。如果不统一，跨平台协作时，git diff会疯狂报“文件末尾多了空行”，实际内容却完全一样。core.autocrlf true表示：检出（checkout）时自动转CRLF，提交（commit）时自动转LF，完美解决此问题。
第三步：创建全局
.gitignore
（一劳永逸）
新建文件
~/.gitignore_global
（Windows 在
C:\Users\YourName\
下），填入：
# 编辑器临时文件
.vscode/
.idea/
*.swp
*.swo
# Python 编译文件
__pycache__/
*.pyc
*.pyo
*.pyd
# Jupyter 笔记本检查点
.ipynb_checkpoints/
# 系统文件
.DS_Store
Thumbs.db
然后执行：
git config --global core.excludesfile ~/.gitignore_global
注意：这步省去你为每个项目手动写
.gitignore的麻烦。比如你用 VSCode，它自动生成的.vscode/目录，从此再也不会意外进入你的仓库。
完成这三步后，执行
git config --list
，确认输出中包含你的 name、email 和
core.excludesfile
路径。少一个，后续协作就可能出乱子。
3.2 仓库初始化：两种路径，一个原则
创建仓库有两种典型场景：① 从零开始新项目；② 为已有项目接入版本控制。无论哪种，核心原则只有一个： 本地仓库（.git）必须与远程仓库（GitHub）建立明确、可追溯的连接 。
场景①：全新项目（推荐 GUI 创建 + CLI 克隆）
-
登录 GitHub，点击右上角
+→New repository； -
填写
Repository name（如stock-prediction-lstm）， 务必勾选Add a README file（这是初始化信任的第一步，让协作者一眼看到项目目标）； -
点击
Create repository； - 回到本地 PowerShell，执行：
git clone https://github.com/your-username/stock-prediction-lstm.git
cd stock-prediction-lstm
为什么不用
git init？因为git clone会自动完成三件事：① 创建本地目录；② 初始化.git；③ 添加远程地址origin指向 GitHub。手动init后还要git remote add origin ...，多一步就多一个出错点。
场景②：已有项目接入（
git init
+
git remote add
）
假设你已有一个本地文件夹
C:\projects\lstm-stock
，内含
data/
,
notebooks/
,
models/
：
cd C:\projects\lstm-stock
git init
git remote add origin https://github.com/your-username/stock-prediction-lstm.git
关键动作：
git remote add后，立即执行git remote -v，确认输出为：
origin https://github.com/your-username/stock-prediction-lstm.git (fetch)
origin https://github.com/your-username/stock-prediction-lstm.git (push)
如果只有(fetch)没有(push)，说明推送权限未配置，后续git push必失败。
无论哪种路径，初始化后第一件事：
创建并提交
.gitignore
。
# 创建 .gitignore 文件
echo "data/raw/" > .gitignore
echo "model/" >> .gitignore
echo "__pycache__/" >> .gitignore
git add .gitignore
git commit -m "chore: add .gitignore for raw data and models"
注意：
data/raw/和model/是数据科学项目最常误提交的两个目录。提前写入.gitignore，比事后git rm -r --cached model/再git commit省心十倍。
3.3 文件管理实战：哪些该进 Git，哪些该绕道走？
以本教程的 MasterCard 股票项目为例，我们来逐类分析文件处理逻辑。这不是理论，而是我每天在 JupyterLab 里真实执行的操作流。
① Jupyter Notebook（
.ipynb
）：清理再提交
Notebook 里常混着：
- 代码（必须保留）；
-
输出图表（
RNN.png，可再生，应删除）； -
调试日志（
print("Step 1 done")，污染历史，应删除）； -
大型变量（
df = pd.read_csv(...)加载的 DataFrame，占内存，不应保存）。
正确做法：
-
在 JupyterLab 中，菜单栏
Edit→Clear All Outputs； -
执行
Cell→All Output→Clear； -
手动删除所有
print()和logging.info()调试语句； - 保存 Notebook；
- 执行：
git add LSTM_GRU.ipynb
git commit -m "feat: add LSTM and GRU training notebook (outputs cleared)"
提示：永远不要提交带输出的 Notebook。否则
git diff会显示数千行 JSON 差异，完全无法阅读。jupyter nbconvert --clear-output可批量清理，但手动清更可控。
② 数据文件（
.csv
,
.json
）：按来源分级
-
data/raw/Mastercard_stock_history.csv（12MB）： 绝对不进 Git 。在.gitignore中已声明data/raw/，确保git status不显示它。 -
data/processed/stock_features.csv（1.2MB）： 必须进 Git 。这是清洗、特征工程后的结果，是实验可复现的关键。执行：
git add data/processed/stock_features.csv
git commit -m "data: add processed features for LSTM training"
计算依据：1.2MB 在 Git 可接受范围（GitHub 推荐单文件 < 100MB）。若处理后仍超 5MB，考虑用
git-lfs track "data/processed/*.csv"启用 LFS。
③ 模型文件（
.h5
,
.pb
）：LFS 是唯一正解
model/LSTM/saved_model.pb
体积约 85MB，直接
git add
会导致：
- 仓库体积膨胀，克隆变慢；
-
每次
git pull都要下载 85MB，浪费带宽； - GitHub 会警告 “Large files detected”。
正确方案：启用 Git LFS（Large File Storage）：
# 1. 安装 LFS（首次）
git lfs install
# 2. 声明跟踪模式（针对模型文件）
git lfs track "model/**/*"
git lfs track "data/raw/**/*"
# 3. 提交 .gitattributes（LFS 的配置文件）
git add .gitattributes
git commit -m "chore: enable git-lfs for model and raw data"
# 4. 现在可以安全添加模型
git add model/
git commit -m "model: add trained LSTM and GRU weights"
git push origin main
注意：
git lfs track会生成.gitattributes文件，它告诉 Git “这些文件用 LFS 存储，只在本地存指针”。git push时，LFS 会自动将大文件上传到 GitHub 的 LFS 服务器，Git 仓库里只留一个轻量指针。这是数据科学项目的标配，没有例外。
④ 文档与配置（
.md
,
.yaml
）：结构化即生产力
README.md
不是装饰品，而是项目的“首页说明书”。我坚持的结构是：
# Stock Prediction with LSTM/GRU
## 🎯 Goal
Predict MasterCard stock price using time-series models. Target: MAE < $2.5.
## 📁 Structure
- `notebooks/`: Training & evaluation notebooks
- `data/processed/`: Clean, feature-engineered CSVs
- `models/`: Trained weights (via LFS)
- `src/`: Reusable Python modules
## ⚙️ Setup
```bash
pip install -r requirements.txt
python src/download_data.py # Fetches raw data to data/raw/
🚀 Quick Start
jupyter lab # Open notebooks/LSTM_GRU.ipynb
> 提示：每次 `git commit` 前，用 `git diff README.md` 快速检查文档是否同步更新。文档滞后，是协作效率的最大杀手。
### 3.4 分支协作：从“改 README”开始理解团队工作流
很多新手以为分支（branch）是高级功能，其实它最基础的应用就是：**隔离不同目标的修改，避免互相干扰**。我们以“完善项目文档”为例，走一遍标准流程。
**第一步：创建特性分支（Feature Branch）**
```bash
git checkout -b docs/readme-update
为什么叫
docs/readme-update而非readme？因为分支名要体现 领域（docs）+ 动作（update）+ 目标（readme） 。这样git branch列表一目了然，避免feature1,temp-fix这类无意义命名。
第二步：修改并提交（在特性分支上）
编辑
README.md
，增加项目背景、数据来源说明、模型评估指标。保存后：
git add README.md
git commit -m "docs: add project background, data source, and eval metrics"
注意：此时
git log只显示这个 commit，main分支完全不受影响。这就是分支的核心价值——你的修改是沙盒里的，不影响主干。
第三步：推送到远程并创建 PR
git push origin docs/readme-update
执行后，GitHub 会自动检测到新分支，并在仓库页面显示 “Compare & pull request” 按钮。点击它，进入 PR 创建页。
第四步：撰写高信息量 PR 描述（关键！）
在 GitHub PR 页面，填写：
-
Title
:
docs: enhance README with background, data source, and eval metrics -
Description
:
## What's changed? - Added project background section explaining the business context of stock prediction - Specified data source: Yahoo Finance API, with link to official docs - Defined evaluation metrics: MAE, RMSE, and target thresholds (MAE < $2.5) ## Why this matters? New contributors can now understand the project goal without reading code. Data source transparency helps reproduce results. Clear metrics enable objective model comparison. ## How to verify? 1. View rendered README on GitHub 2. Check all links resolve correctly 3. Confirm metrics match those reported in LSTM_GRU.ipynb output
提示：这个描述模板（What/Why/How）是我带团队时强制要求的。它让 Reviewer 30 秒内抓住重点，而不是问“你改这儿干啥？”。
第五步：合并与清理
PR 被批准后，点击
Merge pull request
→
Confirm merge
。合并完成后，
立即清理本地和远程分支
：
git checkout main
git pull origin main
git branch -d docs/readme-update
git push origin --delete docs/readme-update
注意：
git branch -d是安全删除（只删已合并的），git branch -D是强制删除（慎用）。删除已合并分支，是保持仓库清爽的铁律。
3.5 日常维护：
git status
是你的每日晨会
很多新手忽略
git status
，直到
git push
失败才打开它。但其实，
git status
是 Git 工作流的“仪表盘”，每天开工第一件事就该看它
。我把它拆解成三个必查区：
① “On branch X” —— 你在哪条路上？
输出首行
On branch main
是安全的；如果是
On branch feature/login
，而你本意是修 bug，说明你切错了分支，立刻
git checkout main
。
② “Changes not staged for commit” —— 哪些修改还没圈进本次提交？
例如：
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: notebooks/LSTM_GRU.ipynb
modified: src/data_loader.py
这意味着你改了两个文件，但只打算提交其中一个。此时必须决定：这两个修改是否属于同一逻辑单元？如果是（如“修复数据加载 bug”），就
git add两者；如果不是，就git restore src/data_loader.py暂存当前修改，专注处理notebooks/。
③ “Untracked files” —— 哪些新文件还没被 Git 知道？
例如：
Untracked files:
(use "git add <file>..." to include in what will be committed)
data/raw/Mastercard_stock_history.csv
model/LSTM/
这是危险信号！如果
data/raw/出现在这里，说明.gitignore没生效（检查路径是否拼写错误）；如果model/LSTM/出现，说明你忘了git lfs track。必须立即处理，否则下一秒git add .就会酿成大祸。
我养成的习惯是：每天打开终端第一件事，
git status
；每次写完一段代码，
git status
；每次
git push
前，
git status
。三秒钟，换来的是一整天的心安。
4. 常见问题与排查技巧实录：那些让我熬夜的报错，现在你都能秒解
4.1 “fatal: refusing to merge unrelated histories” —— 新手克隆后
git pull
就崩？
现象
：你用
git clone
下载了一个空仓库（如教程中的
DataCamp-Git
），然后本地写了
README.md
并
git commit
，接着
git pull origin main
，报错：
fatal: refusing to merge unrelated histories
原因
：
git pull
=
git fetch
+
git merge
。而
git clone
下来的空仓库，其
main
分支没有任何 commit（history 为空）；你本地
git commit
生成的 commit，其父节点是
null
，与远程
main
的空 history 完全不相交。Git 拒绝合并“毫无关系”的两条时间线。
解决方案（二选一） ：
-
推荐
：用
git push --set-upstream origin main强制推送本地 commit，覆盖远程空分支：git push --set-upstream origin main # 后续 git pull 自动识别上游 -
备选
：
git pull origin main --allow-unrelated-histories（不推荐，掩盖设计问题）。
实操心得：这个报错本质是“你试图把两个独立项目强行合并”。正确做法永远是： 先推自己的初始 commit，再让别人基于它协作 。记住口诀：“空仓不 pull，先 push 再合作”。
4.2 “Updates were rejected because the remote contains work that you do not have locally” ——
git push
被拒？
现象
：你
git commit
后
git push
，报错：
! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/...'
hint: Updates were rejected because the remote contains work that you do not have locally.
原因
：远程
main
分支有你本地没有的 commit（比如同事刚
push
了新代码）。Git 要求
push
必须是 fast-forward（即你的本地
main
是远程
main
的直接后代），否则拒绝。
解决方案（按优先级排序） ：
-
首选
git pull --rebase（保持线性历史）：git pull --rebase origin main # 如果有冲突，解决后 git add . && git rebase --continue git push origin main -
次选
git pull（默认 merge） ：git pull origin main # 自动生成 merge commit，历史呈分叉状 git push origin main -
禁止
git push --force（除非你 100% 确认要覆盖他人工作）。
注意：
--rebase的优势是历史干净（所有你的 commit 都排在最新版之后），适合个人项目；pull的 merge 方式更直观，适合团队明确要求保留协作痕迹的场景。我建议新手从pull开始，熟悉后再用rebase。
4.3 “The following untracked working tree files would be overwritten by merge” ——
git pull
时提示文件冲突？
现象
：
git pull
报错：
error: The following untracked working tree files would be overwritten by merge:
data/processed/stock_features.csv
Please move or remove them before you merge.
原因
：你本地有
data/processed/stock_features.csv
，但它不在 Git 管理中（
git status
显示为 Untracked），而远程
main
分支里这个文件已被
git add
并提交。Git 担心
pull
会覆盖你本地的“脏”文件。
解决方案 ：
-
如果本地文件是旧的、可丢弃的
：
git clean -f data/processed/stock_features.csv git pull origin main -
如果本地文件是新的、重要的
（如你刚生成的最新特征）：
git add data/processed/stock_features.csv # 先纳入 Git 管理 git commit -m "data: add latest processed features" git pull origin main # 此时会触发真正的 merge 冲突，按提示解决
提示：
git clean -f是删除未跟踪文件的命令，-f是强制（必须加，否则无效）。永远先git status确认要删的文件，再执行clean。
4.4 “remote: error: GH001: Large files detected” —— GitHub 拒绝大文件？
现象
：
git push
时，GitHub 返回：
remote: error: GH001: Large files detected.
remote: error: Trace: xxxxxxxx
remote: error: See http://git.io/iEPt8g for more information.
原因 ：你尝试推送的文件超过 100MB（GitHub 硬限制），且未启用 LFS。
排查与解决 ：
-
查看具体是哪个大文件：
git ls-files -s | grep "100[0-9]\{6,\}" # 或用第三方工具：git-sizer（推荐） -
如果是模型/数据等
必须的大文件
：
git lfs install git lfs track "model/**/*" git add .gitattributes git commit -m "chore: add .gitattributes for LFS" git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch model/**/*' \ --prune-empty --tag-name-filter cat -- --all git push origin --force --all git push origin --force --tags git push origin main -
如果是
不该存在的大文件
（如
data/raw/*.zip）：git rm --cached data/raw/large_file.zip echo "data/raw/large_file.zip" >> .gitignore git add .gitignore git commit -m "chore: remove large zip from repo, add to ignore" git push origin main
注意：
git filter-branch会重写历史，影响所有协作者。执行前务必通知团队，并确保所有人git pull --rebase更新。生产环境建议用git filter-repo（更安全）替代。
4.5 “Your branch is ahead of 'origin/main' by X commits” ——
git status
显示“ahead”却
git push
不了？
现象
：
git status
显示：
On branch main
Your branch is ahead of 'origin/main' by 2 commits.
(use "git push" to publish your local commits)
但执行
git push
后，报错
No configured push destination
。
原因
：你的本地
main
分支没有设置上游（upstream）分支。
git push
默认推送到
origin/main
，但
origin/main
不存在（可能远程分支名是
master
，或你从未
git push --set-upstream
）。
解决方案 ：
git push --set-upstream origin main
# 或简写
git push -u origin main
提示：
-u（--set-upstream）只需执行一次。之后git push和git pull会自动关联origin/main。这是新手最容易忽略的“一次性配置”，务必养成习惯。
5. 经验沉淀：那些没写在文档里，但让我少熬 200 小时的硬核技巧
5.1 “三分钟应急法”：当
git
命令全忘光时，靠这三步自救
我带新人时总强调：Git 命令可以忘，但 状态意识不能丢 。当你面对满屏报错不知所措，立刻执行这三步：
-
git status：看当前分支、未暂存/未提交/未跟踪文件。这是所有决策的起点。 -
git log --oneline -n 5：看最近 5 个 commit，确认你“退回到哪里是安全的”。 -
git reflog：看所有操作历史（包括reset、checkout等“不可逆”操作），找到你想回到的那个 HEAD。
举个实例：你不小心
git reset --hard HEAD~2删除了两个 commit，git log看不到了。但git reflog会显示：
abc1234 HEAD@{0}: reset: moving to HEAD~2
def5678 HEAD@{1}: commit: add model evaluation metrics
ghi9012 HEAD@{2}: commit: fix data loader bug
此时git reset --hard HEAD@{2}就能瞬间找回。reflog是 Git 最强大的后悔药，但只在本地有效，且默认保留 30 天。
5.2
.gitignore
的黄金法则：五类文件必须屏蔽
很多新手
.gitignore
写得随意，导致仓库混乱。我总结的“五必须”是：
| 类别 | 示例 | 为什么必须屏蔽 |
|---|---|---|
| 编辑器临时文件 |
.vscode/
,
.idea/
,
*.swp
| 与个人开发环境强绑定，协作者无需也不应拥有 |
| Python 编译产物 |
__pycache__/
,
*.pyc
,
*.pyo
|
由源码自动生成，体积小但数量多，污染
git status
|
| Jupyter 检查点 |
.ipynb_checkpoints/
| 自动保存的临时副本，无业务价值，易引发冲突 |
| 操作系统元数据 |
.DS_Store
(macOS),
Thumbs.db
(Windows)
| 系统自动生成，纯属噪音 |
| 数据科学专属 |
data/raw/
,
model/
,
cache/
,
logs/
| 体积大、可再生、含敏感信息，必须用 LFS 或外部存储 |
提示：用
git check-ignore -v filename可验证某文件是否被.gitignore正确捕获。例如git check-ignore -v data/raw/stock.csv应输出匹配的.gitignore规则行。
5.3 为数据科学定制的
git alias
：把高频操作压缩成一个词
Git 支持自定义别名，我把最常用的五个封装成“数据科学快捷键”：
git config --global alias.st "status -s" # git st → 简洁状态
git config --global alias.ci "commit -m" # git ci "msg" → 快速提交
git config --global alias.co "checkout" # git co branch → 切换分支
git config --global alias.br "branch --format='%(HEAD) %(name)'" # git br → 清晰分支列表
git config --global alias.lg "log --graph --oneline --all --simplify-by-decoration" # git lg → 可视化
扫一扫
886
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
