如何於 Kubernetes 內動態掛上一個除錯專用容器
https://medium.com/datamindedbe/debugging-running-pods-on-kubernetes-2ba160c47ef5

Kubernetes 管理人員通常要對 Pod 進行除錯時，很常會使用 kubectl exec 等指令直接跳到 Pod 裡面去檢查當前的運行狀況。
kubectl exec 可以說是每個 Kubernetes 玩家都必定會且非常被大量使用的指令，但是該指令實際上會有一些限制

進去後的身份與指令實際上是仰賴於最初運行的容器狀態
由於上述的限制，所以到底有哪些指令可以運行非常仰賴當初打包 Image 使用的基底與指令，譬如使用 alpine 與 scratch 可以使用的指令與安裝方式就有非常大的不同，甚至有些環境連基本的 shell 都沒有，這種情況下除錯
此外現在愈來愈多的容器會以 non-root 的方式去執行，但是除錯的除錯的時候就是需要使用 root 來進行一些指令操作除錯，因此 kubect exec 這種直接繼承本來使用者身份的方式對於除錯來說稍嫌無力
為了解決這個問題， Kubernetes 官方提供了 kubectl debug 的指令，該指令可以動態的創建一個暫時 Container，並且將該 Container 掛載到任何選擇的 Pod 來進行除錯，該短暫 Container 可以共享既有的 Process namespace, network namespace 等，同時其所運行的 userID, groupID 則不受本來運行之限制，且該短暫 Container 的 Image 也可以自行選擇，所以就可以掛上自己常用的除錯 Container 來除錯。
該指令目前的缺陷就是預設的情況下無法共享 mount namespace，因此如果除錯的過成需要去觀看檔案系統的話，這方式會有點無力，因此文章提到可透過 patch 的方式動態的去修改 Pod spec，將 volumeMount 的資訊填上，該流程也被第三方包成一個 superdebug 的指令

此外還有其他工具如 kpexec 等都是想要強化既有 kubectl exec 的缺陷與限制

Container Runtime 抓取 Container Image 的過程介紹
https://itnext.io/exploring-oci-container-registries-by-use-case-pull-a-public-image-from-kubernetes-3d2d4267201c


過往使用 Container runtime (Docker, Containerd, CRI-O) 時，大家總是會學習到 Contianer Image 本身有快取的機制，能夠透過快取機制減少不必要的檔案抓取。此外 Kubernetes 內也有提供 ImagePullPolicy 等機制來設定抓取 Image 的策略。
本篇文章稍微探討了一下抓取 Image 中間的過程，包含

先從遠方 Repository 伺服器獲得該 Image 的一個小ID
確認本地有沒有該 ID 的 Image，有的話就代表本地擁有，不需要重複抓
若本地沒有，就代表需要抓取該 Image
接者就會去抓取該 Image 的第二層資料，該資料內會提供該 Image 用到的所有 layer 資訊
接下來每個 layer 獨自判別，若該 Layer 本地已經有快取，那就使用本地資料，否則從遠方抓取
從這個流程來看，本地沒有 Image 去遠方抓取並不代表是真的要去遠方抓取，若 Image Layer 本地已經有的情況下，部分 Layer 的抓取也是可以加速的，這意味如果以後要提高 Image 抓取的內容，除了探討 Image 本身的設定外，也許 Image Layer 的部分也值得研究看看，是否可以透過這些機制來降低每次抓取新版所需要的資料量與時間。

如何於 Bash 環境中產生有結構的 log
https://medium.com/picus-security-engineering/structured-logging-in-shell-scripting-dd657970cd5d

本篇文章作者探討如何使用 tail + bash redirection 等的方式來改善 bash script，讓檔案的輸出更有結構且能夠將個人的除錯 log 與指令的輸出有一個比較好的結構去分離，甚至可以加上不同的 log level，同時這些 log 可同時存放於檔案與 stdout 中。

為了讓 bash 運行過程的輸出可以同時寫到檔案與 stdout，作者於檔案內透過 tail 與 exec 的方式，後者會將該 script 內所有的 stdout/stderr 都導向特定檔案，同時透過 tail 的方式將檔案讀出給轉向 stdout 讓指令呼叫者也可以觀察到 log 的輸出。
有了基本機制後就是撰寫各種 wrapper function 來處理自己輸出的檔案格式。

