約定式提交 Conventional Commits

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
  1. fix: fix 類型的 commit 表示修正了某個 bug;對應到 SemVerPATCH
  2. feat: feat 類型的 commit 表示增加了一個功能;對應到 SemVerMINOR
  3. BREAKING CHANGE: 表示重大變更並且在 commit 的 footer 註記 BREAKING CHANGE 且一定要全部大寫或是再 type/scope 之後加上 ! 標記;BREAKING CHANGE 可以是任何類型的 commit 的一部分;對應到 SemVerMAJOR
  4. 除了 fixfeat 也可以有其他類型的 commit,例如:
  • build: 與建置系統或外部依賴項有關的更改。
  • ci: 對 CI 配置文件或 script 的更改。
  • docs: 文檔相關的更改。
  • refactor: 代碼重構。
  • perf: 效能相關的改進。
  • style: coding style 的調整。
  • test: 新增或修改測試。
  • revert: 回復之前的 commit。
  • chore: 雜項更改,不包含任何 source code 或 test 的更改。
  1. scope: 用於描述 commit 影響的範圍,例如:routercomponentitem ui...。
  2. description: 用於描述 commit 的目的,最好簡潔且清楚。
  3. body: 用於描述 commit 的詳細內容,可以包含更多的資訊。
  4. footer: 用於描述一些額外的資訊,例如:BREAKING CHANGEIssue number...。

Ref:

Read more

Debug Story

Debug Story

Ref: * 寫程式不是輸出,是內化 * Vibe Story:用敘事智能為程式碼注入生命,簡化維護 這篇主要是想紀錄一下看了Ruddy 老師的文章後想做的事情,雖然通篇的重點不是在我想做的這件事,但因為Ruddy 老師的這篇文章讓我覺得以後在排除 Bug 的時候應該要做這件事才對。 以下的內容是擷取 Ruddy 老師的內容(部分修改) 1. 記錄搜尋路徑與嘗試過的假設 => 我以為是 state 沒清,但發現是 effect 未執行 2. 為錯誤進行分類,然後標註成概念 => 這是 mutable state 的副作用問題 3. 寫一段描述該段程式的情境與原則 => Vibe Story 該段程式的情境與原則可以參考一下的要點撰寫: * 場景(Context):描述程式碼的背景與需求。 * 目標(Goal):說明功能目的。 * 挑戰與迭代(Challenges &

By Mars
Claude Code Status line on Windows

Claude Code Status line on Windows

Claude Code 在大家軍備戰發布了 Status line 這個功能,讓使用者可以在 Claude Code 的輸入框下方自訂自己想要的訊息,官方提供幾個方式可以實現這功能(Bash, Node.js, Python),最後我選擇使用 Node.js。 趁著週末寫玩了一下,剛開始照著官方文件做,結果啥都沒顯示出來,接著叫 Claude Code 幫我做,他說成功了,結果還是啥都沒有...最後才發現可能是官方提供設定檔案的問題 { "statusLine": { "type": "command", "command": "~/.claude/statusline.sh", "padding": 0 // Optional:

By Mars