Git通讲-第三章（2）：Hooks钩子
前言这篇文章我们来聚焦.git/hooks/这个熟悉又陌生的文件夹。我不知道读者有没有前端经验，React里也有Hook的概念，但是此hook非彼hook。不懂，我们看下去就知道了。
Git 钩子的基本概念以下是 Git 钩子（hooks）的详细介绍，包括使用场景、编写示例和注意事项。Git的钩子（hooks）是一组钩子脚本文件，位于.git/hooks目录下。它们允许你在Git的特定事件（如提交、合并、推送等）发生时，自动执行自定义脚本。默认情况下，Git在.git/hooks目录中会提供一些样例文件，这些样例文件以.sample为扩展名。
Git Hooks 的分类Git hooks分为客户端钩子和服务器端钩子两类：
客户端钩子：这些钩子在本地仓库运行，主要用于检查或优化提交的代码，确保符合规范，适用于代码风格检查、运行测试等常规操作。
服务器端钩子：这些钩子在远程仓库服务器上运行，通常用于更高级的代码控制，比如防止不合规的代码被推送到共享仓库上。
客户端钩子这些钩子在本地仓库中运行，通常用于代码质量检查、测试等。
pre-commit：在提交前执行。用于检查代码是否符合要求 ...
Git通讲-第三章（1）：常用指令及仓库分区
前言本章开始，我会笼统的介绍一下git的一些常用指令，然后挑我感兴趣的一些指令进行详细解析和拓展。这章将不像前一章那样关注概念的理解，而是逐渐将重心转移到应用上去。
Git指令Git的指令（命令）可以分为几种主要类型，每种类型针对不同的操作和功能，其实如果你一路看下来光看名字也能猜出个所以然，前面文章中也多多少少触及到了一些Git指令。以下是主要的几种类型指令：
1. 配置命令
git config：设置Git的全局或本地配置。
2. 仓库命令
git init：初始化新的Git仓库。
git clone：克隆远程仓库。
3. 文件操作命令
git add：将更改添加到暂存区。
git rm：删除文件。
git mv：移动或重命名文件。
4. 提交命令
git commit：提交更改。
git commit --amend：修改上一个提交。
git commit -m "message"：提交时直接添加提交信息。
5. 分支和合并命令
git branch：管理分支。
git checkout：切换分支或恢复文件。
git merge：合并分支。
git r ...
Git通讲-第二章（4）：分布式版本控制
前言也是到第二章的第四篇了，这篇我希望能结合前面讲到的快照模型、不可变数据对象、分支模型的知识，来探讨Git是如何实现分布式这件事情的，或许会捎带嘴的提一下Github之类远程托管仓库平台的兴起。
Git分布式版本控制的实现Git的分布式版本控制系统与传统的集中式版本控制（如SVN）相比，有几个关键的不同点。Git的架构使得每个开发者的本地仓库不仅仅是一个工作副本，而是一个完整的仓库，包含了项目的所有历史记录。这种设计带来了灵活的协作模式和极大的独立性。以下是Git分布式版本控制的一些关键点：
1. 本地完整仓库
完整性：在Git中，每个开发者的本地仓库都是项目完整的历史副本，包括所有的提交记录、分支、标签等。这意味着，开发者在本地可以进行几乎所有的操作，比如查看历史、创建分支、提交代码等，而不需要连接到远程服务器。
独立性：开发者不需要依赖中央服务器，甚至在没有网络连接的情况下也可以正常工作。这种离线工作的能力在许多场景下非常有用，尤其是在网络不稳定的环境中。
优势：即使没有网络连接，开发者也可以进行提交、分支创建、查看历史等操作，而不依赖于中央服务器。
2. 数据完整性和安全性
...
Git通讲-第二章（3）：分支模型
前言呜呜呜🫡🫡🫡也是到第三篇了，我打算在该篇主要讲git的本地分支的相关内容，而远程分支则留给下一篇分布式版本控制。由于.git/ref/文件下还有tag，那就同时补充介绍一下之前一直忽视的tag吧，我个人感觉是没啥用。其实这一块内容我6月份的一篇文章中已经讲解了具体的命令操作（[[Git本地与远程]]），本篇则更加关注于概念和原理。
分支模型Git 的分支模型是一种灵活且高效的版本控制机制，通过指针和哈希引用管理分支，能够轻松支持并行开发、功能隔离和协作。这种实现方式既节省空间，又使得分支操作非常迅速。以下是 Git 分支模型的详细讲解：
1. 分支的基本概念
分支是 Git 的核心特性，它允许你从主线代码中分离出独立的开发路径。分支的创建、切换和合并速度很快，使得开发人员可以并行进行新功能的开发、修复 bug 或实验，而不会影响主分支。
默认情况下，Git 会有一个主分支，通常称为 main 或 master（弗洛伊德之死黑命贵运动席卷全球后由于master有主人的意义，为避免种族歧视嫌疑，git现在默认的主分支名改为了main，github也是如此，当然分支的默认名称可以通 ...
Git通讲-第二章（2）：对象数据库
前言理解了上篇文章的两大模型（快照和不可变对象）后，让我们看看Git 的核心——对象数据库，快照存储在 .git/objects 目录中，Git 通过这种方式管理项目的所有历史和数据。
Git对象数据库下面是 .git/objects 目录的基本结构：
1234567891011121314151617.git/objects/│├── e5/│ └── 0c5ab6d9c5e3ac9e7b1b3f1c3b2302c0f4db3 # 对象文件│├── 12/│ └── ab34b22f35e3f1c26c0c4e3dff9c3c0ff76c76a # 对象文件│├── 34/│ └── f8ae3f7b1bcad1cb38e3ae0a49dbd8b35a1be0b2 # 对象文件│├── pack/│ ├── pack-<hash>.pack # Pack文件│ └── pack-<hash>.idx # Pack索引文件│└── info/ └── packs # 存储有关已打包对象的信息
说明：
e5/ 和 12/ ...
Git通讲-第二章（1）：快照和不可变对象模型
前言上一篇文章主要介绍些Git起源背后的一些故事背景，从这篇开始将逐渐讲解Git的设计理念，包括分布式控制、快照管理、不可变对象模型和分支模型。其实上述概念都不是孤立的，在讲解中会发现它们是相辅相成的有机整体，实现1+1大于2的效果。接下来预计会按照快照模型与不可变对象模型、分支模型、分布式控制这样的顺序讲解，其用意到后面自会明了。本人总是从中能看到区块链的影子，之后会引入区块链的相关知识进行补充，也当是拓展了🫠。
快照存储模型快照模型与传统的版本控制系统（如SVN等）不同。传统系统通常基于文件的差异（diff）来管理版本，而Git则使用快照（snapshot）的方式来记录项目的每个版本。
快照模型的主要特点：
快照而非差异：
Git会在每次提交时保存项目的当前状态，称为“快照”。这意味着每次提交都是整个项目的完整状态，而不是仅保存变化部分。
只保存变更：
虽然每个提交实际上是一个完整的快照，但Git为了节省空间，内部实现上只存储更改过的文件的内容，而未改变的文件只保存一次。这使得Git非常高效。
对象存储：
Git将文件和目录的快照存储为对象，每个对象都有一个唯一的SHA- ...
Git通讲-第一章：起源
前言这一篇文章其实我筹谋了好久了，从七月暑假开始之时突然对git的源码感兴趣，想要深入了解一下，也确实看了些资料，但最后还是战线拖太长了，注意力转移到其他处了，写博文的事情就一直在todolist呆到现在🫠。之前也略微写了两篇博文，第一篇大致的记录了git的基础知识包含一些vim的基础知识，第二篇则是主要关注git本地和远程仓库之间的操作，感兴趣的可以爬楼去看。本打算一篇博客就讲完的，但是学了一下，发现可讲的东西确实有些丰富，就打算开一个系列，系统地讲讲Git。这篇文章也是系列的开始之作，希望能有头有尾吧orz。也算给我锻炼下文笔，努力给大家讲得明明白白的。
引文要讲Git是什么，我打算还是先让大家了解下git诞生的目的是什么——版本控制🗄️
版本控制简介版本控制系统（Version Control System，简称VCS）是一种软件工具，用于跟踪文件的更改历史，记录代码在不同时间点的状态。它的核心功能是允许开发者保存项目的多个版本，并能够在需要时回溯、对比、合并这些版本。通过版本控制，团队中的每个开发者都可以轻松地协同工作，同时确保代码的版本历史清晰可追溯。
为什么版本控制对软 ...
Obsidian个人知识管理工具体验分享
前言之前都是在用Typora作为我的文字记录工具，但暑期的时候看到RSS突发奇想，想要搞一套完整的信息流，于是就在寻找合适我的笔记软件，最后选择了Obsidian。obsidian自从9月初使用以来了已将近两个月了，当初忘记写初体验了，现在补上一篇充分体验后的产品报告。
竞品比较当初本就抱着all in one的目的，想找一个功能全面的笔记软件，能满足我的“跨平台记录阅读”的需求，当时比较了市面上主流的几款笔记软件——Notion、Obsidian、印象、Flomo。当然还有幕布、、Bear、石墨、Logseq，但这些都因为精力有限，各种原因导致没能在一开始吸引我进行更深入的体验。
印象笔记印象笔记就纯纯炮灰🤦♂️，弹广告我就接受不了一点，各种功能都要付费，更其他俩个一比就是垃圾，特别是国产收购后就开始日渐臃肿发福。还是那句话“我本可以忍受黑暗，如果我不曾见过光明”。
FlomoFlomo的设计的核心理念是“卡牌笔记”，适合碎片化、片段性的文字记录，经过轻度体验不切我本人需求，但是其产品概念还是不错的，很有发展前途，或许将来我会使用。个人感觉flomo和anki联动一下或许能有更好 ...
Tailwind CSS初体验
还是把我想说的话放前面吧，对于独立React小项目的快速开发来说，Tailwind是值得尝试的，我也就仅仅讨论在我目前的状态下（苦逼大学生🤓，个人独立项目（没前端队友，没专业设计）），被拉去打比赛，最后还是“能者多劳”，前端的活最终还是一个人大包大揽🚬🚬🚬。
前言好久没写博文了，最近在努力从安卓转前端，一直都在学（技术力不够不配写博文）。看了如何在 React 中使用 CSS 样式 — How to CSS Style in React (robinwieruch.de)这篇文章，了解了下Tailwind Css，被其的高效惊喜到了。
我个人的感觉Tailwind是在传统的css上抽象了一层，一切优缺点都是有此带来的。不像是Sass，只是作为css的一个拓展超集，爱用就用，不用不用。
缺点团队配合本来奇怪为什么没看到什么主流项目在用，搜索了下主要争议点还是在-目前不适合团队配合，毕竟原子化CSS是学习成本的东西也没流行到成为一种规范，在需要多人配合中大型项目不好合作。目前这东西还得是公司自上而下的推行才有可能在团队项目里使用。这一点是不得不去考虑的，毕竟偏离主流的技术在大型项目 ...
C盘扩容
C盘扩容
核心理念就是将与C盘相邻近的磁盘彻底清空, 然后通过磁盘管理的拓展卷现实C盘扩容.
前言鄙人不才，分盘的时候C盘分的不够大，导致C盘一直处于爆红状态，遂借加装硬盘（当然如果内存够用可以不加）之机给C盘扩容一下。没想到遇到不少问题，于是有了这篇文章。希望能给有相关需要的xdm一定的帮助。
具体操作1.复制文件
打开磁盘管理器：右键任务栏的🪟windows图标
这是我改后的磁盘分区，如果你的C盘右边紧挨的磁盘(之后文章里默认是D盘)里没安装什么流氓软件（360,百度网盘之类的）,那你很幸运,很简单就能把目标完成了。
如果很不幸你像我一样安装了百度网盘,360zip,迅雷之类的会在后台偷偷运行的软件，在后面的删除文件环节你就得好好看了🤷♂️
分盘：右键D盘（我这里因为已经改好了，所有是G盘），点击压缩卷，分出足够空间，然后新加卷
转移资源：将D盘的资源全部复制到新加卷中
2.清空D盘
这是本篇文章的初始写作的目的，有些文件是真的逆天，无法正常彻底删除
接下来下内容根据本人的亲身体会，大致麻烦程度逐渐递增，致敬传奇耐删王🖖
I.普通文件直接删就完事了，一股 ...