Use_Git_Like_a_Senior

文章 1: Use Git Like a Senior Engineer

這篇文章旨在闡述資深工程師如何將 Git 從一個簡單的版本控制工具，昇華為提升團隊溝通、安全性與生產力的利器。

前言：Git 遠不止 `git add . && git commit -m “fix”`

段落重點：這段對比了資淺與資深工程師對 Git 的看法。資淺開發者將 Git 視為保存程式碼的備份倉庫，而資深工程師則將其視為溝通層、安全網和生產力倍增器。他們不只是記憶指令，而是將 Git 融入到一種更有效率的協作習慣與思維模式中。
段落總結：

許多人知道 Git 指令，但這不代表能有效地使用它。資深工程師不將 Git 視為一項任務，而是將其視為一個強大的工具。他們用它來記錄專案的歷史、避免災難，並使協作成為第二天性。資淺開發者認為 Git 是一個備份儲存庫，而資深工程師則將 Git 視為一個溝通層、一個安全機制、一個生產力倍增器。本文將探討如何像一位工程主管那樣使用 Git，超越記憶指令，擁抱能讓你成為更高效協作者的習慣和心態。

1. 像專業說書人一樣撰寫 Commit

段落重點：強調 Commit 歷史的重要性，它應該是專案的故事書，而不是混亂的日誌。糟糕的 Commit 會讓除錯變得極為困難。文章提出了撰寫 Commit 的三大規則：原子化、描述性訊息和使用現在式。
段落總結：
Git 歷史不僅僅是一個日誌——它是你專案背後的故事。糟糕的 Commit 會造成混亂的時間線，沒有人願意去進行除錯。一個大師會將每次 Commit 都視為一個有意義的動作。

規則:
- 原子化提交 (Atomic commits)：每次提交必須是一個邏輯上的變更。不要將修復錯誤和更新文件混在一次提交。
- 描述性訊息 (Descriptive messages)：不要只寫 fix things，而是寫 Fix null pointer exception when user ID is absent。
- 使用現在式 (Use present tense)：使用 “Add validation” 而不是 “Added validation”。
好的 Commit 訊息範例:
```
feat(auth): Add JWT expiration check middleware

- Ensure expired tokens return 401 Unauthorized
- Add unit tests for expired and malformed tokens
- Update documentation with example requests
```
這樣做，能讓幾個月後的讀者在查閱歷史時，不必逆向工程你的思維過程。

2. 有目的地創建分支，而非恐慌

段落重點：分支不應是隨意工作的垃圾桶，而是用於協作和保持清晰的工具。資深工程師會採用明確的分支策略，並保持分支的生命週期短暫，以避免合併衝突的惡夢。
段落總結：
分支不是「我正在做的任何事」的垃圾桶，它們是協作和保持清晰的工具。資深工程師使用分支策略來防止混亂：
- 功能分支 (Feature branches)：用於新增功能 (feature/user-profile)。
- 錯誤修復分支 (Bugfix branches)：用於特定的修復 (bugfix/payment-timeout)。
- 緊急修復分支 (Hotfix branches)：保留給嚴重的生產環境問題 (hotfix/critical-security-patch)。
他們會保持分支的生命週期短暫。一個存活數週的分支會變成合併衝突的惡夢。選擇一個命名慣例並保持一致性，這比追求完美更重要。

3. Rebase vs. Merge: 理解其概念

段落重點：區分 rebase 和 merge 是區分新手與老手的關鍵。Merge 保留所有歷史紀錄，適合團隊協作；Rebase 則重寫歷史使其變得線性，適合在合併到主分支前整理提交紀錄。關鍵原則是絕不對他人正在使用的共享分支進行 rebase。
段落總結：
這個議題區分了新手和老手。
- Merge: 合併歷史，保留所有提交的原貌。適合團隊協作。
- Rebase: 重寫歷史使其變得線性。非常適合在合併到主分支前清理歷史。
一個資淺工程師會混合使用。一個資深工程師則知道何時使用 rebase 來保持歷史整潔，何時使用 merge 來保留協作的上下文。絕對不要對別人正在處理的分支進行 rebase，那會讓你收到憤怒的 Slack 訊息。

4. 把 `git log` 變成你的朋友

段落重點：資深工程師不僅是推送程式碼，他們還會利用 Git 歷史來審視他們推送了什麼以及為什麼。文章推薦了幾個非常有用的指令，如 git log --oneline --graph --decorate、git blame 和 git bisect，這些工具能讓你成為解決問題時的「Git 偵探」。
段落總結：
資深工程師不只是推送後就忘了。他們使用 Git 歷史來查看他們推送了什麼以及為什麼。

有用的指令:
- git log --oneline --graph --decorate: 以乾淨、可讀的格式視覺化歷史。
- git blame <file>: 顯示誰最後修改了每一行（用於除錯，而非指責）。
- git bisect: 當你的團隊想知道那個討厭的 bug 是從哪裡來的時候，這是一個救星。
理解這些指令能讓你在出現問題時，成為團隊中的「Git 偵探」。

5. 冷靜地處理合併衝突

