焦糖酒的妙妙屋

前言以下所有分析皆是从我的视角出发，探讨下我现行局势下觉得最有可能的实现且有未来发展前景的技术方案。由于本人没有啥开发经验，所以多是纸上谈兵，仅仅记录和分享下我个人想法。 移动App的开发模式：在技术选型上，其实好久没这么犹豫过了，最近几天学到React Native，但迟迟没有全身心投入，就是在疑虑其和市面上的其他技术相比是否值得学习。目前移动应用开发有以下三条主要道路（原生 H5 混合）外加一个国内特色的小程序 开发模式 典型应用场景 优点 缺点 代表技术 原生开发 高性能需求、UI/UX要求严格的场景 性能高，完整API支持，用户体验佳 开发和维护成本高，无法跨平台 Android SDK, iOS SDK, UWP H5开发 跨平台、快速迭代、内容动态更新的场景 一次开发，多平台适配，更新简单 性能受限，功能受限 HTML, CSS, JavaScript, JSCore, V8 混合开发 跨平台、调用原生功能、性能要求较高的场景 跨平台，调用原生功能，维护成本低 性能较原生略差，复杂功能开发受限 React Native, Weex, uni-a ...

前言这估计就是本系列的最后一篇文章了，我将在这篇中为系列做个总结，探讨一下git的未来，分享下我洋洋洒洒写了这么多篇文章下来的个人感悟。 Git的未来Git不仅是一个强大且灵活的分布式版本控制系统，而且在过去的十几年中不断发展。其未来发展方向体现在两大方面：核心功能的改进和与生态系统中其他工具的整合。 Git的持续发展随着技术的发展和用户需求的变化，Git的开发者们不断对其进行优化和扩展。比如，近年来的更新中引入了以下改进： 性能优化：为了应对超大规模代码库的管理需求，Git引入了诸如partial clone（部分克隆）和sparse checkout（稀疏签出）等功能，这些功能让开发者能够选择性地检出代码，提高了效率。 安全性提升：随着计算机算力提升，SHA-1算法安全隐患的逐渐增加，Git逐步引入了更强的哈希算法（如SHA-256），以保证数据的安全性和完整性。 用户体验优化：Git的CLI体验也在逐步改进，通过更丰富的输出提示和更多的人性化选项，使得命令的执行更为直观，降低了初学者的使用门槛。 未来，Git可能会继续在以下方面优化： 更加智能的合并和冲突解决工具：Git社 ...

前言这篇文章是我昨天晚上躺在床上突然想起来要写的，感觉Git的Git - GUI Clients像是GitHub Desktop还是值得讲一讲的。Git官网上推荐了39款GUI客户端，我就挑几款介绍一下，主要还是带大家了解一下有这东西。此外，由于之前提到过微软收购了GitHub，也在自家IDE-VScode等中官方支持了一些可视化插件，还是挺好用的。 Git GUI工具以下是几款Git GUI工具的介绍： 1. Sourcetree | Free Git GUI for Mac and Windows 开发者：由Atlassian开发，免费使用。 支持平台：Windows、macOS。 特点： 详细的提交历史可视化：Sourcetree展示了清晰的提交历史图，帮助用户追踪项目进展。用户可以直观地查看提交、分支和合并情况。 分支和合并管理：简化了分支和合并操作的复杂性，通过图形化的分支树状结构，使得Git操作更直观。 子模块支持：能够管理多个子模块（或仓库），方便对大型项目的依赖进行管理。 适用场景：适合需要高效管理分支和分布式项目的用户。 优缺点： 优点：界面详细、功能丰富、免费。 ...

前言这个子模块（submodule） 也是我在写这章的时候才知道的东西😁，也是把书读厚了，学到新东西了。我也没实践过但是我猜啊，比如在React Native的开发过程中，除了用RN的那一套前端代码，在需要用到某些RN无法实现的功能时，需要进行原生开发，这时候这一个项目同时又前端的代码（typescript）、Android的代码（kotlin）、ios的代码（swift），利用这个子模块（submodule）就可以在这个大项目中又对三块截然不同的代码进行细分管理。嘻嘻，讲都讲到这了那我就简单提提我设想的技术路线，我之前学过一年的安卓开发，期间也接触了ios的开发，也是发现了原生开发的磨叽，想着能否实现跨端，于是发现了React Native，便开始从头来过，走前端路线三件套、React、ts、tailwind等等前端技术，最后过渡到RN，在移动端深入下去🤪🤪🤪。 子模块（submodule）Git中的子模块（submodule）功能主要用来管理一个仓库中的多个独立的项目代码，便于将其作为另一个项目的依赖并一起管理。子模块适合那种多项目组合的场景，比如在一个大项目中嵌入另一个独 ...

