今天處理專案程式碼推播時，碰上了一個啼笑皆非的插曲。本來只是一個單純的 GitHub 驗證過期問題，在解決過程中最後卻衍生出終端機的語法報錯。這篇文章紀錄了我們處理 GitHub Token 逾期的標準流程，以及踩到的終端機小陷阱。
突如其來的 Authentication Failed
和平常一樣，寫完程式後下了 git push origin dev，結果終端機毫不留情地吐了這串錯誤出來：
remote: Invalid username or token. Password authentication is not supported for Git operations.
排查後發現，我們因為方便，之前直接在 git remote 的網址裡寫死了 GitHub Personal Access Token (PAT) 來做驗證，而那組 Token 剛好過期。
如何處理 GitHub Token 逾期？
遇到這個問題，重新發行一組新的 Token 綁定回去即可，具體操作步驟如下：
-
產生新的 Token： – 登入 GitHub 網站，點擊右上角的大頭貼進入 Settings (設定)。 – 在左側選單滑到最下方，點選 Developer settings。 – 點選 Personal access tokens -> Tokens (classic)。 – 點擊 Generate new token (classic)，隨便設定一個名稱與過期時間（建議最多設 90 天比較安全）。 – 最重要的是：在 Select scopes 權限清單中，務必勾選
repo，才能提供程式碼的完整存取權限。 – 點擊產生後，把那一串以ghp_開頭的新密碼複製下來。 -
更新本機的 Remote URL： – 在終端機執行指令，把舊的 Token 替換成剛剛複製的新 Token：
bash git remote set-url origin https://你的GitHub帳號:<新Token>@github.com/你的帳號/專案名稱.git
問題本該到這裡就輕鬆解決，結果解法卻變成了新的坑。
魔鬼藏在複製貼上裡
我們參考了自己寫過的語法筆記，在終端機貼上了剛才那段 git remote set-url 指令，結果按下去，終端機居然說：
zsh: no such file or directory: ghp_xxxx
當下愣了幾秒，才發現問題根本不是出在 Git 或 GitHub，而是終端機的符號陷阱。
在官方或是網路上的教學文件裡，為了標示「這裡請替換成你的資訊」，通常會用 < > 角括號包起來，例如 <新Token>。但我們剛剛複製貼上的時候，不小心連 < 和 > 這兩個符號都一起執行了。
在 Mac 預設的 Zsh 或一般的 Bash 終端機裡，< 和 > 可是有特殊意義的，它們代表「匯入與匯出檔案（Redirection）」。終端機看到這個符號，以為我們要寫入或讀取一個叫做 ghp_xxxx 的檔案，實體硬碟裡當然沒有這個實體檔案，所以才會回報 no such file or directory。
解法很單純，把指令裡的角括號拿掉，只留下 Token 本身。重新執行後，再搭配 git pull --rebase 解決版本分歧，git push 終於順利發布。
小結
這次經驗提醒了我們兩件事：
1. GitHub Token 過期是常態 — 遇到推播失敗且回報 Password authentication is not supported 時，先檢查 Token 是不是失效了並照著步驟重發一把。
2. 複製終端機指令請記得去殼 — 看到文件中的 < > 或 [ ] 請自動在腦內把它們過濾掉，不要連著框線一起貼進 Terminal 裡。
比起寫死 Token 在 URL 裡，其實改用 GitHub CLI (執行 gh auth login) 或 SSH Key 才是更穩健長期作法。這也會是我們後續著手調整開發環境的重點項目。