如何透過幾種常見的 Image Cache 工具來加速 Kubernetes 內抓取 Image 的速度

https://medium.com/itnext/improve-container-image-availability-and-speed-with-caching-in-kubernetes-870fa7bfa1ed


Kubernetes 內應用程式從部署到真正運行中間所消耗的時間，有一段是仰賴於節點要花多少時間去抓取 Image，對於大小只有幾百甚至幾十MB 的應用程式來說
抓取 Image 的時間都非常的快，但是當有 Image 本身大小達到GB等級，同時節點上同時有多個 Pod 同時下載，這時候若超出平行下載限制時就會發生排隊等待的現象
最後就會導致部分應用程式花過長的時間才起來

這些流程對於更新應用程式來說也許不算什麼，畢竟既有的服務還在運作，但是對於節點掛掉或是 drain 的過程來說就會有比較大的影響，因為當下沒有服務正在運行，因此要如何更快速的
讓 Pod 被叫起來是一個值得關注的議題

本篇文章專注於如何加速 Image 下載的流程，介紹了下列幾個開源專案，每個專案都用不同的方式與架構來加速，包含
1. Kube-fledged
2. kube-image-keeper (kuik):
3. kubernetes-image-puller
4. Tugger

概念上大同小異，但是實作方式與目的都有些許不同

回顧 2023 年 Kubernetes 環境下的各種 Vulnerabilities

https://www.armosec.io/blog/kubernetes-vulnerabilities-2023/


根據統計，2019到2023 這幾年來看， Kubernetes 相關的 Vulnerabilities 數量幾乎翻了一倍，去年大概有 60 多條左右
這些 Vulnerabilities 大致上可以分成 Kubernetes 本身的問題以及相關生態系整合的問題，其中
1. Kubernetes 本身大概 11%
2. Cilium: 9%
3. ArgoCD 12%
4. Kyverno: 11%
5. KubePi: 6%
6. Others: 51%

作者從中整理了這些漏洞並且分類，可以分成下列幾項
1. Users can escalate into admin privileges by creating pods or persistent volumes on Windows nodes.
2. Users can launch containers and bypass the mountable secrets policy.
3. Users are able to bypass container image restrictions.
4. Pods can bypass the enforcement of the seccomp (secure computing mode) profile.
5. This entails improper privilege management in SUSE Rancher.
6. This entails improper authentication in Capsule Proxy, which leads to privilege escalation.

後兩者與特定工具有關，其餘前面四個類別也都有對應的 CVE 紀錄，總結來說隨者 Kubernetes 的應用愈來愈廣泛，資安的重視程度也要隨之提升，對團隊來說除了資安管控外，如何讓管理與開發不同的團隊能夠一起合作來提升資安風險也是另外一個重點，畢竟過多的限制有時候會對開發人員帶來過多的不便。

使用 SimKube 這套工具來模擬與回放 Kubernetes Cluster 的各種事件

https://thenewstack.io/simulate-kubernetes-cluster-behavior-with-simkube/


隨者 Kubernetes 落地的普及，也有不少團隊與工具探討如何用簡易的方式去模擬 Kubernetes 讓開發團隊能夠有更方便的方式去評估應用程式的效果與效能
譬如 KWOK (Kubernetes Without Kubelet), KubeMark, Virtual Kubelet, KCP 以及本篇文章探討的 SimKube

SimKube 希望能夠於目標 K8s 上去記錄與收集相關事件，並且於模擬叢集上去回放與模擬這些行為，特別是問題發生時，能夠將這些事件重新回放讓團隊有機會去檢視真正的問題原因
作者舉例 SimKube 的一個使用情境就是去評估 Scheduler 的運作行為，看看哪種演算法與參數最後調度出來的結果是最適合的，透過這類型的模擬工具可以讓開發人員不需要有一個很龐大的實際叢集來測試，反之透過一台筆電上就可以去模擬這些行為。

https://www.cncf.io/blog/2024/01/12/root-cause-chronicles-connection-collapse/

P90 Latency 飆高的除錯經驗談


作者於本篇文章探討一個 event 發生時的除錯情況，該 event 發生來自於 Application P90 的 Latency 過高，該 Latency 大約為 9.2 秒左右，這使得所有 client 產生 timeout 然後功能都無法正常使用，接者 user 開始各種抱怨網頁無法瀏覽，訂單無法查閱等嚴重事項。

