ファイル管理
GitHubのファイル管理機能は、単なるバージョン管理を超えて、開発者の日常業務を効率化する実用的なツールセットになっています。本記事では、基本的なファイル操作から大容量ファイルの扱い方まで、実務で使える情報を体系的にまとめます。
目次
1. 基本的なファイル操作
1.1. ファイルの作成
GitHubのWeb UIから直接ファイルを作成できます。書き込み権限があれば、リポジトリ内で即座に新規ファイルを追加可能です。
Web UIでの作成手順
制限事項
- Web UI経由のファイルサイズ上限:25 MiB
- ファイル名に使用可能な文字:英数字とハイフン(
-)のみ - その他の文字を使用する場合は、ローカルで作成してpushする必要があります
コマンドラインでの作成
より大きなファイル(最大100 MiB)を追加する場合は、コマンドラインを使用します。
# ファイルをステージング
git add .
# コミット
git commit -m "新規ファイルを追加"
# リモートにプッシュ
git push origin your_branch
1.2. ファイルの編集
リポジトリ内のファイルは、Web UI上で直接編集できます。
編集の流れ
- 編集したいファイルに移動
- 右上の鉛筆アイコンをクリック
- 内容を変更
- プレビューで確認(Markdownなど対応形式の場合)
- コミットメッセージを入力して保存
複数の編集モード
- デフォルトのファイルエディタ
- github.dev(より高機能なコードエディタ)
- GitHub Desktop(ローカル編集)
1.3. ファイルの移動
ファイルの移動も、Web UIまたはコマンドラインで実行できます。
Web UIでの移動
ファイル名フィールドで以下の操作が可能です:
- サブフォルダに移動:
フォルダ名/を入力 - 上位ディレクトリに移動:
../を入力 - 親フォルダ名を編集:Backspaceキーで編集
コマンドラインでの移動
# ファイルを物理的に移動
mv old-folder/image.png new-folder/image.png
# 変更をステージング
git add .
# 状態確認
git status
# コミット
git commit -m "ファイルを新しいディレクトリに移動"
# プッシュ
git push origin your_branch
1.4. ファイルの削除
個別ファイルまたはディレクトリ全体を削除できます。
重要な注意点
削除されたファイルがGitの履歴に残ることを理解しておく必要があります。機密情報を含むファイルを削除した場合、完全に除去するには履歴からの削除が必要です。
ディレクトリ削除の手順
- 削除したいディレクトリに移動
- 右上のケバブメニュー(三点アイコン)をクリック
- "Delete directory"を選択
- 削除されるファイルを確認
- コミットメッセージを入力して確定
ファイルサイズの制限と対応
GitHubには、パフォーマンスと信頼性を確保するため、ファイルサイズに制限があります。
サイズ制限の詳細
| 操作方法 | ファイルサイズ上限 | 動作 |
|---|---|---|
| Web UI経由のアップロード | 25 MiB | 超過するとエラー |
| コマンドライン経由 | 50 MiB | 警告が表示される(pushは成功) |
| コマンドライン経由 | 100 MiB | ブロックされる |
| Git LFS使用時 | プランによる | 後述参照 |
2.2. リポジトリサイズの推奨値
- 推奨サイズ:1 GB未満
- 強く推奨されるサイズ:5 GB未満
大きなリポジトリは、クローン速度の低下やメンテナンスの困難さにつながります。
2.3. 外部依存関係の管理
外部ライブラリやパッケージをリポジトリに含めないことが重要です。以下のパッケージマネージャーを活用してください:
- Ruby: Bundler
- JavaScript: npm / yarn
- Java: Maven / Gradle
- Python: pip / Poetry
Git Large File Storage (Git LFS)
100 MiBを超えるファイルを扱う場合、Git LFSが必須となります。
Git LFSの仕組み
Git LFSは、大容量ファイルの実体を別の場所に保存し、Gitリポジトリにはポインタファイルのみを格納します。
ポインタファイルの例
version https://git-lfs.github.com/spec/v1
oid sha256:4cac19622fc3ada9c0fdeadb33f88f367b541f38b89102a3f1261ac81fd5bcb5
size 84977953
このファイルには以下の情報が含まれます:
-
version: Git LFSのバージョン -
oid: ファイルの一意識別子 -
size: 実際のファイルサイズ
3.2. プランごとの最大ファイルサイズ
| プラン | 最大ファイルサイズ |
|---|---|
| GitHub Free | 2 GB |
| GitHub Pro | 2 GB |
| GitHub Team | 4 GB |
| GitHub Enterprise Cloud | 5 GB |
重要: 5 GBの上限を超えるファイルは、Git LFSでも拒否されます。
3.3. Git LFSのインストール
macOS
# Homebrewを使用
brew install git-lfs
# MacPortsを使用
port install git-lfs
# 初期化
git lfs install
Windows / Linux
- git-lfs.comからダウンロード
- インストーラーを実行
- ターミナルで初期化
git lfs install
3.4. Git LFSの設定
ファイルタイプの追跡設定
# PSDファイルを追跡
git lfs track "*.psd"
# 設定を確認
cat .gitattributes
この操作により、.gitattributesファイルが作成・更新されます。
重要な推奨事項
.gitattributesファイルは必ずリポジトリにコミットしてください。理由は以下の通りです:
- グローバル設定に依存すると、他のプロジェクトで競合する可能性があります
- フォークやクローンを作成する際、Git LFS設定が自動的に引き継がれます
- ZIPやtarballアーカイブにGit LFSオブジェクトを含めるかどうかの制御が可能になります
ファイルの追加とプッシュ
# ファイルを追加
git add path/to/file.psd
# コミット
git commit -m "PSDファイルを追加"
# プッシュ(進捗が表示される)
git push
出力例:
Sending file.psd
44.74 MB / 81.04 MB 55.21 % 14s
64.74 MB / 81.04 MB 79.21 % 3s
3.5. 既存ファイルのGit LFS移行
リポジトリに既に存在する大容量ファイルをGit LFSに移行する場合:
# 履歴から削除(filter-repoを使用)
git filter-repo --path path/to/large-file.bin --invert-paths
# Git LFSで追跡を設定
git lfs track "*.bin"
# 再度追加
git add path/to/large-file.bin
# コミットしてプッシュ
git commit -m "大容量ファイルをGit LFSに移行"
git push
3.6. Git LFSファイルの削除
単一ファイルの削除
- 履歴から削除(
git filter-repoを使用) -
.gitattributesから該当する追跡ルールを削除 - 変更を保存してコミット
すべてのGit LFSファイルを削除
# Git LFSをアンインストール
git lfs uninstall
# 古いバージョン(1.1.0未満)の場合
git lfs uninit
注意: Git LFSオブジェクトはリモートストレージに残り続けます。完全に削除するには、リポジトリ自体を削除して再作成する必要があります。
3.7. 協業時の注意点
Git LFSがインストールされていない共同作業者は、実際のファイルではなくポインタファイルのみを取得します。
対応策
- READMEにGit LFSのインストール手順を記載
- 大容量ファイルの変更を避けるようガイドラインを設定
- 必要に応じて、DropboxやGoogle Driveなどのファイル共有サービスを併用
フォークへのプッシュ
フォークに大容量ファイルをプッシュする場合、帯域幅とストレージのクォータは親リポジトリにカウントされます。
コードナビゲーション機能
GitHubのコードナビゲーション機能により、定義へのジャンプや参照の検索が可能になります。
対応言語
以下の言語で、定義と参照のナビゲーションが利用できます:
- Bash, C, C#, C++
- CodeQL, Elixir, Go
- Java, JavaScript, JSX
- Lua, PHP, Protocol Buffers
- Python, R, Ruby
- Rust, Scala, Starlark
- Swift, TypeScript
4.2. シンボルパネルの使用
使用方法
- シンボル(関数、クラスなど)を含むファイルを開く
- ファイルコンテンツの上部にあるシンボルアイコンをクリック
- シンボルパネルから目的のシンボルを選択
- 検索範囲を選択:
- このファイル内
- このリポジトリ内
- すべてのリポジトリ
4.3. 定義へのジャンプ
関数やメソッドの呼び出し部分をクリックすると、その定義に直接ジャンプできます。
4.4. すべての参照を検索
関数やメソッドの呼び出し部分をクリックして、リポジトリ内のすべての参照箇所を表示できます。
4.5. GitHub Copilotによる理解支援
GitHub Copilotを使用して、コードの理解を深めることができます。
使用方法
- ファイル全体について質問:右上のCopilotアイコンをクリック
- 特定の行について質問:
- 行番号をクリックして範囲を選択
- 選択範囲の右側のCopilotアイコンをクリック
- 質問を入力
質問例
ファイル全体に対して:
- このファイルの説明をしてください
- このコードを改善する方法はありますか
- このスクリプトをテストする方法は
特定の行に対して:
- 選択した行の関数を説明してください
- このクラスを改善できますか
- このコードにエラーハンドリングを追加してください
- このメソッドの単体テストを書いてください
4.6. パーマリンクの取得
ファイルを表示中にyキーを押すと、URLが特定のコミットIDを含むパーマリンクに更新されます。
URL形式の比較
通常のURL(ブランチ参照):
https://github.com/tanaka-repo/codeql/blob/main/README.md
パーマリンク(コミットID参照):
https://github.com/tanaka-repo/codeql/blob/b212af08a6cffbb434f3c8a2795a579e092792fd/README.md
パーマリンクを使用すると、将来ブランチが更新されても、常に同じバージョンのファイルを参照できます。
多様なファイル形式のサポート
GitHubは、コードだけでなく、さまざまなファイル形式のレンダリングに対応しています。
画像ファイル
対応形式
- PNG, JPG, GIF, SVG, PSD
差分表示モード
画像の変更を視覚的に比較できる3つのモードがあります:
- 2-up(デフォルト): 新旧の画像を並べて表示。サイズ変更も数値で確認可能
- Swipe: スライダーで新旧の画像を切り替え表示
- Onion skin: 透明度スライダーで新旧の画像を重ねて表示
5.2. 3Dファイル(STL形式)
.stl拡張子のファイルは、インタラクティブな3Dビューアで表示されます。
操作方法
- ドラッグ:モデルを回転
- 右クリック+ドラッグ:視点を移動
- スクロール:ズームイン/アウト
他サイトへの埋め込み
<script src="https://embed.github.com/view/3d/tanaka/secret-bear-clip/master/stl/clip.stl"></script>
サイズのカスタマイズも可能です:
<script src="https://embed.github.com/view/3d/tanaka/secret-bear-clip/master/stl/clip.stl?height=300&width=500"></script>
5.3. CSV/TSVファイル
カンマ区切り(.csv)やタブ区切り(.tsv)のファイルは、インタラクティブなテーブルとして表示されます。
機能
- ヘッダー行と行番号の自動表示
- 検索バーでデータのフィルタリング
- 特定の行へのリンク(行番号をクリック)
- 複数行の選択(Shiftキーを押しながら)
制限事項
- ファイルサイズ:512 KB以下
- 各行の列数が一致している必要があります
- サポートされる区切り文字:カンマまたはタブ(セミコロンは不可)
5.4. PDFドキュメント
PDFファイルは、GitHub上で直接レンダリングされます。ただし、PDF内のリンクは現在無視されます。
5.5. Jupyter Notebook
.ipynb拡張子のファイルは、静的HTMLとして表示されます。
制限事項
- JavaScriptを使用したインタラクティブな機能は動作しません
- カスタムプロットなどは表示されません
代替手段
- nbviewerでJavaScriptコンテンツをレンダリング
- ローカルでNotebookサーバーを起動して完全なインタラクティブ環境を使用
トラブルシューティング
レンダリングに失敗する場合、コマンドラインで変換できます:
jupyter nbconvert --to html notebook-name.ipynb
5.6. Mermaid図
.mermaidまたは.mmd拡張子のファイルは、フローチャートやシーケンス図として表示されます。
ファイル例
Markdown内での使用
Mermaid構文をMarkdownに直接埋め込むこともできます。
既知の問題
- シーケンス図で余白が多めに表示される場合があります
- ポップオーバーメニュー付きのアクターノードが正しく動作しない場合があります
- すべての図がアクセシビリティ対応しているわけではありません
5.7. GeoJSON/TopoJSON
地図データファイル(.geojson、.topojson、.json)は、Leaflet.jsを使用してインタラクティブな地図として表示されます。
対応するジオメトリタイプ
- Point, LineString, Polygon
- MultiPoint, MultiLineString, MultiPolygon
- GeometryCollection
他サイトへの埋め込み
<script src="https://embed.github.com/view/geojson/suzuki/dc-wifi-social/master/bars.geojson"></script>
サイズのカスタマイズ:
<script src="https://embed.github.com/view/geojson/suzuki/dc-wifi-social/master/bars.geojson?height=300&width=500"></script>
トラブルシューティング
- ポイントが予期しない場所(海の真ん中など)に表示される場合、投影法が原因の可能性があります
- GitHub は
urn:ogc:def:crs:OGC:1.3:CRS84投影のみサポートしています - 10 MBを超えるファイルはブラウザでレンダリングできません
- TopoJSON形式に変換すると、最大80%ファイルサイズを削減できます
5.8. Markdown文書の差分表示
Markdownファイルのコミットやプルリクエストでは、ソースビューとレンダリングビューの両方で変更を確認できます。
機能
- 追加・削除された文字列のハイライト
- 属性変更のツールチップ表示(例:リンクURL変更)
- ヘッダーへのリンク機能
- 行単位でのコメント機能
レンダリングを無効化
ファイル上部の"Code"ボタンをクリックすると、Markdownレンダリングを無効にしてソースを表示できます。これにより、行リンクなどのソース表示機能が使用可能になります。
6. 運用上の注意点
6.1. 保護されたブランチ
保護されたブランチでは、Web UIを使用したファイルの編集やアップロードができません。
対応方法
- GitHub Desktopを使用して新しいブランチに変更を移動
- そのブランチで変更をコミット
- プルリクエストを作成
6.2. プッシュルールセット
リポジトリにプッシュルールセットが設定されている場合、特定の制限に基づいて新規ファイルの作成がブロックされることがあります。
重要な特徴
- ルールセットはフォークネットワーク全体に適用されます
- 親リポジトリで設定されたルールセットは、すべてのフォークにも適用されます
6.3. プッシュプロテクション
プッシュプロテクションが有効な場合、トークンなどの機密情報を含むファイルのアップロードがブロックされます。
対応方法
- ファイルから機密情報を削除
- 再度アップロードを試行
注意: Web UIでのファイルアップロードに対するプッシュプロテクションは、現在パブリックプレビュー中です。
6.4. .gitattributesファイルの扱い
.gitattributesファイルのロジックを適用する必要がある場合(例:改行の自動変換)、Gitを使用してファイルをプッシュする必要があります。
Web UIを通じてアップロードされたファイルは、.gitattributesを無視します。
6.5. 機密情報の取り扱い
絶対にコミットしてはいけない情報
- パスワード
- APIキー
- トークン
- その他の認証情報
万が一コミットしてしまった場合
履歴から完全に削除する必要があります。単にファイルを削除するだけでは、Git履歴に残り続けます。
# filter-repoを使用して履歴から削除
git filter-repo --path path/to/sensitive-file --invert-paths
6.6. リポジトリの健全性
リポジトリの健全性は、以下の要因の相互作用によって決まります:
- サイズ
- コミット頻度
- コンテンツ
- 構造
大きすぎるリポジトリは、パフォーマンスと信頼性に影響を与えるため、GitHub Supportから是正措置を求められる場合があります。
6.7. ソースコードアーカイブの安定性
GitHubが生成するZIPファイルやtarballには、安定性に関する重要な特性があります:
保証される内容
- コミットIDのアーカイブは、リポジトリ名が変わらない限り、常に同じファイル内容を持ちます
- ブランチやタグのアーカイブは、それらが同じコミットを指している限り、同じ内容です
変更される可能性のある内容
- 圧縮設定(ただし、変更の6ヶ月前に通知されます)
- リポジトリ名(アーカイブ内のルートディレクトリ名に影響します)
再現性が必要な場合
コミットIDを指定してArchives REST APIを使用することを推奨します。
セキュリティが重要な場合
ソースダウンロードではなく、Releasesを使用することを推奨します。リリースでは、検証済みのアセットを配布できます。
6.8. ファイルの表示カスタマイズ
.gitattributesファイルを使用して、特定のファイルを差分表示から除外したり、言語統計から除外したりできます。
例:生成されたファイルをマーク
search/index.json linguist-generated
例:通常生成ファイルとされるものをマーク解除
bootstrap.min.css -linguist-generated
7. まとめ
GitHubのファイル管理機能は、単なるバージョン管理を超えた実用的なツールセットです。本記事で紹介した機能を活用することで、以下のメリットが得られます。
効率化の観点
- Web UIでの直接編集による作業の迅速化
- コードナビゲーション機能による理解の促進
- 多様なファイル形式の視覚化による確認作業の効率化
大規模プロジェクトへの対応
- Git LFSによる大容量ファイルの効率的な管理
- パッケージマネージャーを活用した依存関係の適切な管理
- リポジトリサイズの最適化
チーム協業の円滑化
- パーマリンクによる正確なコード参照
- 画像差分などの視覚的な変更確認
- 適切な権限管理とプロテクション機能
これらの機能を理解し、プロジェクトの特性に応じて適切に使い分けることが重要です。特にGit LFSの導入は、大容量ファイルを扱うプロジェクトにおいて必須となるため、早い段階での検討をお勧めします。