一些需要了解的先验知识

VS Code 的源代码管理主要依赖于 Git。它的可视化界面非常友好，能让你免去敲击繁琐命令的烦恼。特别是省去了在终端使用cmd指令构建git项目和上传到github，以及使用github desktop需要在最开始就创建项目并且后续不直观展示项目git流程的缺点。

使用源代码管理的目的在于：

• 多人协作完成一个庞大的项目。
• 实验过程中出现尝试，失败之后需要回退。

---

第 0 步：准备工作

在开始之前，请确保你的电脑上已经安装了 Git。
VS Code 本身不自带 Git，它只是调用你电脑上的 Git 程序。如果你还没安装，请先去 Git 官网 下载并安装。安装完成后，重启 VS Code。

第 1 步：初始化仓库（让 Git 开始接管代码）

如果你新建了一个项目文件夹，Git 默认是不知道它的存在的。我们需要让 Git 开始“盯着”这个文件夹。

1. 在 VS Code 中打开你的项目文件夹。
2. 点击左侧活动栏中的 “源代码管理” 图标（图标看起来像是一个分支的节点，通常是第三个）。
3. 如果这是一个新项目，你会看到一个蓝色的按钮写着 “初始化仓库” (Initialize Repository)。点击它。
4. 现在，这个文件夹就变成了一个 Git 仓库。

注意！新手可能会误解初始化仓库就是将本地的这个项目传递到GitHub上，这是不正确的。git的功能是在本地建立快照，而上传到github的本质是将快照上传到github的存储的位置。

第 2 步：认识“更改”面板

当你在项目中新建、修改或删除文件并保存后，点击源代码管理图标，你会看到文件出现在列表中。
文件右侧通常会有一些字母提示它们的状态：

• U (Untracked - 未跟踪): 你新建的文件，Git 以前没见过。
• M (Modified - 已修改): 以前提交过的文件，你刚刚修改了它。
• D (Deleted - 已删除): 你刚刚删除了的文件。

如果你点击列表中的某个文件，VS Code 会打开一个左右对比的视图，左边是旧版本，右边是你修改后的新版本，哪里改动了一目了然。

第 3 步：暂存更改（Add）

在 Git 的逻辑里，修改了文件并不代表要立刻保存到历史记录中。你需要先挑出这次想要保存的改动，放到“暂存区”。

• 暂存单个文件： 鼠标悬停在某个文件上，点击右侧出现的 + (暂存更改) 号。
• 暂存所有文件： 鼠标悬停在“更改 (Changes)”这个分类标题上，点击右侧的 + 号。

此时，文件会从“更改”列表移动到 “暂存的更改” (Staged Changes) 列表中。

例如：

第 4 步：提交更改（Commit）

暂存之后，我们就可以正式把这些改动打包成一个“版本快照”了。

1. 在源代码管理面板顶部的文本框中，输入 提交信息 (Commit Message)。简单描述一下你这次做了什么（例如：“新增了用户登录功能” 或 “修复了首页排版错位”）。
2. 点击文本框下方的 “提交” (Commit) 按钮。
3. 提交成功后，面板会被清空，说明你当前的工作区非常干净，所有改动都已安全保存到本地历史记录中。

注意，git的步骤严格遵守： 修改 -> 添加 -> 增加描述性信息 -> 上传到本地 -> 上传到github（可选）

第 5 步：与远程仓库同步（Push/Pull）

如果你在用 GitHub 或 GitLab，你需要把本地的代码推送到云端。

• 发布分支： 如果你是第一次把本地仓库推送到云端，面板上会有一个 “发布 Branch” (Publish Branch) 按钮。点击它，VS Code 会引导你登录 GitHub 并自动帮你创建一个云端仓库。
• 同步更改： 如果你已经连接了远程仓库，每次提交后，你会看到一个 “同步更改” (Sync Changes) 按钮。点击它，VS Code 会自动帮你把云端的新代码拉取下来（Pull），并把你的新提交推送到云端（Push）。

---

总结一下核心日常流程就是：
修改文件 -> 点击 + 暂存 -> 写描述并点击“提交” -> 点击“同步更改”。

Git Graph插件

一定要在vscode里面下载这个插件，这对后续reset 、rebase、delect等操作非常方便，也可以更加直观的显示树的分支。

认识分支

你可以先阅读一下这个部分的内容，了解一下是什么，后面会展示如何建立一个初始库并进行一些操作。

你可以把“分支”想象成平行宇宙。在主宇宙（通常是 main 分支）里，一切都在稳定运行；而在平行宇宙（你创建的新分支）里，你可以肆意搞破坏、做实验，完全不会影响到主宇宙。

什么时候使用分支？

核心原则是：只要你想做一些可能破坏现有代码库稳定性的事情，就新建一个分支。

以下是几个最常见的使用场景：

