既存のプロジェクを準備して GitHub にアップロードする方法

完了

このユニットでは、プロジェクトを GitHub にアップロードする場合の重要な考慮事項について説明します。

GitHub にアップロードする理由

GitHub の長所を称える文章は大量にあり、登録するように説得することは、このモジュールの範囲を超えています。 しかし、このモジュールでは、アップロードを計画する際に考慮する必要があるサブジェクトのコンテキスト内の主な利点の一部を要約します。

バージョン コントロール

GitHub では、使用されているバージョンコントロール システムとして、ほぼ間違いなく最良である Git を独占的に使用しています。 ただし、Git は非常に高度です。Git を使用すると、あなたのチームが経験したことのない可能性のある複雑なコードを扱うシナリオを作成することができます。 Git を使用する開発者にとって、"ブランチ" と pull request は日常の作業の基本部分であり、GitHub を使いこなすには、これらを効果的に使用するタイミングと方法を理解している必要があります。 チームがまず GitHub のフローに精通していることが重要です。そうすれば、すぐに全力で取り組むことができます。

コードをクラウドに保持する

多くのプロジェクト コードは、まだ開発者のコンピューターにのみ保存されています。 あなたのコードが GitHub にアップロードされた場合、それはチーム メンバーがどこからでも簡単にアクセスできる、GitHub のクラウド プラットフォームに移行することになります。 この変更は、バージョン コントロールを行っているファイルとデータの種類に対するご自分のチームのポリシーを確認するよい機会になります。 ベスト プラクティスとして、GitHub にコミットするすべてのものがセキュリティ侵害されるおそれがあると想定する必要があります。 そのため、API キー、パスワード、または同等の情報を含む他のファイルなどの、機密データを含めないようにしてください。

Note

GitHub では、パブリックとプライベート両方のリポジトリおよびリポジトリのさまざまな部分に対するきめ細かいアクセス制御が提供されています。 これにより、プロジェクトを表示できるユーザーを制御したり、特定のユーザーが実行できる操作を制御したりすることができます。

コラボレーション

GitHub では、イシュー、pull request、コード レビューなどの機能により、チームのコラボレーションに対する優れたサポートが提供されています。 ただし、GitHub のフローは、現在のチームが使い慣れている方法とは異なる場合があります。 チームが GitHub にどのように適応するか、既存のプロセスを保持する必要があるかどうかを検討することをお勧めします。

あなたのプロジェクトが外部の共同作成者を受け入れるオープンソース プロジェクトである場合、メリットを最大にするのに GitHub より適した選択肢はありません。

GitHub にアップロードする

プランに関する考慮事項

GitHub にご自分のアップロードを行う前に最も重要なのは、自分のソースを現在の状態以上のものにして保持する必要があるかどうかということを考慮することです。 たとえば、修正しようとしているバグの追跡に、スプレッドシートやプロジェクトマネジメント ソフトウェアを使用している場合があります。 これらの項目の移行のサポートはプラットフォームによって異なり、コミュニティ プロジェクトから一般公開されています。 このモジュールでは、その種類のデータの移行については説明しません。

プロジェクトに現在格納されているバイナリ ファイルを処理する

ベスト プラクティスとして、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 にリポジトリを作成します。 作成したら、ご自分の GitHub リポジトリの [コード]タブに移動します。 このビューには、プロジェクト コードをアップロードする方法がいくつか用意されています。

Screenshot of importing code to a GitHub repository.

ご自分のソースをアップロードするには、git クライアントまたは Git 対応のツールを使用することをお勧めします。 または、[新しいファイルの作成] リンクから、手動で自分のファイルをアップロードすることもできます。 長期的には、git クライアントを使用して変更やブランチなどを管理するのが最適であることに気づかれるでしょう。