團隊接收到問題後，就開始排查各種可能性，首先透過 Prometheus + Grafana 觀察 Latency 飆高附近的其他資料，譬如 ops/sec 的資料，但是整體數值預期內，沒有特別明顯的問題，此外同步觀察由 Loki 部署的 Logging 服務，也沒有看到任何的有用的錯誤訊息，觀察問題的同時，先嘗試同步透過修改前端的 timeout 來暫緩使用者的問題。

接下來開始觀察整個流程中是否有哪些元件最近有進版升級過，會不會是什麼新引入的 Bug 所導致，不幸的是兩天內都沒有任何新版本上線，最後先透過 Kiali 服務來觀測叢集中所有被 istio 掌控的流量走向，觀察到流量與特定的服務有關，最後就開始請開發人員加入戰情室一同研究。
最終各種合作除錯下，找到問題點是後方 Database MySQL 的 maxconnection 踩到上限，因此所有新的連線都沒有辦法被處理，全部卡在等待，因此部分連線請求就開始失敗，然後一路回傳回去。

團隊針對這次的事件也學習到相關經驗，並且列出下列改善的方向
1. 前端的程式碼針對 timeout 的部分可以有更多調整，秒數可以拉大一些
2. 最前線處理使用者問題的工程師基本上對於整個 end-to-end 的架構都不理解，因此回報問題時沒有辦法提供太精準的細節
3. Istio 搭配的 Kiali 沒辦法顯示 External Service 的資訊，這使得判讀時會產生混淆
4. MySQL 沒有送出對應的 alert 來告警 connection 快滿或是已經滿的情況
5. database 的調整需要改善，最初採用預設值但是明顯不夠用

https://www.cncf.io/blog/2024/01/18/new-year-new-skills-kick-off-2024-with-cncf

CNCF 官方簡述過去針對使用者調查的清單中顯示，回應者普遍對 CNCF 這領域有更多技術需求，特別是技術人員的能力培養，因此 CNCF 本身今年針對這些訓練課程以及相關證照都有些許展望
訓練部分
1. Cloud Native Fuzzing Fundamentals
2. Etecting Cloud Rintime Threats with Falco
上述兩個課程主要都是跟資安相關，隨者愈來愈多的架構導入與整合，資安的重視程度愈來愈高，因此需求人才也多

證照部分也提供了兩個新的證照
1. Certified Argo Project Assciate (CAPA)
2. Cilium Certified Associate (CCA)

這兩個證照與專案有非常密切的關聯性，其中 CAPA 涵蓋的是整個 Argo 生態系，這包含了 Argo CD, Argo Rollout, Argo Workfow 以及 Argo Events。後者則是基於 eBPF 的 CNI 專案 Cilium

此外去年九月開始所推行的 Istio Certifited Associate (ICA) 與相關訓練課程也是目前很多環境都需要的一個技術，隨者 istio 專案的畢業，估計今年會採用 istio 的使用者數量會增加，而隨之而來的複雜性則不可避免，如何掌握更多知識以便未來有能力除錯則是每個導入 istio 的使用者都需要注意的。

使用 kdump + crash 揭露 Kernel Crash 的原因

https://medium.com/@idan7h/demystifying-kernel-dumps-on-openshift-96177579f8f2

本篇文章雖然是說基於 openshift 去搭建，不過重點都是 Linux 節點本身，因此上層是用麼方式搭建 Kubernetes 完全不影響。
對於 Kubernetes 維運來說，若問題是跟 Pod 有關時，大部分都會從 K8s API 出發去檢視各種資源的狀態來評斷問題，但有時候問題可能會是跟節點有關，這種情況下要除錯就相對麻煩，畢竟要直接進入到節點本身去存取與除錯，此外當節點本身因為 kernel crash 導致整個掛點不能使用時就更麻煩，雖然重啟節點之後就可以重新加入回 K8s 內繼續服務，但是要如何找出根本原因並且避免則是麻煩的事情。

文章內提及可以使用 kernel dump (kdump) 的方式讓 kernel 預留部分 memory 來紀錄當 kenrel crash 時當下 kernel 的狀態，並且之後使用 crash 這種工具來檢視紀錄並嘗試從中找到導致 kernel crash 的原因。
文章內也有提及可以透過某些 /proc 底下得參數來主動觸發 kdump 藉此熟悉與練習相關工具的使用。

