エラーの説明
git status または git pull を実行すると、次のエラーが表示されます:
fatal: not a git repository (or any of the parent directories): .git
Git はディレクトリツリー全体を検索しましたが、どこにも .git フォルダが見つかりませんでした。どのリポジトリを指しているのか、Git には判断できません。
根本原因
すべての Git リポジトリのルートには、隠し .git ディレクトリが存在します。このフォルダには、コミット履歴、ブランチ参照、設定、トラッキングデータなど、Git の動作に必要なすべてが格納されています。.git がなければ、Git は機能しません。
主な原因は6つあります:
- リポジトリの外でコマンドを実行している(ディレクトリが間違っている)
- プロジェクトが
git initで初期化されていない .gitフォルダが誤って削除されたか、クリーンアップスクリプトによって削除された- サブディレクトリにクローンして、
.gitがある場所より1レベル上または下にいる - Docker コンテナや CI ジョブでリポジトリがマウントまたはクローンされていない
- リンクファイルが壊れた Git サブモジュールの中にいる
修正方法1:まず現在のディレクトリを確認する
ほとんどの場合、解決策はこれだけシンプルです — 単に間違ったフォルダにいるだけです。現在地を確認しましょう:
pwd
次に .git ディレクトリを探します:
ls -la | grep .git
何も表示されない? 間違った場所にいるか、リポジトリが初期化されていない可能性があります。
プロジェクトのルートディレクトリに移動して、再試行してください:
cd /path/to/your/project
git status
リポジトリがどこにあるかわからない場合は、検索してください:
# Linux/macOS
find ~ -name ".git" -type d 2>/dev/null
# Windows (PowerShell)
Get-ChildItem -Path C:\ -Filter .git -Recurse -Directory -ErrorAction SilentlyContinue
修正方法2:新しいリポジトリを初期化する
新規プロジェクトで Git リポジトリが初期化されていない場合、1つのコマンドで解決できます:
cd /path/to/your/project
git init
Git は次のメッセージで確認を表示します:
Initialized empty Git repository in /path/to/your/project/.git/
ファイルをステージして最初のコミットを作成します:
git add .
git commit -m "Initial commit"
GitHub や GitLab に接続する場合は、リモートを追加してプッシュします:
git remote add origin https://github.com/youruser/yourrepo.git
git branch -M main
git push -u origin main
修正方法3:リポジトリを再クローンする
誤って .git を削除してバックアップもない場合は、リモートから再クローンしましょう。これが最もクリーンな解決策です。
# 現在の(コミットされていない)ファイルをまず保存
mv /path/to/project /path/to/project_backup
# 新しいコピーをクローン
git clone https://github.com/youruser/yourrepo.git /path/to/project
クローン後、バックアップフォルダからコミットされていない変更を手動でコピーして戻してください。
修正方法4:クローン後に間違ったディレクトリにいる場合
よくある落とし穴:git clone を実行すると Git が新しいフォルダを作成しますが、次のコマンドを実行する前に cd で移動するのを忘れてしまいます。
# ここでクローンした:
git clone https://github.com/youruser/myproject.git
# Git が作成:./myproject/
# でも親ディレクトリにいる — git status が失敗する
# 修正:フォルダに入る
cd myproject
git status
修正方法5:CI/CD または Docker — チェックアウトステップの欠如
自動化パイプラインでは、このエラーはほぼ必ずリポジトリが実際にチェックアウトされる前に Git コマンドが実行されたことを意味します。GitHub Actions では、チェックアウトアクションを最初に実行する必要があります:
steps:
- name: コードをチェックアウト
uses: actions/checkout@v4 # ← 最初に実行する必要がある
- name: git log を実行
run: git log --oneline -5
Docker は別の話です。.git フォルダは .dockerignore によって暗黙的に除外されることが多いです。確認してください:
# この行がビルドコンテキストから .git を除外している:
.git
# コンテナ内で git 履歴が必要な場合は削除する
ボリュームをマウントする場合は、マウントするホストパスにソースファイルだけでなく .git フォルダも含まれていることを確認してください。
修正方法6:Git Worktree またはサブモジュール
サブモジュールや Worktree の中では、.git はディレクトリではなくファイルです。これは意図的なもので、実際の git データが別の場所を指しています:
cat .git
# gitdir: ../.git/worktrees/myworktree
そのファイルが欠落しているか破損している場合は、親リポジトリのルートから再初期化してください:
git submodule update --init --recursive
修正の確認
上記の修正を行った後、次の3つの確認を実行してください:
# ブランチ名とトラッキングされたファイルが表示されるはず
git status
# 最近のコミットが一覧表示されるはず
git log --oneline -5
# .git が存在しディレクトリであることを確認
ls -la .git
git status でブランチ情報が表示されれば完了です。
予防策
- **
.gitを神聖なものとして扱う。**プロジェクトのトラッキングを意図的に解除する場合を除き、手動で削除しないでください。このフォルダ全体がバージョン履歴そのものです。 - **バックアップを取る。**プロジェクトのバックアップにはソースファイルだけでなく
.gitも含めてください。 - **CI ではチェックアウトを最初に。**Git コマンドを実行するすべてのパイプラインは、最初にチェックアウトステップが必要です。これは絶対です。
- 頻繁に使用するコマンドをシェルエイリアスにまとめ、最初にプロジェクトルートへ
cdするようにすることで、間違ったディレクトリのミスを完全に排除できます。 - **コンテナ内で Git 履歴が必要な場合は
.dockerignoreを確認する。**見落としやすい暗黙的な除外設定です。

