リポジトリの作成
GitHubのリポジトリは、単なるコードの保管場所ではありません。適切に管理すれば、チームの生産性を飛躍的に向上させ、プロジェクトの品質を根本から変える強力なツールになります。このガイドでは、GitHubの公式ドキュメントをもとに、リポジトリの作成と管理に関する実践的な知識を解説します。
1. リポジトリの基本概念
1.1 リポジトリとは
リポジトリは、プロジェクトのすべてのコード、ファイル、そして各ファイルの変更履歴を保存する場所です。複数の協力者と作業でき、公開または非公開に設定できます。
1.2 重要な用語
| 用語 | 説明 |
|---|---|
| ブランチ | リポジトリ内に含まれる並行バージョンのコード。メインブランチには影響しません |
| クローン | GitHub.comからすべてのバージョンを含む完全なコピーをダウンロードすること |
| フォーク | 元のリポジトリとコードと可視性設定を共有する新しいリポジトリ |
| マージ | あるブランチの変更を別のブランチに適用すること |
| プルリクエスト | あるブランチから別のブランチへの変更のマージを要求すること |
| リモート | ローカルではなくGitHub上に保存されているリポジトリ |
| 上流(Upstream) | フォークまたはクローンされた元のリポジトリのブランチ |
2. リポジトリの制限値
パフォーマンスと管理性を最適化するため、以下の制限値を守ることを推奨します。
2.1 サイズとストレージの制限
| 項目 | 推奨最大値 | 強制値 |
|---|---|---|
| ディスク容量 | 10GB | - |
| 単一ディレクトリ内のエントリ数 | 3,000 | - |
| ディレクトリの深さ | 50 | - |
| ブランチ数 | 5,000 | - |
| プッシュサイズ | - | 2GB |
| 単一オブジェクトサイズ | 1MB | 100MB |
大容量ファイルの取り扱い
1MB以上のファイルには、Git Large File Storage (Git LFS)の使用を推奨します。バイナリファイルはGit LFSで管理し、プログラムで生成されるファイルはオブジェクトストレージに保存することで、リポジトリサイズを抑制できます。
2.2 アクティビティの制限
| 操作 | 推奨最大値 |
|---|---|
| Git読み取り操作 | 15回/秒/リポジトリ |
| プッシュレート | 6回/分/リポジトリ |
| オープン中のプルリクエスト（同一ブランチ対象） | 1,000件 |
| プルリクエストのマージレート | 1件/分 |
2.3 差分表示の制限
| 項目 | 制限値 |
|---|---|
| プルリクエストの総差分 | 20,000行または1MB |
| 単一ファイルの差分 | 20,000行または500KB |
| 単一差分内の最大ファイル数 | 300 |
| レンダリング可能なファイル数 | 25 |
3. リポジトリの作成
3.1 Web UIからの作成
3.2 URLクエリでフォームを事前入力
教育現場などで同じ設定のリポジトリを複数作成する際に便利です。
クエリパラメータの例
https://github.com/new?name=test-repo&owner=tanaka-corp&visibility=private&description=新しいプロジェクト
| パラメータ | 使用例 | 有効な値 |
|---|---|---|
name |
name=test-repo |
有効なリポジトリ名（スペースは+または%20） |
description |
description=素晴らしいプロジェクト |
任意の文字列 |
visibility |
visibility=private |
public, private
|
owner |
owner=tanaka-corp |
組織名またはユーザー名、@meで自分を指定 |
template_owner |
template_owner=tanaka-corp |
テンプレート所有者のユーザー名 |
template_name |
template_name=octo-repo |
テンプレートリポジトリ名 |
3.3 Copilot Chatからの作成
Visual Studio CodeでModel Context Protocol (MCP)を使用して、Copilot Chatから直接リポジトリを作成できます。
4. テンプレートリポジトリの活用
4.1 テンプレートリポジトリとは
既存のリポジトリをテンプレート化することで、同じディレクトリ構造、ブランチ、ファイルを持つ新しいリポジトリを素早く生成できます。
4.2 フォークとの違い
4.3 テンプレートリポジトリの作成手順
- リポジトリを作成
- リポジトリの設定画面に移動
- 「Template repository」にチェック
注意点
- テンプレートリポジトリにはGit LFSで保存されたファイルを含めることができません
- GitHub Classroomで課題のスターターコードとして使用できます
5. クローンの実践
5.1 基本的なクローン手順
# リポジトリのURLをコピーした後
cd ~/projects
git clone https://github.com/ユーザー名/リポジトリ名.git
実行結果:
Cloning into 'リポジトリ名'...
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 10 (delta 1), reused 10 (delta 1)
Unpacking objects: 100% (10/10), done.
5.2 クローン方法の選択
| 方法 | 使用場面 | コマンド例 |
|---|---|---|
| HTTPS | 最も一般的、パーソナルアクセストークンで認証 | git clone https://github.com/... |
| SSH | SSH鍵を設定済みの場合、パスワード不要 | git clone git@github.com:... |
| GitHub CLI | GitHub CLIを使用している場合 | gh repo clone ... |
5.3 空のリポジトリのクローン
READMEなしでリポジトリを作成した場合でも、クローンは可能です。
git clone https://github.com/ユーザー名/空リポジトリ名.git
6. リポジトリの複製とミラーリング
6.1 単純な複製
フォークせずにリポジトリのミラーを維持する方法です。
# ベアクローンを作成
git clone --bare https://github.com/元ユーザー/元リポジトリ.git
# ミラープッシュ
cd 元リポジトリ
git push --mirror https://github.com/新ユーザー/新リポジトリ.git
# 一時的なローカルリポジトリを削除
cd ..
rm -rf 元リポジトリ
6.2 Git LFSオブジェクトを含む複製
# ベアクローン
git clone --bare https://github.com/元ユーザー/元リポジトリ.git
cd 元リポジトリ
# LFSオブジェクトを取得
git lfs fetch --all
# ミラープッシュ
git push --mirror https://github.com/新ユーザー/新リポジトリ.git
# LFSオブジェクトもプッシュ
git lfs push --all https://github.com/新ユーザー/新リポジトリ.git
# クリーンアップ
cd ..
rm -rf 元リポジトリ
6.3 定期的に更新するミラー
別の場所にミラーを作成し、元のリポジトリから定期的に更新を取得する方法です。
# ミラーされたクローンを作成
git clone --mirror https://github.com/元ユーザー/ミラー対象リポジトリ.git
# プッシュ先を設定
cd ミラー対象リポジトリ
git remote set-url --push origin https://github.com/新ユーザー/ミラー先.git
# 更新を取得してプッシュ
git fetch -p origin
git push --mirror
7. トラブルシューティング
7.1 よくあるHTTPSエラー
エラー例
error: The requested URL returned error: 401 while accessing
https://github.com/ユーザー名/リポジトリ名.git/info/refs?service=git-receive-pack
fatal: HTTP request failed
解決手順
- Gitバージョンの確認
git --version
バージョン1.7.10以上を推奨します。
- リモートURLの確認
git remote -v
出力例:
origin https://github.com/佐藤/cocoareactive.git (fetch)
origin https://github.com/佐藤/cocoareactive.git (push)
リモートURLが正しくない場合:
git remote set-url origin https://github.com/佐藤/ReactiveCocoa.git
- アクセストークンの提供
パスワードの代わりにパーソナルアクセストークンを使用する必要があります。
- 権限の確認
リポジトリへのアクセス権限があることを確認します。
7.2 Repository not foundエラー
このエラーが表示される場合、以下を確認します。
原因と対処法
| 原因 | 対処法 |
|---|---|
| タイプミス | リポジトリページからクローンURLをコピー&ペーストする |
| 権限不足 | オーナー、コラボレーター、またはチームメンバーであることを確認 |
| SSH設定の問題 |
ssh -T git@github.comでSSHアクセスを確認 |
| リポジトリが存在しない | GitHub.com上でリポジトリの存在を確認 |
7.3 デフォルトブランチが存在しないエラー
warning: remote HEAD refers to nonexistent ref, unable to checkout.
解決方法
- リポジトリの管理者権限が必要
- GitHub.comでデフォルトブランチを変更
- 利用可能なブランチを確認:
git branch -a
- 新しいブランチに切り替え:
git checkout new-main
8. リポジトリの移転
8.1 移転の影響範囲
リポジトリを移転すると、新しいオーナーは即座に以下を管理できます。
8.2 前提条件
- リポジトリの管理者権限が必要
- 個人アカウント間で移転する場合、新しいオーナーは確認メールを受け取り、1日以内に承認が必要
- 組織に移転する場合、対象組織でリポジトリ作成権限が必要
- 対象アカウントに同名のリポジトリまたは同一ネットワークのフォークが存在しないこと
8.3 移転手順
- リポジトリのメインページに移動
- Settingsタブをクリック
- ページ下部のDanger Zoneセクションで「Transfer」をクリック
- 新しいオーナーを指定
- 必要に応じてリポジトリ名を変更（組織のオーナーである場合のみ）
- リポジトリ名を入力して確認
- 「I understand, transfer this repository」をクリック
8.4 移転後の推奨作業
既存のローカルクローンのリモートURLを更新します。
git remote set-url origin 新しいURL
8.5 重要な注意事項
プライベートリポジトリからGitHub Freeアカウントへの移転
保護されたブランチやGitHub Pagesなどの機能へのアクセスが失われます。
GitHub Marketplaceに掲載されているアクション
移転すると、元のオーナー名とリポジトリ名の組み合わせは永久に引退扱いになります。そのアクションを使用しているワークフローは失敗します。
リダイレクトの削除
元の場所に新しいリポジトリまたはフォークを作成すると、移転されたリポジトリへのリダイレクトは永久に削除されます。
9. リポジトリの削除と復元
9.1 削除の影響
9.2 削除手順
- リポジトリのメインページに移動
- Settingsタブをクリック
- Generalページ（デフォルトで選択）を下にスクロール
- Danger Zoneセクションで「Delete this repository」をクリック
- 「I want to delete this repository」をクリック
- 警告を読む
- 削除するリポジトリ名を入力
- 「Delete this repository」をクリック
9.3 復元の条件
- 復元可能期間: 削除から90日以内
- 復元不可のケース: リポジトリが現在空でないフォークネットワークの一部だった場合
- 復元されないもの: リリース添付ファイル、チーム権限
- Issueのラベル: 復元されたIssueにはラベルが付きません
9.4 復元手順（個人アカウント）
- 画面右上のプロフィール写真をクリック
- Settingsを選択
- サイドバーのRepositoriesをクリック
- Deleted repositoriesをクリック
- 復元したいリポジトリの横のRestoreをクリック
- 警告を読んで「I understand, restore this repository」をクリック
9.5 復元手順（組織）
- 画面右上のプロフィール写真をクリック
- Organizationsを選択
- 組織の横のSettingsをクリック
- 左サイドバーのDeleted repositoriesをクリック
- 復元したいリポジトリの横のRestoreをクリック
- 警告を読んで確認
10. ベストプラクティス
10.1 READMEファイルの作成
すべてのリポジトリにREADMEファイルを作成することを推奨します。READMEは、プロジェクトの重要な情報を伝え、期待を明確にします。
READMEに含めるべき内容
- プロジェクトの概要と目的
- インストール方法
- 使用方法
- 貢献方法へのリンク
- ライセンス情報
- 連絡先情報
10.2 リポジトリのセキュリティ確保
最低限、公開リポジトリで無料で利用できる以下の機能を有効にします。
| 機能 | 説明 |
|---|---|
| Dependabotアラート | 依存関係ネットワークのセキュリティ脆弱性を通知 |
| シークレットスキャン | APIキーやトークンなどのシークレットをスキャン |
| プッシュ保護 | サポートされているシークレットを含むプッシュをブロック |
| コードスキャン | コード内の脆弱性とエラーを識別 |
追加の推奨事項
-
SECURITY.mdファイルをリポジトリに追加し、セキュリティ脆弱性の報告方法を記載 - リポジトリの「Private vulnerability reporting」を有効化
10.3 ブランチングをフォーキングより優先
定期的なコラボレーターには、単一のリポジトリから作業し、リポジトリ間ではなくブランチ間でプルリクエストを作成することを推奨します。
フォークが適しているケース
- オープンソース貢献者など、プロジェクトと提携していない人からの貢献
ブランチングのメリット
10.4 Git Large File Storageの使用
GitHubは、リポジトリで許可されるファイルサイズに制限を設けています。大容量ファイルを追跡するには、Git LFS (Large File Storage)を推奨します。
Git LFSの利点
- 大容量ファイルをGitリポジトリで効率的に管理
- クローンとフェッチの速度を改善
- リポジトリサイズを抑制
11. リポジトリビューの管理
11.1 保存されたビューの作成
複数の組織にわたるリポジトリを監視し、見つけやすくするために、リポジトリダッシュボードで保存されたビューを作成できます。
作成手順
- 画面上部でリポジトリアイコンをクリック
- 左サイドバーのViewsの下で新規ビューアイコンをクリック
- タイトル、説明、カスタムアイコンを追加
- Queryの下で、高度なフィルターを使用して検索クエリを構築
- Save viewをクリック
便利なフィルター
organization:tanaka-corp props.key:value
組織のカスタムプロパティでリポジトリを検索できます。
制限事項
- 最大25個の保存されたビューを作成可能
11.2 ビューの編集と削除
- 画面上部でリポジトリアイコンをクリック
- 左サイドバーで編集したい保存されたビューをクリック
- ビュー名の右側のメニューアイコンをクリック
- Edit（編集）、Duplicate（複製）、またはDelete（削除）を選択
12. コラボレーションの実践
12.1 個人リポジトリでのコラボレーション
他のユーザーをコラボレーターとして招待することで、所有するリポジトリで他の人と協力できます。
コラボレーションツール
| ツール | 用途 |
|---|---|
| Issue | ユーザーフィードバックの収集、ソフトウェアバグの報告、タスクの整理 |
| GitHub Discussions | 質問と回答、情報共有、お知らせ、会話の実施 |
| プルリクエスト | リポジトリへの変更提案 |
| Projects | Issueとプルリクエストの整理と優先順位付け |
12.2 プライベートフォークの権限継承
プライベートフォークは上流リポジトリの権限構造を継承します。これにより、プライベートリポジトリのオーナーはコードの管理を維持できます。
重要な注意点
- チーム権限のみが継承されます（個人権限は継承されません）
- 組織の基本権限を変更しても、プライベートフォークの権限は自動更新されません
12.3 後継者の指定
個人アカウント所有のリポジトリを管理できなくなった場合に備えて、別のGitHubユーザーを後継者として招待することを推奨します。
後継者ができること
- 公開リポジトリをアーカイブ
- 公開リポジトリを自分のユーザーアカウントに移転
- 公開リポジトリをリポジトリ作成権限のある組織に移転
後継者の制限
- アカウントにログインすることはできません
- 死亡証明書提示後7日間、または死亡記事提示後21日間待機する必要があります
13. まとめ
GitHubのリポジトリの作成と管理は、プロジェクトの成功を左右する重要な要素です。このガイドで紹介した制限値、ベストプラクティス、トラブルシューティング手法を活用することで、以下を実現できます。
実現できること
- パフォーマンスの最適化
- セキュリティの強化
- チームコラボレーションの効率化
- プロジェクトの長期的な維持管理性の向上
特に重要なのは、リポジトリサイズの管理、セキュリティ機能の有効化、そして適切なブランチング戦略です。これらを実践することで、スケーラブルで安全なコードベースを構築できます。
GitHub Docsは常に更新されているため、最新の情報を確認することをお勧めします。このガイドが、あなたのプロジェクトをより効果的に管理するための一助となれば幸いです。