程式碼在誰的帳號？想換人接手，才發現連版本庫在哪裡都要問

想換人接手，才發現程式碼不在自己手上

您找了自由工程師幫忙開發會員系統，前端能用、功能也跑得起來。現在想找另一位工程師加入，或是想把系統交給內部 IT 維護，這時候才發現：程式碼放在外包工程師個人的 GitHub 帳號裡、雲端主機登入密碼要問他才知道、CI/CD 的部署權限也綁在他的信箱。

您問他能不能「交接」，他也很配合，願意給您帳號密碼、或是把程式碼打包寄給您。但新的工程師接手後告訴您：「我拿到的是壓縮檔，沒有版本歷史記錄；部署環境還在他的 AWS 帳號下，我們沒有管理權限。」這時您才意識到：交接不只是「拿到程式碼」，而是要能夠「完全掌控系統」。

這是台灣中小企業軟體外包最常見的交接漏洞，也是最容易在合約階段就預防、或在專案中途就補救的風險。本文將帶您了解如何把程式碼版本庫、部署權限、雲端資源，一步步收回公司名下。

為什麼程式碼會在外包個人的帳號裡？

實務上，很多外包專案一開始沒有明確約定程式碼要放在哪裡。自由工程師習慣用自己的 GitHub 或 GitLab 帳號建立專案，因為這樣最快、也最方便他自己管理。雲端主機（AWS、GCP、Azure）、域名註冊商帳號，也常常直接用工程師個人的信用卡開通，因為「先做起來再說」。

<cite index="26-18,26-19">問題在於：如果合約沒有明確的所有權條款，開發者或外包團隊可能保有您付費開發的程式碼權利。</cite>這會讓您無法自由修改、轉售、甚至無法完全使用自己的產品。

另一個常見狀況是：外包工程師離職、失聯、或因為合約糾紛不願配合交接。這時候如果程式碼版本庫、部署設定、資料庫備份都在對方帳號裡，您的系統就等於被「人質綁架」——技術上可以救，但時間成本和法律成本都很高。

四個步驟，把程式碼版本庫與部署權限收回公司

步驟一：建立公司的 GitHub Organization 或 GitLab Group

不要使用個人帳號管理公司的程式碼。<cite index="18-1">建立獨立的 GitHub Organization 或 GitLab Group，讓不同專案或團隊的存取控制能夠集中管理。</cite>

• GitHub：Settings → Organizations → New organization（免費版已足夠中小企業使用）
• GitLab：Groups → New group

建立後，將公司內部 IT 人員或技術主管設為 Owner 角色，確保即使外包工程師離開，公司仍保有完整管理權限。

步驟二：要求外包工程師轉移 Repository 所有權

<cite index="4-4,4-6">GitHub 允許您將 Repository 轉移給其他使用者或組織帳號。當您轉移 Repository 給新擁有者時，對方可以立即管理程式碼內容、Issue、Pull Request、Release、專案設定。</cite>

轉移步驟（GitHub 為例）：

1. 請外包工程師登入他的 GitHub 帳號
2. <cite index="3-5,3-6,3-7,3-8,3-9">進入要轉移的 Repository → 點選 Settings → 向下捲動至 Danger Zone 區塊 → 點選 Transfer ownership → 輸入您公司的 Organization 名稱並確認轉移</cite>
3. <cite index="4-10,4-11,4-12">當您將個人擁有的 Repository 轉移給另一個帳號時，新擁有者會收到確認信件，內含接受轉移的操作說明。如果新擁有者未在一天內接受轉移，邀請將會過期。</cite>

轉移完成後，<cite index="4-1">原擁有者會自動成為該 Repository 的協作者</cite>，您可以決定是否保留他的存取權限。如果合約已結束，建議移除他的協作者身分。

步驟三：盤點並轉移雲端資源與部署權限

程式碼版本庫只是第一步，部署環境的掌控權更重要。請列出以下清單，逐項確認所有權：

• 雲端主機（AWS EC2、GCP Compute Engine、Azure VM）：是否在公司帳號下？還是外包工程師的個人帳號？
• 資料庫服務（RDS、Cloud SQL）：備份存放在誰的帳號？
• CI/CD 工具（GitHub Actions、GitLab CI、CircleCI）：部署權限綁定哪個帳號？
• 域名與 DNS：在哪家註冊商？登入帳號是誰的信箱？
• SSL 憑證：誰持有私鑰？自動續約設定在哪裡？

<cite index="12-1,12-2">根據使用者角色限制 Repository 存取權限。僅授予需要的人員權限，並定期檢視存取記錄。</cite>建議在公司內部建立一個「數位資產清單」Excel 或 Notion 頁面，記錄所有帳號、權限擁有者、更新日期。

步驟四：確認合約中的智慧財產權條款

如果外包專案還在進行中，現在就是補上智慧財產權條款的時機。<cite index="26-21,26-22,26-23,26-24">合約中應明確三件事：第一，所有交付成果及其原始碼在完成或付款時轉移給您；第二，任何第三方或開源元件都必須揭露，並列出其授權條款；第三，外包商不得保留任何重複使用的權利。</cite>

如果外包工程師已經離職或失聯，而程式碼還在他個人帳號裡，您有以下選項：

1. 協商取回：提供合理補償（例如支付剩餘尾款、或額外的交接費用），請對方配合轉移
2. 法律途徑：<cite index="20-1,20-2">在台灣，外包合約爭議通常透過訴訟或仲裁解決。仲裁因其效率與保密性而較受青睞。</cite>
3. 技術重建：如果程式碼無法取回、且沒有備份，評估重新開發的成本是否比法律訴訟更划算

下一步：建立公司的程式碼管理制度

把程式碼收回公司只是第一步。長遠來看，您需要建立一套內部的程式碼管理制度，避免未來再次發生類似風險：

• 所有專案一律使用公司 Organization 帳號：不論內部開發或外包，程式碼都應該放在公司名下的 GitHub/GitLab
• 設定雙因素驗證（2FA）：<cite index="17-3,17-4,17-5">為組織的 GitHub Repository 強制啟用雙因素驗證，要求每位團隊成員在存取時提供額外驗證層（例如驗證 App 產生的臨時代碼）。這能大幅降低未授權存取的風險，尤其在密碼外洩的情況下。</cite>
• 定期備份程式碼與資料庫：即使版本庫在公司帳號裡，也要定期將程式碼與資料庫備份到另一個獨立儲存空間（例如公司 NAS 或另一個雲端服務）
• 建立離職交接 SOP：當工程師（不論正職或外包）離職時，有明確的權限回收流程

如果您現在手上有個做到一半的系統、或是正在評估外包專案的交接風險，我們提供免費的程式碼健診服務，幫助您盤點現有專案的版本控制、部署權限、資料備份狀況，並給出具體的補救建議。

當您能完整掌控程式碼版本庫、部署環境、雲端資源，您的系統才真正屬於您——不論未來想自己維護、找新團隊接手、或是擴充功能，都不會再被「程式碼在誰的帳號」這個問題卡住。