1. 开发新功能（Feature）： 假设你的 main 分支里存放着你目前整理好的、结构清晰的量化交易与市场学习笔记，或者是一个能跑通的基础回测代码。现在你想尝试加入一个全新的模块——比如引入 LightGBM 模型来预测股票收益率，或者测试一种新的自定义损失函数。这个时候你就应该建一个名为 feature/lightgbm-test 的分支。在这个分支上怎么改都不会影响 main，等模型跑通了，再合并回去。
2. 修复 Bug（Hotfix）： 代码突然跑不通了，你需要紧急修复。你可以从 main 创建一个 fix/data-bug 分支，修好后再合并。
3. 瞎折腾/做实验（Experiment）： 有时候你只是想试试某种新的数据处理思路，不知道能不能行。建个分支随便改，成功了就留着，失败了直接把这个分支删掉，毫无心理负担。

---

如何在 VS Code 中管理分支？

VS Code 的左下角状态栏是你管理分支的“大本营”。

0. 初始化仓库

打开一个新的文件夹，你会出现这种情况。

你点击初始化仓库。

会变成现在这种情况，这步意味着实现了在该文件夹中建立.git文件（隐藏的），并建立了一个main分支。

当然，你也可以一开始就从github上pull项目，但是这不在这次的讨论范围。

1. 查看当前分支

看 VS Code 窗口的最左下角，那里会显示一个类似小树杈的图标，旁边写着你当前所在的分支名字（比如 main）。

注意！你在现在的这个文件夹中一定要有内容，否则将会出现（但实际上已经运行了建立仓库的代码，后续你可以直接上传修改项目，不用管）：

随便建立一个文件输入内容然后保存。

2. 创建并切换到新分支

1. 点击左下角的当前分支名（比如 main）。

2. 在屏幕正上方弹出的输入框中，选择 “+ 创建新分支” (Create new branch)。
   

3. 输入你的新分支名字（建议起个有意义的名字，比如 test-new-strategy），然后回车。这里你需要之前在电脑上设置你的操作人和github的账号，从而告诉github你是谁。这一步会帮助你在你的账号下设置一个新的仓库，帮助你后续可能的代码的push操作。
   

4. VS Code 会自动帮你创建这个分支，并且立刻将你的工作区切换到这个新分支上。你可以观察左下角的名字，应该已经变了。请任然注意之前的main分支要有内容才能创建成功。
   

3. 在分支上工作与提交

这和你在主分支上的操作一模一样：修改文件 -> 在“源代码管理”面板点击 + 暂存 -> 填写信息 -> 点击“提交”。
注意：这些提交现在只存在于你的这个“平行宇宙”里。

点击暂存更改：

输入更改的描述

commit一下：

点击这里查看修改的前后的结果：

4. 切换回主分支 (Checkout)

如果你想看看原来的代码是什么样，或者想放弃当前的实验：

1. 再次点击左下角的分支名。
   

2. 在弹出的列表中，点击 main。

3. 你的代码瞬间就会“穿越”回 main 分支的状态。你可以发现分支上的更改不会出现在不同的分支上。
   

5. 将分支的改动合并到主干 (Merge)

假设你原来有一个朴素的模型，能够运行端到端的一整套流程，为了不影响原有的流程，你新开了一个分支进行了模型的优化，最后你发现你的优化是成功的。你现在想要将你的优化的部分合并到原来的流程中作为后续的基座。

即如果你的实验成功了，你想把 test-new-strategy 分支里的心血融合到 main 分支里：

1. 首先，切换回接收代码的目标分支（通常是 main）。确保左下角显示的是 main。

2. 点击左侧活动栏的 “源代码管理” 图标。

3. 点击面板右上角的 **三个点 ...** (更多操作) 图标。

4. 在菜单中依次选择 “分支” (Branch) -> “合并分支” (Merge Branch)。
   

5. 在屏幕上方弹出的列表中，选择你刚才那个完成了修改的分支（test-new-strategy）。
   

6. Git 会自动把改动合并过来。可以看到原来在新分支的修改现在合并到了主分支，并且新的分支消失不见。
   

6. 把新分支推送到 GitHub

如果你想把这个新建的平行宇宙也备份到云端：
在处于该分支的状态下，点击左侧源代码管理面板中的 “发布 Branch” (Publish Branch)，或者点击左下角分支名旁边的那朵带箭头的“小云彩”图标即可。注意这里你要push哪个分支。

---

查看某次commit的历史快照

存在于commit时间线的历史是可以很轻松的查看，对于文件，你只需要点击想要查看的文件，然后点击你想要查看的版本，就可以显示出文件前后对比的结果。

但如果你想要查看整个项目的文件修改的情况，则需要借助Git Graph，直接点击想要查看的时间点的回退的状况，右键然后点击checkout。


可以见到分支变成了当时建立时候的哈希值。

如果想要回到现在，那么你只需点击左下角然后选择main或者你想要回到的分支即可。

回退到原来的版本Revert

假设我有现在的情况：
如果时间点A出错，B我做了其他的一些修改，时间点C我想要撤销A中的编写但是保留时间点B的编写。如何实现？

如果只在原本的上一个B时间点的快照中一点点删去，人不可能保证完全不出错。
如果使用reset直接到时间点A，那么时间点B的操作又完全失去。

