公開個人檔案上顯示的儲存庫可能是 fork，而 fork 起初是上游儲存庫的副本，同時仍與上游保持連結。在某人的個人檔案上看到它，並不能證明底層專案是由該人所建立。在 AI 報告作出那項歸功之前，請尋找可見的上游關係，把 fork 託管視為已知事實，並且只加入你實際能看到的公開貢獻背景。
使用我們的 TraceSeek 應用程式尋找公開社群檔案線索。
將託管與作者身分分開
個人檔案上的列表告訴你某個儲存庫公開託管於何處。它不會告訴你上游程式碼是誰寫的。GitHub 說明 fork 起初是上游儲存庫的副本；fork 保有自己的設定與權限，但仍與上游保持連結。由於 fork 起初是副本，我們的判讀規則是區分「託管該 fork」與「撰寫其上游程式碼」。這是應持續留意的區別：託管是可觀察的，作者身分則是另一個問題。 [GitHub：分支與上游儲存庫的關係]
尋找可見的上游標記
GitHub 會在 fork 名稱下方標示上游，這是最清楚的公開關係訊號。請在儲存庫頁面本身尋找該標籤，而不是在頁面的摘要上尋找。如果標籤存在，就將該專案記錄為 fork，並寫明它所指向的上游。如果在你所能看到的部分中沒有該標籤，不要用猜測填補空白；請註明上游關係對你而言並不可見。 [GitHub：分支與上游儲存庫的關係]
- 註明儲存庫名稱下方是否出現上游標籤。
- 只有在實際顯示時才記錄上游名稱。
- 若無法確認，請寫「fork 狀態不可見」，而不是「原創作品」。
將三項觀察放在各自獨立的欄位
風險在於把不同的觀察混成單一結論。請將 fork 關係、公開貢獻背景，以及任何 AI 陳述分開放置，讓每一項都能各自查核。下表是給讀者的輔助說明，並非對任何產品介面的描述。
| 觀察 | 限制 | 下一步 |
|---|---|---|
| 儲存庫出現在個人檔案上 | 僅憑出現位置，無法說明程式碼是誰寫的 | 在歸屬於任何人之前，先檢查是否有上游標籤 |
| 上游標籤標示了另一個專案 | 確認的是分支關係，而非任一方的工作範圍 | 將個人檔案持有者描述為託管該專案的分支 |
| 看不到上游標籤，或頁面無法使用 | 缺乏標示並不代表原始著作權的證據 | 記錄確切的限制，並停止推論 |
| AI 報告將完整創作歸給個人檔案持有者 | 這是一種解讀，而非平台事實 | 在公開背景資料支持之前，重新標記為未經驗證 |
將持有者所寫的內容視為自我陳述
由個人檔案持有者撰寫的專案描述屬於自我陳述，即使它就出現在分支旁邊也一樣。它可能準確，但並非對原始著作權的獨立確認。應將其視為一個人的說法，並與可見的上游關係相互對照，而非以其取代上游關係。兩者若有衝突，應直接說明，而非默默化解衝突。 [GitHub：分支與上游儲存庫的關係]
僅在公開貢獻背景資料可見時才加入
若分支問題對某項決定有影響，只尋求公開貢獻背景資料，例如平台公開顯示的活動。將該背景資料標示為部分視角：公開活動並非完整的工作經歷，也無法衡量上游程式碼的品質或原創性。假設性範例：某個個人檔案顯示一個帶有上游標籤的儲存庫，該標籤標示了較大的專案，而個人檔案持有者的公開活動只觸及其中一小部分。站得住腳的說法是他們託管了一個分支並顯示部分公開活動，而非他們建立了該專案。 [GitHub：分支與上游儲存庫的關係]
停在素材的邊界
若來源不存在、屬私人、不相符或含糊不清，記錄該確切限制並停止。不要索取私人存取權限，不要試圖從間接訊號辨識任何人，也不要讓 AI 摘要自信的語氣取代證據。可見的分支連結是事實；關於誰應為整個專案記功的推論則是主張，需要自身的佐證。把限制寫下來，讓下一位讀者繼承的是不確定性，而非虛假的確定性。
還有幾個問題
儲存庫出現在個人檔案上，就代表那個人建立了它嗎？
不是。分支起初是上游儲存庫的複本，並持續與其相連，因此公開託管分支本身並不能確立上游工作的著作權。在將整個專案的功勞歸給任何人之前，請先檢查是否有上游標籤。
如果我無法看出該儲存庫是否為分支，該怎麼寫？
記錄確切的限制，例如：在你所能觸及的公開頁面上看不到上游關係，然後就此打住。不要因為缺少標籤就推論原始著作權，也不要為了釐清此事而索取私人存取權限。
由個人檔案持有者撰寫的描述能證明著作權嗎？
不能。那是該個人檔案所屬者本人的自我陳述。它可能是有用的背景資料，但並非獨立確認，且應與可見的分支關係一併閱讀，而非取代它。
來源與編輯說明
官方參考資料查核於 2026年10月24日。檢查清單、比較表格與範例措辭是 DateClues 的編輯工具，並非官方測試或經驗證的風險分數。
一般資訊。任何指南或工具都無法保證某人的身分、意圖或安全。 閱讀我們的編輯準則。