如何將現有的專案移轉至 GitHub？
這裡我們會討論從舊版的版本控制系統將專案移轉至 GitHub 時的重要考量事項。
為何要移轉至 GitHub？
有大量讚揚 GitHub 優點的文獻。 本課程模組的範圍不包括說服您移動的內容。 但是，我們可以在您規劃移轉時需要考量的主題內容中回顧一些主要優點。
版本控制
GitHub 只會使用 Git，這可以說是最理想的版本控制系統。 不過，Git 非常複雜，而且或許會遇到一些複雜案例來處理您的小組可能不熟悉的程式碼。 分支與提取要求對於使用 Git 的開發人員而言是日常生活的基本部分，因此，需要了解有效使用這兩者的時機與方式，才能在 GitHub 上成功。 對您的小組而言，值得先花時間來熟悉 GitHub 流程，如此您就能迅速且順利地開始。
將您的程式碼保留在雲端
大部分的專案程式碼仍會儲存在位於公司防火牆後方的舊版版本控制系統中。 當您移轉至 GitHub 時，您會將程式碼移至 GitHub 的雲端平台，讓小組成員可以輕鬆地從任何地方存取。 此移轉提供一個好機會，可針對您在版本控制中保留的檔案與資料種類檢閱小組的原則。 最佳做法是您應該假設您提交給 GitHub 的任何內容都遭入侵。 請確保不要包括敏感性資料，例如 API 金鑰、密碼或其他包含可比較資訊的檔案。
注意
GitHub 同時提供公用與私人存放庫，以及適用於存放庫不同部分的細微存取控制。 這可讓您控制能夠看到專案的人員，以及指定使用者可以執行的動作。
共同作業
GitHub 透過問題、提取要求與程式碼檢閱等功能，為小組共同作業提供絕佳支援。 不過，GitHub 流程可能與您小組目前習慣的做法不同。 建議您在完成移轉之前，先考量小組是否打算全面採用 GitHub、保留其指定流程，或彼此各退一步以找到一個平衡點。
如果您的專案是允許外部參與者的開放原始碼專案，則不會有比 GitHub 更好的選項可發揮最大效益。
移轉至 GitHub
規劃考量
在執行移轉至 GitHub 之前最重要的考量是，您是否需要保留任何超出來源目前狀態的內容。 如果您認為以目前的來源立即開始新專案即可，則最佳選項是將它視為新的專案，並將來源上傳至您的存放庫。
不過，如果您想要保留版本控制歷程記錄，則需要使用 GitHub Migrator 工具來匯入。 如需不同版本控制平台匯入支援的詳細資訊，請參閱從協力廠商版本控制系統匯入資料。
除了 Git 資料以外，您可能也會希望保留問題、提取要求或其他資料。 對這些項目的支援因平台而異，而且通常可從社群專案取得。 此課程模組並未涵蓋移轉非 Git 資料。
處理目前儲存於專案中的二進位檔案
最佳做法是將 GitHub 存放庫限制為建置專案所需的檔案。 避免認可大型二進位檔案，例如組建成品。 試算表與簡報之類的二進位檔案更適合在入口網站上進行追蹤，以了解如何適當地為其提供服務並進行版本設定。 如果您需要對大型二進位檔案進行版本設定，請考慮使用 Git LFS (大型檔案儲存體) Git 延伸模組。
建立 .gitignore 之類的重要 Git 檔案
Git 支援 .gitignore 檔案，以協助強制執行版本控制檔案原則。 這些檔案會定義用來從原始程式碼控制追蹤中排除檔案與資料夾的搜尋模式。 下列簡單範例會從來源控制追蹤中，以遞迴方式排除名為 Bin 或 bin 的任何資料夾以及其內容：
[Bb]in/
您可以深入了解忽略檔案。 您也可以參閱 gitignore 存放庫中針對各種平台提供的入門 .gitignore 檔案集合。
GitHub 專案中通常會使用數個其他檔案，來向存放庫取用者與參與者說明不同原則。 即使您的專案是私人且僅限於有限的對象，但明確表達這些原則仍然很有用。 儘管不需要這些檔案，但我們仍在此列出了一些常見檔案。
| 檔案 | 目的 |
|---|---|
README.md |
目錄的登陸頁面。 在 GitHub 上檢視其目錄時，即會呈現此頁面。 |
LICENSE.md |
提供程式碼所依據的授權。 |
CONTRIBUTING.md |
說明使用者應如何參與專案，例如提取要求期望。 |
SECURITY.md |
說明專案的安全性原則。 提供指導方針給想要提交與安全性相關的敏感性程式碼或不應在解決前公開之意見反應的使用者。 |
深入了解如何設定專案以獲得健全的貢獻 \(英文\)。
將專案匯入至 GitHub
準備好要移轉的存放庫之後，即可瀏覽至 GitHub 存放庫的 [程式碼] 索引標籤。 使用 [匯入程式碼] 選項來指定來源存放庫。
GitHub Migrator 工具會負責處理其餘作業。