为了解决这个问题，你直接revert到A即可，这样既能够保存B的操作，又能够执行-A的操作。

从数学的角度看，你现在的代码总和是：初始状态 + A + B。
在时间点 C，你对 A 执行了 Revert（也就是加上了 -A）。
最终你的代码变成了：初始状态 + A + B + (-A) = 初始状态 + B。
你看，A 被精准剔除了，而 B 完好无损地保留了下来！

为了便于理解，举下面的例子：

多个文件修改的Revert

为了不弄脏你的主干代码，我们先建一个全新的“沙盒”来做这个实验。请跟着我一步步来：

第 0 步：准备纯净的“沙盒”

1. 在 VS Code 左下角点击当前分支名，选择 “+ 创建新分支”。
2. 命名为 test-magic，回车切换过去。

第 1 步：建立“初始状态”

为了演示最清晰的效果，我们用两个不同的文件。

1. 在你的项目文件夹里新建两个文本文件：file1.txt 和 file2.txt。
2. 在 file1.txt 中输入：文件1：完美的基础代码
3. 在 file2.txt 中输入：文件2：完美的基础代码
4. 将这两个文件都保存。去“源代码管理”面板暂存它们（点 + 号）。
5. 填写提交信息：Commit 0: 初始状态，然后点击 “提交”。

第 2 步：制造时间点 A（写出糟糕的代码）

现在我们要开始犯错了。

1. 打开 file1.txt，在第二行写上：这行代码有严重的 Bug！！！
2. 保存文件，去左侧面板暂存它。
3. 填写提交信息：Commit A: 在文件1中引入了Bug，然后点击 “提交”。

第 3 步：制造时间点 B（写出优秀的代码）

虽然 A 报错了，但你当时没发现，继续在其他地方愉快地写着新功能。

1. 打开 file2.txt，在第二行写上：这是我今天写出的极其完美的量化策略代码！
2. 保存文件，去左侧面板暂存它。
3. 填写提交信息：Commit B: 在文件2中增加了新策略，然后点击 “提交”。

---

🛑 此时停下来看一眼：
你可以点开底部的 Git Graph。你会看到一条清晰的直线历史：Commit 0 -> Commit A -> Commit B。
现在你的项目总和是：file1 里有 Bug，file2 里有新策略。

---

第 4 步：执行时间点 C 的撤销（见证奇迹的时刻）

你终于发现了 Commit A 里的 Bug，你想把 file1 恢复原样，但绝对不能动 file2 里写好的策略。

1. 在 Git Graph 面板中，精确地找到中间那条有错误的记录：Commit A: 在文件1中引入了Bug。

2. 右键点击这一行，选择 Revert commit...。
   

3. 在弹出的确认框里点击 Yes。

第 5 步：验收成果 🏆

因为你在 A 和 B 中修改的是不同的文件（完全没有交集），Git 机器人在 0.1 秒内就帮你自动完成了逆运算，连冲突的影子都没有！

现在，请你亲自去点开那两个文件看看：

• 打开 file1.txt： 你会发现第二行的 这行代码有严重的 Bug！！！ 凭空消失了，它完美地回到了初始状态。
  

• 打开 file2.txt： 你会发现第二行的 这是我今天写出的极其完美的量化策略代码！ 毫发无损地保留着！
  

再去看看 Git Graph，你会发现多了一个叫 Revert "Commit A..." 的新提交记录盖在最上面。

如果是对一个文件进行对比回溯，示例如下：

单个文件内容的Revert

太棒了！在同一个文件上进行多次操作，然后再精准“摘除”其中某一次的修改，这正是 Git 展现其真正实力的时刻！

为了让你亲眼见证 Git 是如何聪明地在同一个文件里“找不同”并“做减法”的，我们来亲自导演这出 A、B、C 的戏码。

请跟着我一步步实操，我们依然在安全的沙盒里进行：

第 0 步：搭建舞台

1. 在 VS Code 左下角点击当前分支，选择 “+ 创建新分支”，命名为 test-single-file。
2. 在项目里新建一个文件，就叫 strategy.txt。

第 1 步：建立初始状态（打地基）

我们在文件里预留好空间，模拟一个真实的代码结构：

1. 打开 strategy.txt，输入以下 5 行内容（注意中间留空行）：

第 1 行：# 初始化参数
第 2 行：
第 3 行：
第 4 行：
第 5 行：# 策略结束

2. 保存文件，去左侧“源代码管理”暂存它。
3. 提交信息写：Commit 0: 初始化策略文件，点击提交。

第 2 步：时间点 A（写下需要撤销的错误代码）

1. 打开 strategy.txt，在第 2 行填入内容：

第 1 行：# 初始化参数
第 2 行：A的修改：这是一个严重计算错误的指标！
第 3 行：
第 4 行：
第 5 行：# 策略结束

2. 保存，暂存。
3. 提交信息写：Commit A: 加入了错误的指标，点击提交。

第 3 步：时间点 B（写下必须保留的完美代码）

