说明

突然发现不管在干什么的时候，随时会有一些想法，这种时候我一般会写一些文字到一个txt里，有时候就保存下来到相关的文件夹中，为想法.txt。有时候就没保存。刚才突然想到可以写到博客上。

下面列出的想法，按照天进行组织。每天中某个时段集中做某件事时的想法，如果觉得有必要记录，就会单独列出一个小节。小节内容可能会被选择性的扩充为一整篇博客，如果这么做了，对应位置会有相应的博客链接。

想法

2025年9月15日

找实习

强化学习的老师。

计算机新技术专题课程可以认识很多老师。

https://directionai.cn/html/index.html，下方contact部分。北理工高扬。认识西湖大学张岳

VMware与网络连接

VMnet0：桥接网络（Bridged）
VMnet1：仅主机网络（Host-only）
VMnet8：NAT网络（Network Address Translation）

ping 命令通常不走 HTTP/HTTPS 代理。它直接发送 ICMP 包，绕过了代理设置。

Clash for Windows的TUN模式能够接管所有流经该接口的网络流量，然后将这些流量根据代理规则进行转发。使用TUN模式后，VMware中的虚拟机直接使用NAT模式，也无需进行任何代理配置，即可顺利访问外网。

2025年9月14日

科学上网

Clash

https://clash.wiki/

https://github.com/clash-download/Clash

https://github.com/vernesong/OpenClash

https://ikuuu.de/user

V2Ray

https://github.com/2dust/v2rayN

2025年9月13日

git子模块

GitHub中我会见到一些仓库列标中，有一个特殊的文件夹，图标有一个右箭头。点进去，会跳转到另一个仓库的某一次提交。这实际上是git的子模块（git submodule）功能。

nanobanana

SynthID 水印：每个创作都包含 Google DeepMind 的隐形 SynthID 水印，确保负责任的 AI 使用，同时保持专业的视觉质量。

软件开发的术语

单一可信来源（single source of truth，SSOT）

语义化版本、约定式提交

https://semver.org/lang/zh-CN/

https://www.conventionalcommits.org/zh-hans/v1.0.0/

semantic-release是一个自动化版本管理和发布工具，基于语义化版本控制（Semantic Versioning）和约定式提交（Conventional Commits）规范。它通过分析提交信息来确定版本号的更新类型（主版本、次版本、修订版），并自动生成发布日志和更新包。

常用插件：

  • @semantic-release/commit-analyzer：分析提交信息，确定版本号的更新类型。

  • @semantic-release/release-notes-generator：根据提交信息生成发布日志。

  • @semantic-release/changelog：将生成的发布日志添加到项目的CHANGELOG文件中。

  • @semantic-release/npm：将新版本发布到npm注册表。通常用于需要发布到npm的JavaScript项目。

  • @semantic-release/git：将更新后的CHANGELOG和版本号提交到Git仓库。会多创建一个提交，包含更新后的CHANGELOG和版本号。

  • @semantic-release/github：将新版本发布到GitHub Releases。

  • @commitlint/config-conventional：一个预设配置，基于Conventional Commits规范，用于检查提交信息是否符合规范。

  • @commitlint/cli：命令行工具，用于在提交时检查提交信息是否符合规范。

  • husky：一个Git钩子工具，可以在Git操作（如提交、推送等）前后执行自定义脚本。常用于在提交前运行commitlint来检查提交信息。

上述的自动化提交内容检查和版本发布，都依赖于Node.js环境，因此需要在CI/CD的运行环境中安装Node.js。为添加这些功能，需要在package.json中添加相应插件，之后运行npm install安装这些插件。之后，需要在项目根目录下创建一个.releaserc文件，配置semantic-release的行为。commitlint同理。

0.0.0-development版本

持续集成和持续交付 (CI/CD)

GitHub Actions

瀑布开发、敏捷开发和DevOps

Docker

2025年9月12日

git默认对文件名大小写不敏感的处理

遇到问题以及解决的历程：

  1. 将含有仅仅是文件和目录名大小写更改的分支压缩合并到主分支上时，发现这部分更改没有被合并上去。（如，我在分支中将Network/改为了network/，但合并后主分支上仍然是Network/）。询问AI，发现是因为git默认对文件名大小写不敏感的处理方式导致的。

  2. 执行类似下面的命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
:: 1. 配置Git区分大小写
git config core.ignorecase false

:: 2. 强制Git识别大小写更改
cd /d "C:\Users\Timothy\Desktop\CSFI\prj\RemoteExpert"
git rm -r --cached client/src/Business
git rm -r --cached client/src/Network
git add client/src/business
git add client/src/network

:: 3. 处理具体的文件重命名
git rm --cached client/src/business/models/Ticket.cpp
git rm --cached client/src/business/models/Ticket.h
git rm --cached client/src/business/models/User.cpp
git rm --cached client/src/business/models/User.h
git add client/src/business/models/ticket.cpp
git add client/src/business/models/ticket.h
git add client/src/business/models/user.cpp
git add client/src/business/models/user.h

:: 4. 提交更改
git add -A
git commit
  1. 在提交更改之后，准备切换回主分支，git向我报告了冲突，并阻止了切换。这时我强制切换回了主分支，删除了原本的压缩合并提交，然后重新进行了压缩合并，问题解决。

git config core.ignorecase false 这个配置项会影响本仓库中的所有分支与提交，使其都区分大小写。这对于跨平台协作，特别是在Linux等区分大小写的系统上工作时很重要。

让我想起了一年前搭这个博客遇上的git在识别中文时的乱码问题，显示的是类似 \346\226\207\344\273\266 这样的八进制转义序列（这个序列对应的中文为“文件”）。

使用squash and merge的原因和方式

自己在一个分支上频繁地进行提交是为了保存每次的进度方便回溯，不过提交到远程仓库时肯定不能这么多提交。每次自己的小提交也不必遵守严格的提交文本规范，方便回溯时查看即可，但是一次向远程仓库的提交需要规范的提交文本格式。

2025年9月11日

任务驱动式的学习法

我发现我只有在有强制任务时，才会去主动学很多东西。而之前那些什么所谓的自学，之所以没坚持下来，正是因为我不知道学了那些有什么用

我的爱干净、爱整洁的习惯促使我去重构代码，学到了架构设计理念

促使我去学习提交文本规范，分支命名规范等git工作流规范