Git祖师爷和我发明的GitMission🤣

祖师爷实在太伟大了

祖师爷伟大程度：出版社在22年三个月就发表Linux Unix前世今生

想了很久这个话题，我上次还定义成情报界Github

本集探讨祖师爷发明Git的心路历程

先发一下四个月前我写的情报界GitMission【剧本】代号008 女主对男主的爱💗 Code Review — SHINAINAI

能量层级排在第1位的是“开悟” 在code review中开悟 得到启示

我了解了一下Git和Github区别

Github延续和使用Git核心部分，直接表面其作为Git代码库托管中心的本质功能，并最大化复用Git的开源生态与技术共识

Git（版本控制）+ Hub（枢纽 集散）

Git + Mission（整理好的情报和数据用于女主的推理和分析）

来自ChatGPT：

Linux祖师爷本人：

2005 年 4 月，Linus 开始编写 Git。4 月 7 日，Git 的第一个提交出现；Git 很快就能管理自身的源代码。

他希望新工具具备几个关键特征：

• 速度快：能够处理 Linux 内核这样的大型代码库。

• 分布式架构：每个开发者都可以拥有完整的本地仓库和历史记录。

• 分支能力强：允许多个开发者同时进行不同方向的开发。

• 可靠性高：能够检查和追踪代码内容的变化。

2005 年下半年，Git 的维护工作逐步交给 Junio Hamano，Git 随后持续发展为成熟的开源版本控制系统

---

我总结了一下女主为什么没有第一时间收到讯息，就是男主的commit被revert

中间还有无数次其他情报员暗示过女主，她也没进行复盘

原因如下：

1. 三种可能的操作

情况 A：使用 git reset 并强制推送

对方把分支指针移回之前的提交，再使用 git push --force 或 git push --force-with-lease 更新远程分支。

结果：原提交可能不再出现在该分支的提交历史中。

情况 B：分支被删除或替换

你的 commit 所在的分支可能被删除、重建，或者被其他分支的历史取代。

结果：在原先查看的位置找不到它。

情况 C：你查看的是不同的分支或页面

例如，原提交在某个功能分支上，而你现在查看的是 main 分支的提交记录。

结果：原提交仍可能存在于其他分支或 Pull Request 中。

2. 怎么判断到底发生了什么？

你可以在 GitHub 上检查：

• Commits：确认当前分支的提交历史。

• Branches：查看原来的分支是否还存在。

• Pull Requests：查看相关的合并、关闭或撤销记录。

• 原始 commit URL：如果你之前保存过提交链接，可以直接打开，看看是否仍然可访问

---

祖师爷在早期繁重的工作：

Linux 内核在早期发展过程中，开发者需要通过邮件发送代码补丁、交换文件，再由维护者检查和整合修改。

这种方式能够工作，但随着 Linux 内核越来越庞大，开发者数量增加，管理大量并行修改就变得困难。

我自己的理解：

祖师爷就像一个大管家，他有绝对的控制权，选择加入哪些让他满意的代码整合到系统中

就像女主角做情报，所有情报都在女主角脑里，由女主出决策，能否采用依据可靠程度-信或不信，就像早期Linux整个项目依赖一条由子系统维护者组成的信任链