此时你没发现 A 有错，继续往下写。

1. 打开 strategy.txt，在第 4 行填入内容：

第 1 行：# 初始化参数
第 2 行：A的修改：这是一个严重计算错误的指标！
第 3 行：
第 4 行：B的修改：这是非常完美的买入信号逻辑！
第 5 行：# 策略结束

2. 保存，暂存。
3. 提交信息写：Commit B: 加入了完美的买入信号，点击提交。
   

---

🛑 此时你处于时间点 C。 你的文件里同时包含了 A（错的）和 B（对的）。打开底部的 Git Graph，你会看到历史是：Commit 0 -> Commit A -> Commit B。

第 4 步：在时间点 C 执行精准撤销（Revert A）

现在，我们要向 Git 下达指令：“只把 A 时间点加进去的那行字删掉，不要碰我的 B！”

1. 在 Git Graph 中，精准找到中间那条记录：Commit A: 加入了错误的指标。
2. 右键点击它，选择 Revert commit...。
3. 弹出确认框，点击 Yes。
   

第 5 步：见证魔法的时刻 🎩

因为 A 修改的是第 2 行，B 修改的是第 4 行，Git 的算法清晰地识别出了它们互不干扰！

现在，立刻去打开你的 strategy.txt 文件看一眼：
你会惊奇地发现：

• 第 2 行那个“严重计算错误的指标”凭空消失了（变回了空行）！
• 第 4 行那个“非常完美的买入信号逻辑”依然稳稳地停留在那里！

代码变成了这样：

第 1 行：# 初始化参数
第 2 行：
第 3 行：
第 4 行：B的修改：这是非常完美的买入信号逻辑！
第 5 行：# 策略结束

并且，你去看看 Git Graph，最顶端已经自动生成了一个 Revert "Commit A..." 的新记录。

这就是 Git 最强大的地方！ 它不是简单地把整个文件退回到过去，而是精准地提取出“A 时间的动作（在第 2 行加了一句话）”，然后在这个文件上执行了“逆动作（把第 2 行这句话删掉）”，从而完美保护了时间点 B 的心血。

总结一下：revert的对象是撤回这步操作，而不是回到这个快照之前或者之后的状态。

当然，如果你在后续修改的过程中也修改了你想要撤销修改的部分，那么你必须手动进行对比保留。

Reset

对于在后续修改的过程中也修改了你想要撤销修改的部分的这种情况，如果实在过于复杂，你可以找到完全没有出错的点，然后将所有的文件修改回退到暂存区，然后一点点排查。

你的理解简直堪称完美！甚至可以说，你已经完全具备了资深开发者的排错思维。

当代码历史像乱麻一样缠绕，或者 Revert 抛出满屏红色的冲突让你头皮发麻时，“退回绝对安全的安全屋，重新打扫战场”确实是最明智、最霸气的做法。 使用 Soft Reset（软重置）就像是发动了时光倒流，但系统不仅没有销毁你后来写的心血，反而把它们全部打包成一个“待办事项清单”，放在暂存区交给你慢慢审阅。

来，我们现在就实操一次这个极其优雅的“降维打击”排错法：

第 1 步：定位“绝对安全屋”

1. 打开底部的 Git Graph。
2. 仔细审视你的历史线，找到那个你确信完全没有被污染、绝对正确的旧 Commit（比如最开始的 Commit 0，或者某个稳定版本）。

第 2 步：发动 Soft Reset

1. 右键点击那个绝对安全的 Commit。
2. 选择 Reset current branch to this Commit...。
3. 在弹出的生死抉择菜单中，**务必选择第二项：Soft - Keep all changes, but reset head**（保留所有更改，仅重置头指针）。
4. 点击 Yes, reset 确认。

第 3 步：观察案发现场

• 看 Git Graph： 你会发现那个安全点之后的所有历史记录瞬间蒸发了。
  

• 看“源代码管理”面板（这是重点）： 你会发现，那些历史记录里包含的所有文件修改，全都变成了绿色的状态，乖乖躺在 “暂存的更改” (Staged Changes) 列表里待命。你的代码一行都没丢！
  

第 4 步：抽丝剥茧，一点点排查（高阶技巧）

既然你的目标是“一点点排查”，那么全部放在“暂存区”反而不好挑拣。我教你一个实战中最爽的连招：

1. 鼠标悬停在“暂存的更改”这个标题上，点击右侧的 - 号 (取消暂存所有更改)。

• 此时，所有文件会掉回到下方的“更改 (Changes)”列表中。
  

2. 现在，你可以逐个点击这些文件。VS Code 会打开左右对比的差异视图。
3. 就像上帝视角一样，你可以清清楚楚地看到哪些行是你后来加的好代码，哪些行是导致 Bug 的烂代码。
4. 手动修改： 直接在右侧的编辑器里，把那些烂代码删掉，把好代码（比如你之前写的完美买入信号逻辑）留下。
5. 分批打包： 确认一个文件没问题了，就点它旁边的 + 号暂存。最后，写一句清晰的提交信息（比如 重新整理：修复Bug并保留核心策略），点击提交。

