说明
突然发现不管在干什么的时候,随时会有一些想法,这种时候我一般会写一些文字到一个txt里,有时候就保存下来到相关的文件夹中,为想法.txt。有时候就没保存。刚才突然想到可以写到博客上。
下面列出的想法,按照天进行组织。每天中某个时段集中做某件事时的想法,如果觉得有必要记录,就会单独列出一个小节。小节内容可能会被选择性的扩充为一整篇博客,如果这么做了,对应位置会有相应的博客链接。
想法
2025年9月13日
nanobanana
SynthID 水印:每个创作都包含 Google DeepMind 的隐形 SynthID 水印,确保负责任的 AI 使用,同时保持专业的视觉质量。
软件开发的术语
语义化版本、约定式提交
参见https://www.freecodecamp.org/chinese/news/semantic-versioning-and-conventional-commits/。
https://semver.org/lang/zh-CN/
https://www.conventionalcommits.org/zh-hans/v1.0.0/
持续集成和持续交付 (CI/CD)
GitHub Actions
瀑布开发、敏捷开发和DevOps
Docker
2025年9月12日
git默认对文件名大小写不敏感的处理
遇到问题以及解决的历程:
-
将含有仅仅是文件和目录名大小写更改的分支压缩合并到主分支上时,发现这部分更改没有被合并上去。(如,我在分支中将
Network/改为了network/,但合并后主分支上仍然是Network/)。询问AI,发现是因为git默认对文件名大小写不敏感的处理方式导致的。 -
执行类似下面的命令:
1 | :: 1. 配置Git区分大小写 |
- 在提交更改之后,准备切换回主分支,git向我报告了冲突,并阻止了切换。这时我强制切换回了主分支,删除了原本的压缩合并提交,然后重新进行了压缩合并,问题解决。
git config core.ignorecase false 这个配置项会影响本仓库中的所有分支与提交,使其都区分大小写。这对于跨平台协作,特别是在Linux等区分大小写的系统上工作时很重要。
让我想起了一年前搭这个博客遇上的git在识别中文时的乱码问题,显示的是类似 \346\226\207\344\273\266 这样的八进制转义序列(这个序列对应的中文为“文件”)。
使用squash and merge的原因和方式
自己在一个分支上频繁地进行提交是为了保存每次的进度方便回溯,不过提交到远程仓库时肯定不能这么多提交。每次自己的小提交也不必遵守严格的提交文本规范,方便回溯时查看即可,但是一次向远程仓库的提交需要规范的提交文本格式。
2025年9月11日
任务驱动式的学习法
我发现我只有在有强制任务时,才会去主动学很多东西。而之前那些什么所谓的自学,之所以没坚持下来,正是因为我不知道学了那些有什么用
我的爱干净、爱整洁的习惯促使我去重构代码,学到了架构设计理念
促使我去学习提交文本规范,分支命名规范等git工作流规范