段落重點：合併衝突是必然會發生的。關鍵在於處理它的方式。不要驚慌，使用 git mergetool 或 IDE 的整合工具進行視覺化修復，並在解決衝突的提交中寫下描述性的訊息。如果頻繁遇到衝突，這通常是分支生命週期過長的警訊。
段落總結：
合併衝突是必然會發生的，變數在於你如何處理它。不要驚慌，衝突不代表你的儲存庫壞了。
- 使用 git mergetool 或 IDE 的整合工具來視覺化地解決它們。
- 在你的提交中撰寫描述性的衝突解決方案，以便人們理解發生了什麼變化。
- 如果你總是深陷衝突之中，這是一個警訊，代表你的分支生命週期太長了。應該更頻繁地進行 Rebase。

6. 利用 Git Hooks 自動化乏味的工作

段落重點：資深工程師不會依靠記憶來執行重複性工作，他們會將其自動化。Git hooks 允許在關鍵時間點（如提交或推送前）執行腳本，例如運行測試、強制執行提交訊息格式或自動格式化程式碼。
段落總結：
經驗豐富的工程師從不相信自己的記憶力來處理重複性工作，他們會自動化。Git hooks 允許在重要時間點（例如提交或推送前）執行腳本。

範例:
- 推送前運行測試：防止損壞的程式碼進入儲存庫。
- 強制執行提交訊息慣例：不再有 asdf 這樣的提交。
- 自動格式化程式碼：在團隊中保持一致的風格。
pre-commit hook 範例 (.git/hooks/pre-commit):
```
#!/bin/sh
pytest || exit 1
```
現在，除非測試通過，否則任何提交都將不被允許。

7. 明智地使用 Stash

段落重點：當需要緊急切換任務時，git stash 是一個非常有用的工具，可以暫時儲存未完成的工作。資深工程師會使用它來保持工作流程的靈活性，但同時也會定期清理儲藏區，避免它變成一個雜亂的抽屜。
段落總結：
你正在開發一個功能，突然團隊有人要求你解決一個生產環境的 bug。資淺工程師會感到恐慌，資深工程師則會使用儲藏 (stash)。
```
git stash
git checkout main
# Fix bug
git checkout feature-branch
git stash pop
```
這個工作流程讓你保持靈活，而不會留下半途而廢的工作。但是，要像對待一個雜物抽屜一樣對待儲藏區——定期清理它。

8. 不要害怕 `git reflog`

段落重點：git reflog 是一個強大的救援工具。它記錄了 Git 儲存庫中所有 HEAD 的移動，即使這些紀錄沒有出現在標準的提交歷史中。當你不小心刪除了分支或執行了錯誤的 reset 時，reflog 就像時光機一樣可以救你一命。
段落總結：
不小心刪除了一個分支？在一次 hard reset 中弄錯了提交？不要驚慌。git reflog 記錄了你的 Git 曾經的所有移動，即使是那些沒有出現在標準歷史中的。

範例:
```
git reflog
git checkout <commit-hash>
```
它就像一台回到你犯錯之前的時光機。經驗豐富的工程師知道這個指令是個救星。

9. 像資深專家一樣處理 Pull Requests

段落重點：Pull Requests (PR) 不僅僅是一個形式，它是一種溝通方式。好的 PR 應該是專注且小型的、清楚解釋變更的「為什麼」，並在適當時使用截圖或成果來輔助說明。
段-落總結：
Pull Requests (PRs) 不僅僅是一種形式——它們是一條溝通線路。

好的 PRs:
- 專注且小巧（更容易審查）。
- 明確定義變更背後的「為什麼」。
- 如果適用，使用截圖或成果。
- 體貼地標記審查者（不要垃圾郵件整個團隊）。
經驗豐富的工程師不僅僅是提交程式碼；他們讓其他人能夠理解並相信它。

10. 養成「隨手清理」的心態

段落重點：Git 的精髓在於紀律。資深工程師會持續維護儲存庫的健康，例如刪除已合併的分支、避免提交機敏資訊（使用 .gitignore），以及在合併前整理無意義的提交。
段落總結：
Git 不僅是指令，它是一種紀律。資深工程師通過以下方式維護健康的儲存庫：
- 移除已合併的分支。
- 不提交機敏資訊（使用 .gitignore 和 git-secrets 等工具）。
- 在合併前壓縮無意義的提交（如 fix typo, oops, update）。
- 定期檢查審查歷史以識別模式或反模式。
這能讓你的 Git 儲存庫成為一項長期資產，而不是負債。

整篇文章重點結論

這篇文章的核心思想是，Git 的真正價值體現在它作為溝通、協作與保障專案品質的工具，而不僅僅是程式碼的備份系統。

資深工程師與他人的區別在於他們的心態與習慣：

溝通清晰：透過撰寫原子化、描述清晰的 Commit 訊息，將版本歷史變成一個易於理解的故事。
流程紀律：採用有目的的分支策略、明智地使用 rebase 與 merge，並保持分支的短生命週期，以減少混亂和衝突。
善用工具：熟練運用 git log、blame、bisect 等工具進行問題追蹤，並利用 git hooks 自動化重複性工作，提升效率。
安全與恢復：了解 git stash 的靈活性和 git reflog 的強大恢復能力，讓他們在面對意外時能從容不迫。
協作文化：將 Pull Request 視為重要的溝通環節，並養成「隨手清理」的好習慣，共同維護一個乾淨、健康的程式碼庫。

最終，從「保存程式碼」的思維轉變為「為團隊打造清晰歷史」的思維，是從資淺走向資深的關鍵一步。這不僅關乎技術，更關乎專業精神與團隊責任感。