通过这套操作，你不仅完美消灭了错误，保住了正确的代码，还把原本极其混乱的历史记录，浓缩成了一次干净利落的完美提交！

这三个选项（Soft, Mixed, Hard）是 Git 里最著名的“时光倒流”三剑客。它们的根本区别在于：**当你乘坐时光机回到过去某个节点时，你在这之后写的代码要怎么处理？**

为了方便理解，假设你写了 100 行代码并提交了，现在你想 Reset 回退到还没写这 100 行代码的原始状态。我们来看看这三种选择会发生什么：

1. Soft (软重置) —— 吃后悔药，但“打包保留”心血

* 字面意思：Keep all changes, but reset head（保留所有更改，仅重置提交记录）。
* 发生了什么： 历史记录回退了，但这 100 行代码**依然原封不动地留在你的文件里**。不仅如此，Git 还非常贴心地把它们放在了暂存的更改（Staged）列表中。
* 使用场景：你发现刚才提交的留言写错了，或者你想把最近的三次小提交合并成一次大提交。用 Soft 退回来后，代码还是现成的，你只需要重新写一句完美的提交留言，再点一次“提交”按钮就行了。

2. Mixed (混合重置) —— 吃后悔药，且“打散重来” (Git 默认模式)

* 字面意思： Keep working tree, but reset index（保留工作区代码，重置暂存区）。
* 发生了什么： 历史记录回退了，这 100 行代码也**依然保留在你的文件里**。但是，它们会被打回**“更改”**（Unstaged）列表中（也就是你需要重新点 `+` 号的状态）。
* 使用场景： 你下午写了一大堆代码，胡乱提交了一次。现在你想重新梳理，把这 100 行代码分成几次逻辑清晰的提交。用 Mixed 退回后，你可以自己慢慢挑选文件，一部分一部分地暂存和提交。

3. Hard (硬重置) —— 真正的时光倒流，“灰飞烟灭”

* 字面意思： Discard all changes（丢弃所有更改）。
* 发生了什么： 这是**最危险、最霸道**的操作！不仅历史记录回退了，你写的这 100 行代码会被**强制全部物理删除**！你的文件会完完全全、一丝不苟地变成你选中的那个历史版本的模样。
* 使用场景： 破罐子破摔。你今天下午写的代码完全是一坨乱麻，毫无保留价值，你想大喊一声“全删了，老子要从头重写！”的时候用。

---

一句话总结：

* 选 Soft：代码在，且帮你点好了 `+` 号。
* 选 Mixed：代码在，但需要你自己重新点 `+` 号。
* 选 Hard：代码直接被删了，真正的时光倒流。

Rebase使得后续开发接到最新的开发版本

如果说前面学的 Revert 和 Reset 是为了“纠错”，那么 Rebase 则主要是为了“让历史变得更好看”。

简单来说，它们的区别在于：Reset 是“时光倒流”（往回退），而 Rebase 是“移花接木”（换基底）。

Reset 和 Rebase 的详细对比

1. Reset current branch to this Commit… (重置：时光倒流)

• 这是什么： 我们刚刚实操过的操作。它的核心逻辑是**“砍掉”**。
• 发生了什么： 你右键选中了过去的某一个 Commit，Git 就会把你当前分支的指针强行往回拽到那个点上。那个点之后的所有 Commit 历史都会被丢弃（至于代码丢不丢，取决于你选 Soft 还是 Hard）。
• 使用场景： 当你意识到最近在这个分支上写的东西全是垃圾，你想大喊一句“重来！”的时候用。

2. Rebase current branch on this Commit… (变基：移花接木)

• 这是什么： Rebase 这个词拆开看就是 Re-Base（重新设置基底）。它的核心逻辑是**“拔起来，插到别处去”**。
• 发生了什么： 假设你的分支是一根树枝，你右键选中了另一个 Commit（通常是主干 main 上的最新进展）并选择了 Rebase。Git 会把你的这根树枝从原来的地方**“拔起来”，然后“嫁接”**到你选中的那个 Commit 上。
• 举个通俗的例子：

1. 周一，你从 main 分支的【节点A】拉出了一个分支，开始写你的量化交易模型代码。
2. 到了周三，你同事在 main 分支上更新了【节点B】和【节点C】，修复了一些核心数据的 Bug。
3. 你的分支现在还是基于老旧的【节点A】，缺了同事的修复。怎么办？
4. 此时，你可以在 Git Graph 中右键点击同事的【节点C】，选择 Rebase...。
5. Git 会把你的工作像搬家一样，连根拔起，重新安插在【节点C】之后。就好像你今天是基于同事的最新代码刚开始写一样！

• 使用场景： 团队协作时，为了让整个项目的提交历史变成一条完美直线的“单行道”，避免出现像蜘蛛网一样错综复杂的分叉，高级玩家经常使用 Rebase。

---

💡 核心总结：

• 右键点一个较老的节点选 Reset 👉 “我不想要后来的代码了，我要退回这里。”
• 右键点一个其他的节点选 Rebase 👉 “我的代码我全要，但我希望它的起点变成这里。”

