[Git]Another git process seems to be running in this repository

-

     如標題，操作Git時，偶然間發生這個問題，想要使用 switch / checkout, 或是 commit 都是這個錯誤 "git did not exit cleanly (exit code 128)" ，此外還有一行提示 "Another git process seems to be running in this repository"，不多話，附上解法：

刪掉 .git/index.lock

收工。


參考: Another git process seems to be running in this repository - Stack Overflow

留言

張貼留言

這個網誌中的熱門文章

[C#] 無法載入檔案或組件 或其相依性的其中之一。 找到的組件資訊清單定義與組件參考不符。 (發生例外狀況於 HRESULT: 0x80131040)

-
圖片
如提，當專案使用 .NET Framework 時，多少會出現這個問題，尤其是多個專案使用同個套件，如果調整版本時，連帶的依賴套件也會變動，就會造成父子專案的套件版本不同，以下紀錄解決方式。 以下附上情境:  System.IO.FileLoadException: 無法載入檔案或組件 'System.Text.Json, Version=8.0.0.4, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' 或其相依性的其中之一。 找到的組件資訊清單定義與組件參考不符。 (發生例外狀況於 HRESULT: 0x80131040) 分析:       1. 系統認為套件要使用 System.Text.Json, Version=8.0.0.4     2. 但專案中使用的套件 不是  System.Text.Json, Version=8.0.0.4 解決方式:      1. 先確認 bin 裡面的套件版本是多少 。(看起來是 7.0.0)                2. 檢查 App.Config 或是 Web.Config 的套件版本是多少。(看起來是 8.0.4)                3. 檢查 .csproj 的套件版本是多少。(看起來是 8.0.4)                  4. 把  App.Config, Web.Config, .csproj 的版本都改成 7.0.0      5. 清除方案 > 重建方案     
Read more »

[VibeCoding] AI Vibecoding 的地基（上）：大型專案導入前的準備筆記

-
AI Vibecoding 的地基（上）：大型專案導入前的準備筆記 這篇文章記錄我在一個真實的大型 monorepo（後端數千支服務、前端數百個元件的 .NET + Vue 3 專案） 導入 AI 輔助開發的完整過程——蓋了什麼、為什麼蓋、踩過哪些坑、以及先後順序該怎麼排。 為了不洩漏真實業務內容，範例一律改寫成大家熟悉的 NorthWind（北風貿易） 資料庫情境，路徑也改成通用寫法，但架構、順序、數字都是真實測過的。 📖 系列文章・共 2 篇，這是上篇 下篇：五層架構的實作 Prompt——照抄就能用的版本 → 太長不看版 在大型專案放手讓 AI 改程式碼之前，需要先蓋五層基礎建設： ①靜態地圖 （讓 AI 找得到東西）→ ②閱讀紀律 （教 AI 怎麼查地圖，而不是整包讀）→ ③風格範本 （讓 AI 寫出來的東西像自己人）→ ④事實庫 （記錄程式碼本身回答不了的單一業務真相）→ ⑤深度研究筆記 （累積子系統級的來龍去脈，但要有防發散設計）。 前兩層先蓋、成本最低效益最高；後三層要等真實需求出現才動手，不要預先猜測。 起 沒有地圖的 AI，只會用最笨的方法找路 先講一個真實測過的失敗案例。任務是：「幫我追一支 API，看看改動它會影響前後端哪些地方」。 天真的作法是讓 AI 直接對整個 repo 下關鍵字搜尋、讀完相關檔案——聽起來合理，實際跑起來完全不是那回事。 真實測過的數字 同一個搜尋，因為沒有排除建置產物目錄，回傳結果裡混進了壓縮過的前端 bundle （單行超過五萬字元），總輸出超過 30 萬字元 ，跑了 兩分鐘還沒結束 。 而真正相關的命中，其實只有 5 個檔案、不到一千字 。 問題不是 AI 不夠聰明，是它跟人一樣——沒有地圖，只能把整座城市走一遍。專案規模一旦到了 數千支後端檔案、數百個前端元件，「...
Read more »

[VibeCoding] AI Vibecoding 的地基（下）：五層架構的實作 Prompt

-
AI Vibecoding 的地基（下）：五層架構的實作 Prompt 上篇談了為什麼要蓋這五層基礎建設、順序該怎麼排。這篇是實戰版——每一層實際該怎麼下 prompt，內容直接照抄可用（把 <...> 換成你專案的實際內容即可）。範例延用上篇的 NorthWind 情境。 📖 系列文章・共 2 篇，這是下篇 還沒讀過上篇？先看：大型專案導入前的準備筆記 → 先講清楚：這篇刻意不談 git 版控 這五層裡有些東西該不該進版控、要不要跟團隊共用、`.gitignore` 怎麼設——每個團隊的答案都不一樣， 跟公司規範、團隊人數、內容機敏程度都有關。這篇的 prompt 全部略過這一段， 執行前你要自己先想清楚這個決定。 1 Layer 1：靜態地圖產生器 最先做這個——地基，成本最低、最快看到效果。 這支 prompt 的目標不是要 AI「一次生出完美地圖」，是要它先跟你確認專案特性， 再幫你寫一支 可重複執行的產生器 （純程式掃描，不靠 AI 現場生成）。 我想幫這個專案（後端 <技術棧，例如 .NET 8> + 前端 <技術棧，例如 Vue 3 + Vite>） 建立一套「AI 可以按需查詢」的語意地圖，取代目前 AI 每次都要整包掃描原始碼的作法。 請先讀過專案結構，不要馬上動手寫程式，先跟我確認以下幾件事： 1. 後端的路由慣例、DI 註冊慣例、資料存取方式（ORM 還是手寫 SQL） 2. 前端是 SPA 還是 MPA、有沒有用到「元件自動全域註冊」這類框架魔法 3. 專案規模大約幾個檔案，決定要不要把反向索引拆成 JSON 確認過後，幫我寫一支可重複執行的產生器，輸出到 <你的路徑，例如 .ai/maps/> 底下， 至少要包含： - PROJECT_MAP：專案總覽 + 檢索指南（「你想做什麼事，該查哪一份」的對照表） - FEATURE_SLICES：以「功能」為單位，一次列出前後端所有相關檔案 -...
Read more »