7 個 Diagrams as Code 的工具
https://medium.com/@icepanel/top-7-diagrams-as-code-tools-for-software-architecture-1a9dd0df1815


不論是微服務, Kubernetes 或是分散式架構的崛起，如今的軟體設計架構愈來愈追求各種高可用性與效能，整個系統架構設計上趨向複雜，已經不是過往單體式應用程式可以用一兩句話就描述清楚的架構，因此系統架構設計與 review 時如何能夠清楚地將架構展示出來讓眾人有一個共同的概念去檢視就是一個所有簡報者都必須要準備的素材。

文章列出七種不同可以讓你以程式碼的方式去描繪各式各樣 Diagrams 的工具，這些工具有的會使用自行撰寫的語言(DSL)，有的則是基於 YAML 等各種格式，再搭配工具就可以將描述檔案給轉換為最後的架構圖，採用 As Code 的好處就是這些架構都可以透過 git 等版本控制的方式來控管，這樣工程師就可以用習慣的方式去保存這些版本的演進，而減少看到各種投影片的 v1, v2, v3 等，同時共同協作上也不會有各種一份檔案到處轉送，最後合併上又遇到各種版本不一致的問題。

從 DB Read 學習 Disk, FS 到 DB table 的互動流程

https://medium.com/@hnasr/following-a-database-read-to-the-metal-a187541333c2


本篇文章從 database read operation 出發，探討一個 DB read 實際上可能會發生的操作，包含
1. DB Table 的大小設計
2. DB Table 的 Cache 關係
3. DB Table 與 OS File System 的關係
4. OS File System 的 Page Cache
5. OS File System 與 Disk 的 Page 關係

這中間流程會有各種不同稱為 page 的術語，從 Disk, OS 到 Table 都有各自的 page，而其大小可能會有 4KB, 8KB, 32 KB 等都不同，所以這些不同大小的 Page 彼此之間是如何運作的，本文章就以比較淺白的方式去解釋流程，理解這些流程對於理解 DB 與儲存設備之間的參數調教會提供一些幫助，以至於不會亂槍打鳥

這兩日最大消息大概就是 nginx 的紛爭了，從這篇文章來看是一位自從 F5 收購後繼續無償幫 nginx 開源版本貢獻與維護的貢獻者因為與 F5 內部有些紛爭，最後這名貢獻者發起了 freenginx 的專案來繼續維持一個開源且免費的 nginx 版本

https://mailman.nginx.org/pipermail/nginx/2024-February/GPXQY27UA5SJJZ2Y6JWTRWJB2TKPTJR7.html

各種適用 Kubernetes 的 IDE


本篇文章列舉幾個對使用者相對友善的 Kubernetes IDE，這類型的工具目的都是提供一個好操作且視覺化的方式讓使用者可以去管理 Kubernetes 叢集。
相較於傳統使用 Kubectl 指令來管理，該指令需要使用者對指令有很好的熟悉程度，甚至很多時候還要使用各種指令組合才有辦法拼湊出 cluster 層級的資料，因此都會看到各種 -o json | jq, -o custom-colume 等各種輸出格式轉換並且搭配後續轉換。
而 dashboard 的目的就是簡化這些操作。

另外要特別注意的是，所有專案的使用是否都有 License(授權) 的條款，很多專案對個人免費，但是對於企業內的使用者都是要額外收費的，很多專案只是一開始沒有很嚴格的取締，但是並不代表往後不會突然收集資料直接索取應該有的授權費用，譬如 docker desktop 其實就是一個很常見的範例。

文內列舉的包含
1. Seabird
2. JET Pilot
3. Headlamp
4. OpenLens -> 大家比較熟悉的可能是 Lens 這個專案名稱，但是 Lens 本身使用上就有 License 的問題要注意，免費版本只有針對個人以及營收小於 10M 的企業而已，其餘情況理論上都是要購買 Lens Pro Enterprise 等相關授權。因此 OpenLens 這個選項才會出現在這邊，也許功能面上會比 Lens 少，但是授權問題會比較簡單。
5. Monokle
6. PyCharm K8s Plugin
7. K9s
8. Kubenav
9. Rancher -> 這個比較不能算單純 IDE，比較像是 K8s 管理工具並且附加的管理介面

https://medium.com/@seifeddinerajhi/explore-user-friendly-desktop-kubernetes-open-source-ides-5315516b0752

