写这个项目的时候本来用来理清需求和思路， 后来稍微添了点就顺便出来一份规范点的易上手文档，仅供参考
存储技术文档后端项目：你可能需要的文档：
补充后端基础知识 https://youtu.be/XBu54nfzxAQ?si=0Ce6-dFM4nokSlwb
（JWT入门）Spring Boot 如何集成JWT实现Token验证https://cloud.tencent.com/developer/article/2245008
Spring Boot 零基础快速入门https://kucw.io/blog/springboot/1/
Spring Boot Restful API介绍https://kucw.io/blog/springboot/22/
spring与数据库的交互方式 https://dimitri.codes/difference-spring-data-jdbc-jpa/
要求：
系统需求: 支持 Markdown 文件的上传、元数据存储以及权限化的访问管理
用户与权限: 支持基础的JWT认证, 角色权限可以分成User/Admin
...
为防止init_commit的重复创建，应把init_commit写入.gitlet,一次创建，其他地方直接引用
sha接受byte数组，需要readContents先转化为 byte[]
暂存区分tobeadded和tobeDeleted两种
获取timeStamp:
123Date now = new Date();Date inittime = new Date(0);//the init time 'Thursday, 1 January 1970'
转换得到String类型的timeStamp
1234static String dateToTimeStamp(Date date) { DateFormat dateFormat = new SimpleDateFormat("EEE MMM d HH:mm:ss yyyy Z", Locale.US); return dateFormat.format(date); }
对于每个commit，其hashID通常这样...
祝生物钟倒转的三天新年快乐🎆
基于上次的状态机：
之前说过我当时写出这个状态机时，是从最初的if-else重构过来的。
所以当时新接触这个状态机时，我也尝试过从if-else的角度去反向理解这个教简单的状态机，然后误打误撞就发现这其实就是分层状态机（HFSM）的思想
事实上把陌生和友好两个状态合并起来就是对应着本的’false’,而逃跑状态则对应原本的’true’
或者换句话说： if-else本身就是一种广义上的二元状态机
同时，在我们的这个例子中，我们用抽象的思维看，其实’陌生和友好’本身也是一个二元的状态机，它作为一个状态机被封装成了大的if-else二元状态机下的一个状态。
也就是说：状态机中的状态可以是另一个状态机
这也就是分层状态机HFSM
我们把之前的FSM重构为HFSM,它总体上大致长这样
hfsm的运行逻辑是先进入父状态机，然后根据过渡条件选择对应的子状态机，再运行子状态机并进入子状态机下的状态。
各层级内需要做好抽象屏障，子状态机的状态不应与父状态机的状态存在任何通信。
以下是HFSM的一个通用模型
对于我们这个例子：
父状态机是‘逃跑-不逃跑’...
本篇基于Modo在写Flee On Sight时的感想对于较复杂的状态判断，有一种更好的方法为什么不用if-else ?:首先，对于大量子状态的判定会在这种boolean的判定中越来越冗长，如果是写了辅助方法来包装则会有层层嵌套的问题，而且对于几个不相关的子boolean强行包装成一个辅助boolean会导致可读性下降，最终整体的状态判定会很难维护
同时，最最危险的一点在于if-else的各种子状态判定一旦存在耦合，会变得非常非常麻烦举个例子，我们判断一只羊是否应该逃跑（记为isFleeing）, 假设isFleeing这个boolean由两个子状态A和B来判定：
A 代表空间判定（包含视角判定，空间距离判定）
B 代表食物引诱判定（即羊不应在受吸引时逃跑）
或许这个时候你会想这么写
123if (A && B) { isFleeing = true;}
然而事实是B中实际上嵌套了A中的部分空间逻辑🤓，这意味着 A 与 B 并不是两个独立条件，这就非常头疼了
通常接下来你有两种常规的处理这玩意的思路：
第一种是打补丁：在A...