前言这篇文章我们来聚焦.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的一些常用指令，然后挑我感兴趣的一些指令进行详细解析和拓展。这章将不像前一章那样关注概念的理解，而是逐渐将重心转移到应用上去。 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是如何实现分布式这件事情的，或许会捎带嘴的提一下Github之类远程托管仓库平台的兴起。 Git分布式版本控制的实现Git的分布式版本控制系统与传统的集中式版本控制（如SVN）相比，有几个关键的不同点。Git的架构使得每个开发者的本地仓库不仅仅是一个工作副本，而是一个完整的仓库，包含了项目的所有历史记录。这种设计带来了灵活的协作模式和极大的独立性。以下是Git分布式版本控制的一些关键点： 1. 本地完整仓库 完整性：在Git中，每个开发者的本地仓库都是项目完整的历史副本，包括所有的提交记录、分支、标签等。这意味着，开发者在本地可以进行几乎所有的操作，比如查看历史、创建分支、提交代码等，而不需要连接到远程服务器。 独立性：开发者不需要依赖中央服务器，甚至在没有网络连接的情况下也可以正常工作。这种离线工作的能力在许多场景下非常有用，尤其是在网络不稳定的环境中。 优势：即使没有网络连接，开发者也可以进行提交、分支创建、查看历史等操作，而不依赖于中央服务器。 2. 数据完整性和安全性 ...

前言呜呜呜🫡🫡🫡也是到第三篇了，我打算在该篇主要讲git的本地分支的相关内容，而远程分支则留给下一篇分布式版本控制。由于.git/ref/文件下还有tag，那就同时补充介绍一下之前一直忽视的tag吧，我个人感觉是没啥用。其实这一块内容我6月份的一篇文章中已经讲解了具体的命令操作（[[Git本地与远程]]），本篇则更加关注于概念和原理。 分支模型Git 的分支模型是一种灵活且高效的版本控制机制，通过指针和哈希引用管理分支，能够轻松支持并行开发、功能隔离和协作。这种实现方式既节省空间，又使得分支操作非常迅速。以下是 Git 分支模型的详细讲解： 1. 分支的基本概念 分支是 Git 的核心特性，它允许你从主线代码中分离出独立的开发路径。分支的创建、切换和合并速度很快，使得开发人员可以并行进行新功能的开发、修复 bug 或实验，而不会影响主分支。 默认情况下，Git 会有一个主分支，通常称为 main 或 master（弗洛伊德之死黑命贵运动席卷全球后由于master有主人的意义，为避免种族歧视嫌疑，git现在默认的主分支名改为了main，github也是如此，当然分支的默认名称可以通 ...

前言理解了上篇文章的两大模型（快照和不可变对象）后，让我们看看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起源背后的一些故事背景，从这篇开始将逐渐讲解Git的设计理念，包括分布式控制、快照管理、不可变对象模型和分支模型。其实上述概念都不是孤立的，在讲解中会发现它们是相辅相成的有机整体，实现1+1大于2的效果。接下来预计会按照快照模型与不可变对象模型、分支模型、分布式控制这样的顺序讲解，其用意到后面自会明了。本人总是从中能看到区块链的影子，之后会引入区块链的相关知识进行补充，也当是拓展了🫠。 快照存储模型快照模型与传统的版本控制系统（如SVN等）不同。传统系统通常基于文件的差异（diff）来管理版本，而Git则使用快照（snapshot）的方式来记录项目的每个版本。 快照模型的主要特点： 快照而非差异： Git会在每次提交时保存项目的当前状态，称为“快照”。这意味着每次提交都是整个项目的完整状态，而不是仅保存变化部分。 只保存变更： 虽然每个提交实际上是一个完整的快照，但Git为了节省空间，内部实现上只存储更改过的文件的内容，而未改变的文件只保存一次。这使得Git非常高效。 对象存储： Git将文件和目录的快照存储为对象，每个对象都有一个唯一的SHA- ...