https://medium.com/@.anders/learnings-from-our-8-years-of-kubernetes-in-production-two-major-cluster-crashes-ditching-self-0257c09d36cd
本篇文章講述了將 Kubernetes 運行到正式環境 8 年來的心路歷程，最初使用時是於 AWS 上採取自建 Kubernetes 的環境，因為那時候根本沒有 AKS/EKS/GKE 等管理平台，所以可以說採用的時機點是非常早期，團隊於 2018 年開始將環境逐漸遷移到團隊比較熟悉的 Azure 上的 AKS。

這八年來不論是自己管理或是 AKS 的相關經驗學習如下

問題點: Cluster Crash
1. Root CA certificate, etcd/API server certificate 過期導致整個 Cluster 重建，雖然有各種 YAML/Helm 可以重組應用程式，但是卻沒有任何東西去紀錄 Cluster 建立的過程與設定檔案，這使得團隊花了幾天的時間才將整個環境重新打造並上線
2. 上述 Cluster 的重建過程中，使用了 kube-aws 這個專案來幫忙建置與管理，然而該專案那個時期有一個 bug 存在，沒有辦法正確的設定 etcd certificate 的有效期間，於是預設值又是一年，因此一年以後 cluster 又不能動了，不過這時因為有更多的經驗與知識，花了比較少的時間去修復問題，而且不需要整個 cluster 去重建。

上述經驗給團隊帶來的經驗有
1. Kubernetes 很複雜，沒有想像這麼簡單，不是隨時把一個人丟進去就可以學會使用 kubernetes，更別論 debugging 等需要更深入了解的操作
2. Certificate 很重要
3. 統一集中管理 Helm Chart
4. 要有 DR 計畫，更重要的是要測試過這些計畫，而且是時時刻刻都要測試，確保這些工具不會因為版本更新或是等相關架構改變而失效
5. Secret 等相關內容的備份
6. Vendor-Agnostic vs "Go All In"： 最初搬移到 AKS 時，為了有招一日可能要搬移到其他的環境，所以很多服務組件都採取使用 open source 自架服務，譬如 container registry, security scanning, auth 等。 團隊最後還是全面切入到 Azure 的服務
，因為發現從開發體驗，維運複雜度，甚至成本來看，其實都更加划算與有感提升
7. 巔峰流量前就要先行 scaling，雖然有各種自動 scale 的機制來調整數量，但是團隊發現這速度太慢，無法應付瞬間高峰的流量。

文章後半部分還有關於 Observability, Security 等相關內容的

淺談 K8s 中那些完全感知不到的 OOM 事件
https://medium.com/itnext/kubernetes-silent-pod-killer-104e7c8054d9


Kubernetes 中的最小部署單元都是 Container，而 Container 大部分情況下都會只跑一隻主要 process 來處理相關請求，因此當該 Process 被 OOM Killed 後都可以於 Kubernetes 的相關 event 或是 metrics 中去觀察到這現象來除錯。

但是假如 Container 中有其他 process，也就是 pid 不是1 的那些 process 被 OOM Killed 的話會怎樣？
從 OS 的角度來說是可以從 kernel log 找到相關事件，但是對 Kubernetes 則是完全無感的，所以你單純從 Kubernetes 的角度出發就沒有辦法收集到任何相關資料，除錯上也就會比較沒有頭緒。

該問題直到 Kubernetes v1.28 並且啟用 cgroup v2 的 grouping 功能，當 container 內有任何 process 被 OOM Killed 後，就會誅九族連帶 main process 一起被砍掉，最後就可以從 Kubernetes 的角度去觀察到這些事件。

至於 Kubernetes v1.28 以前，基本上沒有任何方式可以去觀察與監控這類型事件，只能從
contianer 內自行去監控並且處理。

又一個基於 ebpf 的效能監測工具，這次是由 netflix 所推出的 bpftop，不過監測目標倒不是普通的應用程式，而是所有 ebpf 應用程式，所以才會看到第二欄的 Type 都是針對 ebpf 的各種類型

所者現在愈來愈多 ebpf 的應用程式被掛到環境，特別是 k8s 生態系中，也許這類型的工具可以用來幫助管理員釐清每個 ebpf 的效率問題

不過前提可能是管理員要先懂 ebpf 而不是單純 YAML engineer

https://github.com/Netflix/bpftop

10 個微服務架構下的 anti-pattern
https://medium.com/statuspal/6-best-open-source-status-page-alternatives-for-2024-b68e5a967cc1