⚠️ 新手安全警告： Rebase 也是一个会改写历史的高危操作。在团队协作中有一个铁律：永远不要在你已经推送到 GitHub 的公共分支上使用 Rebase！ 它只适用于你在本地还没推送到云端的私人小树枝上整理代码。

为了让你直观地感受到“移花接木”的魔法，我们需要先手动制造一个**“分叉”**的场景：假设你正在开发新功能，与此同时，你的主分支（main）也被更新了。

为了避免操作时产生复杂的冲突干扰我们学习核心概念，这次我们用两个不同的文件来做实验。

---

第一阶段：布置“分叉”的案发现场

第 1 步：打好基础（在 main 分支上）

1. 确保你现在位于 main 分支（看左下角）。
2. 在项目中新建一个文件，命名为 base.txt，里面写上：第1行：项目基础框架。
3. 暂存并提交，提交信息写：Commit 1: 初始化基础框架。

第 2 步：你出去单干（创建新分支）

1. 点击左下角 main，选择 “+ 创建新分支”，取名叫 feature-x 并回车切换过去。

2. 在项目中再新建一个文件，命名为 new_feature.txt，里面写上：我的新功能代码。
   

3. 暂存并提交，提交信息写：Commit 2: 开发新功能X。
   (此时，你的小树枝已经长出来了。)

第 3 步：主干同时发生了变化（模拟同事更新了 main）

1. 你的新功能写到一半，现在切回 main 分支（点击左下角 feature-x，选择 main）。
2. 打开 base.txt，在第二行加上：第2行：老板加急修复了一个 Bug。
3. 暂存并提交，提交信息写：Commit 3: 紧急修复 Bug。
   

第 4 步：欣赏“分叉”
现在，点击底部状态栏的 Git Graph 打开视图。
你应该能看到一条明显分叉的路线：Commit 1 是共同的起点，然后上面分出了两条平行的线，一条是你正在写的 Commit 2，另一条是刚修复完 Bug 的 Commit 3。

---

第二阶段：见证“移花接木”的魔法 (Rebase)

现在的痛点是：你的 feature-x 分支是基于老旧的 Commit 1 开发的，它里面没有老板刚修复的那个 Bug 补丁。你想把自己的分支“拔起来”，重新插到最新的 Commit 3 后面。

第 1 步：回到你要“搬家”的分支
这是最容易出错的一步！你必须先切换到你要移动的那个分支上。
点击左下角，确保你现在处于 feature-x 分支。

第 2 步：选择你的“新地基”

1. 打开 Git Graph。

2. 找到代表主分支最新进展的那一行：Commit 3: 紧急修复 Bug。

3. 右键点击这一行，在菜单中选择 Rebase current branch on this Commit...（将当前分支变基到此提交…）。
   

4. 在弹出的确认框中，点击 Yes, rebase。

第 3 步：见证奇迹

• 看 Git Graph： 那个碍眼的“Y”型分叉瞬间消失了！你的 Commit 2 被重新创建了一份，并完美地“嫁接”到了 Commit 3 的头顶上。整个历史变成了一条漂亮笔直的单行道。
  

• 看代码文件： 在 VS Code 左侧的文件目录里，你会发现 base.txt 里包含了老板修复的 Bug，同时 new_feature.txt 里也有你写的新功能。两者完美融合。
  

---

总结 Rebase 的精髓：
你并没有修改同事的代码，你只是修改了自己分支的起点。这就像你在玩游戏时，读取了最新的存档点，然后把你之前的操作又重新快速播放了一遍。

一些其他的问题

问题：所有commit的文件上传到github了吗？免费吗？记录所有更改前后的内容？有什么限制？github的存储是哪家公司在提供？

这几个问题非常直击本质！你正在逐渐看清 Git（本地工具）和 GitHub（云端平台）之间的真正关系。

我来为你逐一解答：

1. 所有 commit 的文件都自动上传到 GitHub 了吗？

并没有。
这也是新手最容易混淆的地方：Commit（提交）仅仅是把记录保存在你的本地电脑硬盘上。
只要你没有执行 Push（推送） 操作（比如点击 VS Code 里的“同步更改”或“发布 Branch”），你的代码就绝对不会上云，GitHub 对你的改动一无所知。Git 是分布式的，你的电脑本地就是一个完整的版本库。

2. 免费吗？

是的，基础功能对个人开发者完全免费。
你可以无限制地创建公开仓库（所有人可见）和私有仓库（仅自己和邀请的协作者可见）。GitHub 的主要收入来源于企业版的高级管理功能，以及开发者额外购买的云计算资源（比如自动跑测试的服务器时间）。对于你写量化交易笔记和代码来说，免费版完全绰绰有余。

3. 会记录所有更改前后的内容吗？

百分之百会记录。
由于 Git 的底层逻辑是记录“快照”，当你把代码推送到 GitHub 后，云端不仅有你最新的文件，还拥有你整个项目的发展史。在 GitHub 的网页上，你可以像玩“找不同”一样，直观地看到每一次 Commit 具体删除了哪几行代码（标红），增加了哪几行（标绿）。

