在停用擁有者帳戶前轉移個人 GitHub 儲存庫

轉移實際改變了甚麼

GitHub 儲存庫轉移會將儲存庫移至另一個擁有者帳戶。這與更改個人檔案用戶名稱並不相同。更改用戶名稱會改變帳戶的公開身份及由此構建的網址；轉移儲存庫則改變該個項目的擁有者。若你的目標是獲得更整潔的個人檔案名稱，而非將項目移交他人，以下轉移步驟便不適用。

這項區別對規劃至關重要。一旦原擁有者帳戶停用，便無人能登入接受邀請、批准後續事項或修正遺漏的連結。所有依賴舊帳戶的事項必須在停用前處理完畢，而非之後。

開始前需確認的先決條件

兩項條件決定轉移能否進行：

儲存庫轉移需要管理員權限，以及一個相容且沒有名稱或分叉網絡衝突的接收帳戶。來源

實際操作上，這意味著在提出請求前，需在擁有者一方檢查三項事項，並在接收者一方檢查一項：

若任何一項不符，請在發送請求前解決。在接收者一方重新命名儲存庫或選擇其他目標帳戶，均屬接收者的決定，因此應預先達成共識，而非在轉移過程中才發現衝突。

接受步驟的時間窗口很短

對於個人帳戶之間的轉移，接收者並非被動一方。他們必須採取行動：

轉移至另一個個人帳戶時，接收者需接受一封一日後失效的電郵邀請。來源

一日有效期是此流程的主要操作風險。若接收者身處不同時區、正在休假，或單純沒有留意電郵，邀請便可能失效，轉移需重新開始。應在接收者能夠回應的時間發送，並告知他們預期會收到該訊息，而非任由它未被閱讀。

簡單的擁有者／接收者接受清單：

1. 擁有者： 確認管理員權限、將要轉移的確切儲存庫，以及接收者帳戶沒有名稱或分叉網絡衝突。
2. 接收者： 確認目標帳戶，並從自身一方檢查是否有相同衝突。
3. 雙方： 協定一個發送時段，讓接收者能於一日內回應。
4. 擁有者： 發送轉移請求。
5. 接收者： 及時接受電郵邀請並回報。
6. 擁有者： 在對舊帳戶採取任何行動前，確認儲存庫現已出現在接收者帳戶下。

在確認第 6 步之前，請勿停用擁有者帳戶。舊帳戶是唯一可以重新發送失敗或逾期轉移的地方。

轉移後公開連結會如何

連結行為正是轉移令人意外之處，因為兩類連結的表現不同：

轉移後儲存庫連結會重新導向，但相關的 GitHub Pages 網站不會重新導向；若舊儲存庫位置被重用，儲存庫的重新導向便會失效。來源

這為轉移後的連結審核提供了清晰區分：

第三行最容易被忽略。若舊儲存庫路徑日後被重用，原本默默覆蓋你舊連結的重新導向便會消失。應將重新導向視為遷移期間的便利措施，而非永久保證，並更新你控制的連結，而非依賴它。

轉移後公開連結檢查清單

在接收者確認擁有權後、擁有者帳戶停用前，執行以下步驟：

• 從你的文件、README 及任何引用該項目的網站中，抽取部分儲存庫連結並開啟，確認它們指向新擁有者。
• 找出與該儲存庫相關的每一個 GitHub Pages 網站，因為它們不會重新導向，並更新已發佈的連結。
• 決定舊儲存庫位置的處理方式，以免被重用而導致重新導向失效。
• 檢查你無法控制的地方（例如外部文章或共享書籤）的連結，並記錄哪些可以更新、哪些不能。
• 在完成上述所有事項前，保持擁有者帳戶活躍。

擁有權遷移與更改用戶名稱的分別

轉移儲存庫與更改個人檔案用戶名稱是兩項獨立任務，各有風險。轉移關乎誰擁有項目；更改用戶名稱則關乎帳戶自身的公開身份。若你真正想要的是整理個人檔案的外觀，而非移交儲存庫，請先參閱用戶名稱指南：更改 GitHub 用戶名稱而不留下失效的個人檔案連結。

若兩者皆需進行，請刻意安排順序：先處理儲存庫擁有權，確認新擁有者能獨立行事，然後才更改或停用舊帳戶。若順序相反，轉移便會依賴一個你已放棄的帳戶。

用戶名稱搜尋的適用範圍與限制

在停用帳戶前，人們常想知道舊用戶名稱在其他地方還留下甚麼公開痕跡。用戶名稱查詢可揭示其他平台上的公開個人檔案匹配，這有助建立可能需要更新的連結清單。但它並非帳戶清單，匹配也不證明同一人擁有兩個帳戶。應將結果視為需要人手檢查的地方，而非確認連結仍然有效或帳戶屬於你。

TraceSeek 覆蓋 3,000+ 個平台，並在 20–30 秒內提供免費首次掃描。這有助你建立待審核的公開個人檔案清單，但它不驗證擁有權，也不能取代上述的轉移及連結檢查。儲存庫轉移本身在 GitHub 上進行，而非在查詢工具中。

實際操作順序

1. 決定你需要的是儲存庫轉移、更改用戶名稱，還是兩者皆需。
2. 確認管理員權限、接收者相容性，以及沒有名稱或分叉網絡衝突。
3. 在接收者能於一日內接受時發送轉移。
4. 確認儲存庫已在新擁有者之下。
5. 審核儲存庫連結，並另行審核任何 GitHub Pages 連結。
6. 保護舊儲存庫位置免被重用。
7. 然後才停用擁有者帳戶。