既存のプロジェクトを GitHub に移行する方法
ここでは、従来のバージョン コントロール システムから GitHub にプロジェクトを移行する場合の重要な考慮事項について説明します。
GitHub に移行する理由
GitHub の長所を説明する資料は多数あります。 移行するようにお客様を説得することは、このモジュールの範囲を超えています。 ただし、移行を計画するときに考慮する必要があるトピックのコンテキスト内で、主な利点の一部をまとめて説明することはできます。
バージョン コントロール
GitHub では、使用されているバージョンコントロール システムとして、ほぼ間違いなく最良である Git を独占的に使用しています。 ただし、Git は非常に高度であり、あなたのチームが経験したことのないような複雑なコードを扱うシナリオを提示できます。 Git を使用する開発者にとって、"ブランチ" と pull request は日常の作業の基本部分であり、GitHub を使いこなすには、これらを効果的に使用するタイミングと方法を理解している必要があります。 チームがまず GitHub のフローに精通することが重要です。そうすれば、すぐに全力で取り組むことができます。
コードをクラウドに保持する
多くのプロジェクト コードはまだ、企業のファイアウォールの内側にある従来のバージョン コントロール システムに格納されています。 GitHub に移行するときは、チーム メンバーがどこからでも簡単にアクセスできる、GitHub のクラウド プラットフォームにコードを移動します。 この移行は、バージョン コントロールに保持するファイルとデータの種類に関するチームのポリシーを確認するよい機会になります。 ベスト プラクティスとして、GitHub にコミットするすべてのものがセキュリティ侵害されることを想定する必要があります。 API キー、パスワード、または同等の情報を含む他のファイルなどの、機密データを含めないようにしてください。
Note
GitHub では、パブリックとプライベート両方のリポジトリおよびリポジトリのさまざまな部分に対するきめ細かいアクセス制御が提供されています。 これにより、プロジェクトを表示できるユーザーを制御したり、特定のユーザーが実行できる操作を制御したりすることができます。
コラボレーション
GitHub では、イシュー、pull request、コード レビューなどの機能により、チームのコラボレーションに対する優れたサポートが提供されています。 ただし、GitHub のフローは、現在のチームが使い慣れている方法とは異なる場合があります。 移行を完了する前に、チームが GitHub に合わせる予定か、現在のプロセスを維持する予定か、またはその中間のどこかにする予定かを検討することをお勧めします。
あなたのプロジェクトが外部の共同作成者を受け入れるオープンソース プロジェクトである場合、メリットを最大化するには GitHub より適した選択肢はありません。
GitHub への移行
計画に関する考慮事項
GitHub への移行を行う前に考慮する必要がある最も重要なことは、現在のソースの状態以外のものを保持する必要があるかどうかということです。 現在のソースをそのまま使用して新しいプロジェクトを開始することに問題がない場合は、それを新しいプロジェクトのように処理し、ソースをリポジトリにアップロードするのが最善の選択肢です。
ただし、バージョンコントロールの履歴を保持する場合は、GitHub Migrator ツールを使用してインポートする必要があります。 さまざまなバージョン コントロール プラットフォームに対するインポートのサポートの詳細については、「サードパーティのバージョン管理システムからのデータのインポート」を参照してください。
Git データ以外では、イシュー、pull request、またはその他のデータを保持したい場合があります。 これらの項目のサポートはプラットフォームによって異なり、一般にコミュニティ プロジェクトで提供されています。 このモジュールでは、Git 以外のデータの移行については説明しません。
プロジェクトに現在格納されているバイナリ ファイルの処理
ベスト プラクティスとして、GitHub リポジトリは、プロジェクトのビルドに必要なファイルに制限する必要があります。 ビルド成果物など、大きなバイナリ ファイルはコミットしないようにします。 スプレッドシートやプレゼンテーションなどのバイナリ ファイルは、適切に処理してバージョン コントロールができるポータルで追跡する方が適しています。 大きなバイナリ ファイルをバージョン管理する必要がある場合は、Git LFS (Large File Storage) という Git の拡張機能を使用することを検討してください。
.gitignore などの重要な Git ファイルを作成する
Git では、ファイルのバージョン コントロール ポリシーを適用する .gitignore ファイルをサポートしています。 これらのファイルでは、ソース管理の追跡からファイルやフォルダーを除外するための検索パターンが定義されます。 次のシンプルな例では、Bin または bin という名前のすべてのフォルダーとその内容を、ソース管理の追跡から再帰的に除外します。
[Bb]in/
詳細については、「ファイルを無視する」を参照してください。 また、gitignore リポジトリでさまざまなプラットフォーム用に提供されているスターター .gitignore ファイルも確認してください。
GitHub プロジェクトには、リポジトリの利用者や共同作成者にさまざまなポリシーを説明するために一般に使用されるファイルが他にもいくつかあります。 プロジェクトがプライベートで、対象ユーザーが限定されている場合でも、これらのポリシーを明確に示しておくのに便利です。 これらのファイルはいずれも必須ではありませんが、一般的なものをいくつか次に示します。
| ファイル | 目的 |
|---|---|
README.md |
ディレクトリのランディング ページ。 このページは、GitHub でディレクトリが表示されるときにレンダリングされます。 |
LICENSE.md |
コードの提供に使用されているライセンス。 |
CONTRIBUTING.md |
pull request で予想されることなど、ユーザーがプロジェクトに投稿する方法について説明します。 |
SECURITY.md |
プロジェクトのセキュリティ ポリシーについて説明します。 機密性の高いセキュリティ関連のコードや、対応する前に公開すべきではないフィードバックを送信するユーザーにガイダンスを提供します。 |
詳細については、「健全なコントリビューションを促すプロジェクトをセットアップする」を参照してください。
GitHub へのプロジェクトのインポート
リポジトリを移行する準備ができたら、GitHub リポジトリの [コード] タブに移動します。 [Import code] オプションを使用して、ソース リポジトリを指定します。
GitHub Migrator ツールが残りの処理を行います。