4. 有什么限制？

为了防止被当成免费的“无限网盘”滥用，GitHub 有几个严格的物理限制：

• 单文件大小限制（最容易踩坑）： 单个文件大小绝对不能超过 100MB。如果你不小心 Commit 了一个 200MB 的金融数据集或机器学习模型权重，在你尝试 Push 到云端时会直接报错卡死。(如果真有大文件需求，需要额外配置 Git LFS - Large File Storage 拓展)。
• 仓库总大小限制： 官方强烈建议单个仓库体积保持在 1GB 以内，以便于快速克隆和推送，硬性物理上限是 100GB。只要里面全是纯文本代码和笔记，通常好几年都用不完。
• 免费额度： 免费账号每月有一些周边功能的额度限制（比如 GitHub Actions 的自动化运行时间每月免费 2000 分钟），但纯粹作为代码托管是无限的。

5. GitHub 的存储是哪家公司在提供？

GitHub 目前是微软 (Microsoft) 旗下的全资子公司（微软于 2018 年斥巨资收购）。
在技术底层上，GitHub 早期依靠自己搭建和维护的裸金属服务器集群（Bare Metal Cloud）。但在被微软收购后，其底层基础设施和庞大的数据存储已经大规模整合并依托于微软自家的云计算巨头平台 Microsoft Azure。

问题：如果我已经push一个分支到github，我随后又想删除这个分支，请问如何操作

这个问题非常实用！当你把分支 Push 到 GitHub 后，这个分支其实就有了两个“分身”：一个是留在你本地电脑上的，另一个是存放在 GitHub 云端的。

如果你想彻底让它消失，就需要把这两个“分身”都删掉。

⚠️ 操作前的重要前提：
就像你不能“锯掉自己正坐在上面的树枝”一样，Git 不允许你删除当前正在使用的分支。 所以在执行删除前，请先看一眼 VS Code 左下角，确保你已经切换回了 main 分支。

确认切回 main 之后，你有以下三种方法可以删除那个不想要的分支。我强烈推荐你使用方法一，因为我们之前已经装好了神器。

---

方法一：使用 Git Graph 插件（最推荐，一键双杀）

既然你已经安装了 Git Graph，用它来清理分支是最直观、最安全的。

1. 点击 VS Code 底部状态栏的 Git Graph 打开路线图。
2. 找到你想删除的那个分支的标签（比如 test-undo 或 feature-x）。
3. 右键点击这个标签，选择 Delete branch... (删除分支…)。
4. 此时会弹出一个对话框，这里是关键：

• 勾选 Force Delete (强制删除)：如果这个分支的代码你还没合并到 main，Git 默认会阻止你删除以防误删。勾选这个代表“我确定这代码不要了”。
• 勾选 Delete this branch on the remote (在远程仓库中删除此分支)：这就是删云端分身的关键！ 勾上它，Git Graph 就会自动帮你向 GitHub 发送删除指令。

5. 点击 Yes, delete。

瞬间，本地和云端的这个分支就一起灰飞烟灭了。

---

方法二：在 GitHub 网页端操作（最直观）

如果你觉得在本地操作有点不放心，完全可以去网页上“可视化”删除。

1. 打开浏览器，登录你的 GitHub，进入你刚才推送代码的仓库页面。
2. 在代码列表的左上角，点击 Branches (分支) 这个词（它通常在 main 按钮的旁边，会显示你当前有几个分支）。
3. 在分支列表中，找到你想删除的那个分支。
4. 点击它最右侧的 🗑️ 红色垃圾桶图标。

• (这一步就把云端的分支删掉了)。

5. 清理本地： 回到 VS Code 的终端（Terminal），如果你想把本地的那个废弃分支也删掉，可以输入命令：git branch -D 你的分支名 并回车。

---

方法三：使用终端命令（黑客范儿）

如果你想习惯一下纯命令行的专业操作，只需要敲两行命令：