微服務架構的構思非常好，希望透過解隅的方式將服務給拆解來達到更彈性且更容易擴充的架構，同時每個服務都可以採用不同的程式語言，中間透過定義好的介面溝通即可。

然而微服務架構下若服務本身的設計不適當，反而會適得其反，使得整個架構變得更難用，因此本篇文章就列舉十個微服務下要避免的架構模式。

1. Monolith in Microservices
2. Chatty Microservices
3. Distributed Monolith
4. Over-Microservices
5. Violating Single Responsibility
6. Spaghetti Architecture
7. Distributed Data Inconsistency
8. Tight Coupling
9. Lack of Observability
10. Ignoring Human Costs

如何於 Kubernetes 打造多階級的 namespace 來更好管理多用戶
https://medium.com/faun/hierarchical-namespaces-in-kubernetes-5b07ea2c3e65
Kubernetes 內建 namespace 的機制來提供輕量級虛擬化，雖然沒有辦法達到如 VM 架構下去隔絕網路流量與相關系統資源用量，但是目前能夠提供
1. 系統 Quota
2. Label/Annotation 供第三方服務使用(如 Istio...etc)
3. 獨立的 RBAC

妥善設計下，可以透過這些機制去管理不同使用者的使用情境，使用者可能是
1. 一個團隊
2. 一個產品
3. 一個部門
4. ...等

隨者使用者數量增大，不可避免的就是 namespace 相關的設定會愈來愈多，同時有很多設定可能本身其實邏輯上是有依賴性的，譬如某個部門底下的團隊的產品，其 Quota 設定上應該會有所規範。這一切的邏輯都可以透過妥善的設定與設計去處理，只是要花不少時間與心力去處理。

本篇文章介紹的 HNC(Hierarchical Namespaces Controller) 是一個第三方服務，能夠將這些 namespace 給串成一個 tree 的架構來達到多節層的管理，來達到
1. 更有邏輯的去管理不同 namespace
2. 自動傳遞相關設定 (parent to child)
3. 簡化 RBAC 的設定

以 Raft 而非 Zookeeper 來搭建的 Kafka Cluster

https://medium.com/itnext/kafka-cluster-without-zookeeper-ca40d5f22304

Kafka 過去安裝需要搭配 zookeepr 來處理
1. Service Discovery
2. Leader Election
3. Broker Discovery
4. Configuration Management
5. ...等

而 3.3 版本後已經內建使用 KRaft 演算法(基於 Raft 改善)來處理分散式的架構，這也意味整個安裝過程不再需要 zookpeer，因此本篇文章就是基於這個概念來分享其架構以及安裝使用過程。

如何使用 eBPF 來偵測到 Kafka 叢集的效能問題

https://blog.allegro.tech/2024/03/kafka-performance-analysis.html


文章探討團隊使用 Kafka 的效能問題，團隊的 Kafka 每秒大概會有 300k 的訊息產生，同時有 1M 訊息被處理。
大部分情況下，所有的 request 都可以 ms 等級內解決，但是系統卻有長尾效應，P99 的結果大概要 1 秒鐘，而 P999 則需要 3 秒鐘。

整篇文章則是探討整個除錯過程，包含從初期的 tcpdump 去分析，後期導入 eBPF 針對更細部的去分析，最終找到問題跟節點上的檔案系統 (ext4) 有關，特別是某些操作會花費過多的時間去等待 lock 導致整個時間被拉長。

文章內最直得學習的就是如何導入 eBPF 這類型的工具來幫忙偵測這類型問題，而不是像過往一樣不知道如何下手

不常見但是可以幫助開發效率的 Git 指令與功能
https://martinheinz.dev/blog/109


本篇文章介紹一些自從 2010 後所被開發出來的 Git 指令。
大部分開發者慣用的指令幾乎都是都是早期版本就有的指令，包含 chcckout, stash 等，而隨者 git 後期的開發，實際上有愈來愈多的指令與功能被開發出來改善效率，譬如文章中介紹的
1. switch
2. restore
3. sparse-checkout
4. worktree
5. bisect

這些指令都有適合的情境，譬如同時有多個 branch 需要開發，或是一個 monorepo 的檔案過大，每次 checkout 都要花費大量時間等，因此花一些時間研究一下這些新的指令說不定可以加速日常工作流程