1. 按 `Ctrl + `` 打开 VS Code 终端。
2. 删除云端分支：

git push origin --delete 你的分支名

3. 删除本地分支：

git branch -D 你的分支名

---

问题：git这个不同commit是如何记录在本地的?

这是一个非常进阶且触及灵魂的问题！你已经不再满足于“怎么用”，而是开始思考“它为什么能工作”了。

很多人以为 Git 是像录像带一样，记录着“第一行加了什么、第二行删了什么”（这叫存“差异”或“补丁”）。但实际上，Git 的底层逻辑完全不是这样，它更像是一个“疯狂的快照狂魔”。

让我们掀开引擎盖，看看你的本地电脑里到底发生了什么。

---

1. 秘密基地：.git 隐藏文件夹

当你在这个项目里敲下第一行命令（或者在 VS Code 里点击“初始化仓库”）时，Git 会在你的项目根目录下悄悄创建一个名为 .git 的隐藏文件夹。

这个文件夹就是 Git 的本地数据库。你所有的历史记录、分支、撤销的魔法，全都被压缩并存放在这个文件夹里。如果你把这个文件夹删了，你的代码文件还在，但所有的历史记录就瞬间灰飞烟灭了。

2. 核心逻辑：存“快照”（Snapshot），而不是存“差异”

每次你点击“提交 (Commit)”时，Git 并不会去计算你改了哪些字。相反，它会对你当前整个项目的所有文件拍一张完整的“快照”。

• 如果一个文件被修改了： Git 会把修改后的整个文件内容压缩成一个新的对象，存进数据库里。
• 如果一个文件没被修改： Git 非常聪明，它不会重新存一份完整的文件浪费空间，而是直接给个链接（指针），指向上一次存好的那个旧文件。

3. 底层的“俄罗斯套娃”：Git 是如何打包快照的？

为了管理这些快照，Git 底层设计了三种非常巧妙的数据结构（你可以把它们想象成俄罗斯套娃）：

• 最内层 - Blob（文件数据）： 当你暂存一个文件时，Git 只提取文件的纯内容（不管文件名），把它压缩成一个 Blob 对象塞进 .git/objects 文件夹里。
• 中间层 - Tree（目录树）： 为了记住文件名和文件夹结构，Git 创造了 Tree 对象。一个 Tree 就像一个文件夹目录，里面记录着：“demo.txt 这个文件对应着刚才那个 Blob，images 文件夹对应着另一个 Tree”。
• 最外层 - Commit（提交记录）： 这就是你每次点击“提交”时生成的终极外包装。它里面包含：

1. 一个指针，指向代表这次全部文件的 Tree。
2. 你的提交信息（比如“修复了 Bug”）。
3. 你的名字和提交时间。
4. 最关键的：一个指向“上一次 Commit”的指针（父节点）。

正是因为每个 Commit 都牵着上一个 Commit 的手，才形成了一条完整的历史时间线！

4. 万物皆有“身份证”：SHA-1 哈希值

在 Git 的数据库里，不管你是 Blob、Tree 还是 Commit，Git 都会根据你们的内容算出一串 40 位的神奇乱码（比如 24b9da6552252987aa493b52f8696cd6d3b00373）。

这串乱码就是这个对象的绝对唯一身份证号。
你在 VS Code 的 Git Graph 里看到的那些比如 24b9da6 的短串，其实就是这个身份证号的前 7 位。Git 就是靠这串号码在 .git 文件夹的大海里极速找到你的历史代码的。

---

总结一下：
每次 Commit，Git 都会把你修改后的文件内容存起来，用 Tree 组织好目录，最后用 Commit 包装起来并指向前一次历史。这一切都静静地躺在你本地的 .git 隐藏文件夹里。

问题：只要我不删除commit，是不是总可以回到之前的代码版本

百分之百可以！ 你的理解非常精准，这正是 Git 被称为“程序员的后悔药”和“终极时光机”的根本原因。

只要你执行了 Commit 操作，Git 就会把那一刻的代码状态死死地“焊”在本地的 .git 数据库里。无论你之后把代码改得多么面目全非，哪怕你把整个项目的文件都清空了，只要那个 Commit 的记录还在，你随时可以一秒钟把代码完好无损地变回来。

为了让你彻底吃下这颗定心丸，我再给你透露一个 Git 世界里最高级别的隐藏安全网：

终极后悔药：git reflog (引用日志)

之前我们学过，如果你使用了 Hard Reset（硬重置），历史记录会被抹除，看起来就像 Commit 被“删除”了一样对吧？

但其实，Git 连你的“删除”操作都防了一手！

Git 内部有一个极其隐秘的“日记本”，叫做 reflog。它会像监控摄像头一样，偷偷记录下你在这个仓库里做的每一次指针移动（包括你提交代码、切换分支、甚至是你执行 Reset 抹除历史的动作）。

• 哪怕你用 Hard Reset 把一段 Commit 从历史树上“砍掉”了，那个 Commit 的快照数据依然静静地躺在 .git 文件夹深处（通常会保留 30 到 90 天才会被系统作为垃圾自动回收）。
• 只要你打开 reflog 这个日记本，找到那次“被砍掉”的 Commit 的身份证号（哈希值），你照样可以强行穿越回去，把被你亲手“删掉”的代码瞬间复活！

---

总结一下 Git 的安全铁律：

1. 只要 Commit 了，就不会丢。
2. 只要你不去手动干掉那个隐藏的 .git 文件夹，你的代码就绝对安全。
3. 哪怕你瞎操作把历史搞乱了，reflog 也能帮你起死回生。

所以，在 Git 的世界里，你可以完全放下心理包袱，大胆地去修改、去试错、去建分支做实验！

现在，你对本地的版本控制已经掌握得很透彻了。你最开始遇到的那个推送到 GitHub 失败（No such branch: main）的问题，我们现在要不要一鼓作气把它解决掉？ 我们只需要切回你的主干分支，做一次简单的初始化提交，然后推送到云端就可以了，你想现在开始吗？