git init コマンドは、指定したディレクトリに新しい Git リポジトリを初期化するためのコマンドです。
バージョン管理を開始するときに最初に実行される基本コマンドです。
Gitで使用されるコマンドなので、あらかじめ「Git」や「Bash」での操作方法を理解しておくことをおススメします。
git init の概要と用途
git init は、実行したディレクトリを Git リポジトリとして初期化します。具体的には、カレント（または指定）ディレクトリ直下に .git/ が作成され、以下のようなバージョン管理に必要なメタデータが配置されます。
何が起こるか（.git ディレクトリ生成・メタデータ格納）
objects/：コミットやツリー、ブロブなど、履歴の実体（オブジェクト）を保存refs/：ブランチやタグが指す参照（ポインタ）HEAD：現在チェックアウトしているブランチを指す参照（初期は未コミット状態）config：このリポジトリ固有の設定（ユーザー名・メールは通常はグローバル設定）hooks/：コミット時などに走らせるフックを配置できるディレクトリinfo/：グローバルではない除外設定などを置ける場所（excludeなど）
この .git/ が 履歴・設定・参照のすべてを担う心臓部です。
作業ツリー（ワークツリー）は .git/ の外側にある普段のファイル群で、git add→git commit によって変更が履歴（objects/）として保存されていきます。
なお、初期ブランチ名は環境設定（例：init.defaultBranch）に従い、main などで開始できます。
すばやく確認：
git init ls -a # .git/ ができている git status # まだコミットがない初期状態
いつ使うか・どのような場面で必要か
git init は 「今あるディレクトリをその場で Git 管理下に置きたい」 ときに使います。代表的なケースは次のとおり。
- 新規プロジェクトを始めるとき
空のフォルダを作ってgit init→ 最初のファイルを作成 →add/commitで履歴化。 - 既存コードを後からバージョン管理したいとき
既に動いているプロジェクトや配布物（ZIP 展開など）に対して、後追いで履歴管理を開始。 - テンプレートやスキャフォールド直後
フレームワークの雛形を生成した後、すぐに履歴化して変更追跡を始める。 - 共有サーバーで “裸の履歴” を置きたい（概念理解）
作業ツリーを持たない ベアリポジトリ（git init --bare）はチームの“受け皿”として使うことがある（詳細は後述セクションで解説）。
一方で、既存のリモートを複製して始めたい場合は git clone を使うのが基本です。
clone は初期化だけでなく 履歴の取得・初期ブランチのチェックアウト・origin の設定まで自動で行います。ローカルから始めたい／手元のフォルダをそのまま履歴化したいなら git init、既存リポジトリから受け継ぎたいなら git clone、という使い分けが実務では定番です。
ありがちな注意点：
- ホームディレクトリ等で誤って
git initすると、配下すべてが管理対象候補になり混乱の元に。場所を確認してから実行しましょう。- 既にリポジトリの中で
git initを再実行しても通常は害はありませんが、目的なく繰り返す必要はありません。- 初期ブランチ名を
mainに揃えたい場合は、事前にgit config --global init.defaultBranch main
を設定しておくと毎回指定せずに済みます。
構文（Syntax）
git init [オプション] [ディレクトリ]
主なオプション一覧
| オプション | 説明 | 使用例 |
|---|---|---|
| （なし） | カレントディレクトリにリポジトリを作成 | git init |
ディレクトリ | 指定ディレクトリにリポジトリを作成 | git init myproject |
--bare | 作業ツリーを持たないベアリポジトリを作成 | git init --bare project.git |
--initial-branch=NAME | 初期ブランチ名を指定（デフォルトは master または設定値） | git init --initial-branch=main |
-q, --quiet | 出力を抑制して実行 | git init -q |
応用オプション（知っていると便利）
--template=<dir>：テンプレート適用
指定ディレクトリにある hooks/ や info/attributes などを新規リポジトリへコピーします。社内共通のフック・属性・除外設定を配布するのに便利。
git init --template=/opt/git-templates
--separate-git-dir=<gitdir>：.git を別ディレクトリに分離
作業ツリー内ではなく、.git（実体）を別の場所に置きたいときに使用。大規模モノレポや特殊な配置要件に。
git init --separate-git-dir=/var/lib/git/meta my-worktree
--shared[=<perm>]：共有権限のプリセット
新規リポジトリのファイルモード（パーミッション）を、共同利用に向けて緩めに設定します。group（または true）、all（world）、umask、数値（0xxx）などが指定可。
# 同一グループで共同運用しやすい権限に
git init --shared=group /srv/git/shared-repo.git
- 使いどころ：同一サーバー上で複数ユーザーが同一リポジトリを操作する運用
- 注意：実際のアクセス可否は OS 側のユーザー/グループ設定にも依存
--object-format=<fmt>：オブジェクト形式の選択（環境依存）
オブジェクトハッシュ形式（例：sha1 / sha256）を指定します。利用可否は Git のバージョンやビルド設定に依存します。
# 例：SHA-256 形式で初期化（対応環境のみ）
git init --object-format=sha256
- 注意：異なるオブジェクト形式間の互換や運用は要理解。既存ツール群との相性も確認を
どれをいつ使う？クイック指針
- ローカルで普通に始めたい：
git init（必要なら-b main） - 共有サーバーに“受け皿”を作る：
git init --bare [--shared=group] - チームルールやフックを配りたい：
git init --template=... .gitを別ディレクトリに置きたい：git init --separate-git-dir=...- 将来のハッシュ形式を試す/要件がある：
git init --object-format=...（対応環境のみ）
実務では
-b main／--bare／--shared／--templateあたりの出番が多め。スクリプティング時は-qを添えてログを静かにする、が定番です。
実行例とユースケース
カレントディレクトリをリポジトリ化
いま居るフォルダをそのまま Git 管理にします。
# プロジェクト直下で
git init
# 例: Initialized empty Git repository in /path/to/project/.git/
git status # まだコミットなし（Untracked が表示される）
git add .
git commit -m "initial commit"
確認ワンライナー
git rev-parse --is-inside-work-tree # true が返ればリポジトリ内
新しいディレクトリで初期化
指定名のフォルダを作って、その中を初期化します。
git init myapp # myapp/.git が作成される
cd myapp
touch README.md
git add README.md
git commit -m "chore: bootstrap repo"
初期ブランチ名を main に指定
プロジェクト開始時から main を既定にしたいケース。
# その場で指定
git init -b main # = --initial-branch=main
# 以後常に main で始めたい（推奨）
git config --global init.defaultBranch main
ベアリポジトリを作成して共有リポジトリとして使う
作業ツリーなしの“受け皿”リポジトリ（サーバー側）を用意 → ローカルから push。
# サーバー側（共有用）
mkdir -p /srv/git
git init --bare --shared=group /srv/git/myrepo.git
# クライアント側（作業用）
mkdir myrepo && cd myrepo
git init -b main
git commit --allow-empty -m "initial"
git remote add origin ssh://user@server/srv/git/myrepo.git
git push -u origin main
- ポイント：
--shared=groupで共同運用しやすい権限に。実際のアクセスは OS のユーザー/グループ設定も必要。
既存ディレクトリで git init（誤って初期化した場合）
間違って関係ない場所（例：ホーム直下）で git init してしまったら…
取り消し（最も簡単）
# 初期化直後など、履歴が不要なら .git を消す
rm -rf .git
既に履歴が付いている/消すのが怖い場合
# まず場所を特定
git rev-parse --show-toplevel # どのディレクトリがリポジトリの最上位か
# バックアップしてから .git を移動 or 削除
mv .git ../git-backup-$(date +%Y%m%d-%H%M%S)
既存リポジトリ内で再度 git init を実行したとき
- ふつうは致命的な問題は起きません（設定の再生成など）が、不要なら実行しないのが吉。
サブモジュールとの関係：git submodule update --init --recursive との使い分け
git init は「このディレクトリをリポジトリ化」するコマンド。
一方サブモジュールは、親リポジトリに紐づく子リポジトリを取得・初期化します。
よくあるフロー
# 既存の親リポジトリを取得
git clone https://example.com/parent.git
cd parent
# 親に定義されたサブモジュールを初期化して取得
git submodule update --init # 1階層だけ
git submodule update --init --recursive # ネストも含めてすべて
使い分けの目安
- 新規プロジェクト開始／手元フォルダを履歴化 →
git init - 親リポジトリに定義済みのサブモジュールをセットアップ →
git submodule update --init [--recursive] - サブモジュールを新規追加 → 親側で
git submodule add https://example.com/lib.git external/lib git commit -m "add submodule lib"
ヒント：サブモジュールは別リポジトリなので、サブモジュール内で作業する時はその中に入ってから通常どおり
git add/commit/pushを行います。
よくある間違い・トラブル対応
git init を誤って実行してしまったときの対処（取り消し／バックアップ）
「場所を間違えて初期化した」「ホーム直下でやってしまった」などのときは、.git を消せば取り消せます。消す前に場所と状態を確認しましょう。
場所の確認
git rev-parse --show-toplevel # そのリポジトリの最上位ディレクトリ
git rev-parse --git-dir # .git の実体パス
最も簡単な取り消し（初期化直後・履歴不要なら）
rm -rf .git # Windows: rmdir /S /Q .git
バックアップしてから取り消す（安全策）
tar czf ../git-backup-$(date +%Y%m%d-%H%M%S).tar.gz .git
rm -rf .git
注意：
.gitを削除すると “そのディレクトリ内の Git 履歴と設定” は失われます。消す前に必要な内容がないか確認を。
存在しないパスを指定したときのエラーと対処
git init <dir> は 最終ディレクトリが無ければ作成 しますが、親ディレクトリが存在しない と失敗します。
例：親パスが無い
git init /path/not/exist/myrepo
# fatal: cannot mkdir '/path/not/exist/myrepo': No such file or directory
対処
mkdir -p /path/not/exist
git init /path/not/exist/myrepo # 成功
既に Git リポジトリが存在するディレクトリで再実行したときの挙動
既に .git/ がある場所で git init を実行すると、再初期化（Reinitialized） されます。
通常は履歴や設定は保持され、致命的な影響はありません。
git init
# Reinitialized existing Git repository in /path/to/repo/.git/
- 不要に繰り返す意味はあまりありません。設定の見直しなら
.git/configを編集するかgit configを使う方が安全です。 .gitの場所を分離・変更したい用途は--separate-git-dirを検討。
リモートリポジトリを後から紐付ける方法
git init で始めたローカルリポジトリに、のちほどリモート（例：GitHub/GitLab）を設定する手順です。
1) リモートを登録
git remote add origin git@github.com:USER/REPO.git
# すでに origin がある場合は
# git remote set-url origin git@github.com:USER/REPO.git
2) 初回の push（ブランチ追跡を設定）
# 例：main ブランチを使っている場合
git push -u origin main
# 以後は git push / git pull だけで OK（追跡設定済み）
3) 既定の初期ブランチを揃える
# 新規プロジェクトを常に main で始めたい（グローバル設定）
git config --global init.defaultBranch main
補足：ベア（受け皿）側に後から接続する場合
# サーバー側（受け皿）
git init --bare --shared=group /srv/git/myrepo.git
# ローカル作業側
git remote add origin ssh://user@server/srv/git/myrepo.git
git push -u origin main
ヒント：既存の “clone 前提” のワークフローに合わせたい場合は、
git cloneを使う方が初期設定（origin登録・初回チェックアウト）まで自動で整います。
内部処理と注意点（少し深掘り）
.git/ ディレクトリの構造（ざっくり把握）
git init が作る .git/ は、履歴・設定・参照の“心臓部”です。代表的な中身は次のとおり。
objects/：コミット・ツリー・ブロブ・タグ等のオブジェクト本体pack/（多数のオブジェクトをまとめた packfile）
refs/：ブランチやタグの参照名 → オブジェクトID の対応refs/heads/<branch>、refs/tags/<tag>、refs/remotes/<remote>/<branch>
HEAD：現在の作業先を指すシンボリック参照（通常ref: refs/heads/mainなど）config：リポジトリ単位の設定（後述の優先順位参照）index：ステージング領域（git addの結果がここに反映）hooks/：フックスクリプト（pre-commitなど）を置く場所info/：info/excludeでそのリポジトリ限定の除外が書けるpacked-refs：refs が多い場合にまとめて格納されるファイル
位置関係（超要約）：作業ツリー（あなたのファイル群） ←→ index（ステージ） ←→ objects（永続化された履歴）
参照（refs/*とHEAD）は「どの履歴を指しているか」を記録します。
デフォルトブランチ（master vs main）の扱いと変更
新規リポジトリの初期ブランチ名は、環境や設定で決まります。最近は main を採用するチームが多く、以下のいずれかでコントロールできます。
A. その場だけ指定
git init -b main # = --initial-branch=main
B. 以後ずっと main で始める（推奨）
git config --global init.defaultBranch main
既存リポジトリを master → main に変えたい（ローカル）
git branch -m master main # ブランス名のリネーム
リモート併用時は、リモートのデフォルトブランチ切り替え・追跡設定の更新・古いブランチ削除（必要なら）などを合わせて行います。
git push -u origin main # 新ブランチを既定として追跡
# プラットフォーム側（GitHub/GitLab等）で default branch を main に変更
# その後、不要ならリモート master を削除
git push origin :master
設定の優先順位と init.defaultBranch の影響
git 設定は概ね システム → グローバル（ユーザー） → ローカル（リポジトリ） の順に上書きされます。
- システム：
/etc/gitconfig（環境全体） - グローバル：
~/.gitconfig（そのユーザー全体） - ローカル：
.git/config（そのリポジトリだけ）
git init の初期ブランチ名は、init.defaultBranch に従います。未設定ならツールやディストリの既定に依存します。
確認と設定例：
git config --show-origin --get init.defaultBranch
git config --global init.defaultBranch main
権限・ファイルシステム依存性（パーミッション／シンボリックリンク など）
複数人・複数OSで運用する際にハマりやすいポイントをまとめます。
1) 共有権限（サーバー側運用）
- 共有サーバーでベアリポジトリを置くなら、初期化時に
--sharedを検討。git init --bare --shared=group /srv/git/repo.git - 実際の可否は OS のユーザー／グループ設定、親ディレクトリのグループ/SGID ビット、
umaskにも依存します。 - 既存リポジトリの既定権限は
core.sharedRepositoryで確認・変更可能。
2) 実行ビット・パーミッションの扱い
- Git は通常、実行ビットの違い（
+x）を追跡します。ネットワークドライブや OS により挙動がぶれる場合、core.filemodeを調整。git config core.filemode false # 実行ビットの変化を無視（環境依存時の逃げ）
3) 改行コード（EOL）と文字コード
- Windows と Linux/Mac を跨ぐ場合は
core.autocrlfや.gitattributesによるtext eol=lf指定で揺れを抑制。
例：プロジェクトの.gitattributes* text=auto eol=lf
4) シンボリックリンク
- Windows 環境ではシンボリックリンクの作成に管理者権限や開発者モードが要る場合がある。Git の
core.symlinks（既定は true）でリンク扱いを調整可能。
5) .git の分離・外部配置
.git実体を別パスに置きたい場合は--separate-git-dir。バックアップ方針や大規模モノレポで有効。git init --separate-git-dir=/var/lib/git/meta my-worktree
まとめ：
- 共有なら
--sharedと OS 側権限の整備をセットで。- クロスプラットフォームなら EOL と filemode、symlink の方針を最初に決める。
- 初期ブランチは
init.defaultBranchを整えて全員の体験を統一。.gitの中身を理解しておくと、トラブル時の切り分けが速くなります。
コマンド比較・関連操作
git clone との違い
git init：空のディレクトリを Git 管理にする。履歴は空っぽで、そこからファイルを追加していく。git clone：既存リポジトリをコピーして新しいディレクトリに展開。履歴・ブランチ・リモート設定（origin）まで自動で揃う。
目的別には以下の違いになります
- ゼロから始めたい →
git init - 他人やリモートのリポジトリを利用したい →
git clone
git config による初期設定
git init のあと、そのリポジトリ固有の設定は .git/config に記録されます。ユーザー名やメールアドレスが未設定だとコミット時にエラーになるため、事前に git config で設定しておきましょう。
# グローバル（全リポジトリ共通）
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
# ローカル（そのリポジトリ限定）
git config user.name "Project Specific"
git config user.email "proj@example.com"
設定ファイルの優先順位：
システム（/etc/gitconfig） < グローバル（~/.gitconfig） < ローカル（.git/config）
git status / git add / git commit の流れ
git init 後に続けて行う基本操作は以下のとおり。
git status # 現在の状態確認（初期化直後はコミットなし）
echo "# MyProject" > README.md
git add README.md # 変更をステージ（index に追加）
git commit -m "first commit" # 履歴として保存
git status：変更やステージ状態を確認git add：変更をステージングエリアに登録git commit：ステージの内容を履歴に保存
この「status → add → commit」が、git init 直後の最初の一歩になります。
git submodule init / git submodule update など
サブモジュールは 親リポジトリの中で別リポジトリを管理する仕組み。git init 自体とは用途が違いますが、初期化フローの一部でよく混同されます。
git submodule init：親に登録済みのサブモジュールを「有効化」する（URL 情報を .git/config に書き込む）git submodule update：そのサブモジュールのリポジトリを実際に取得し、親で指定されたコミットに checkout する
よく使う組み合わせ：
# サブモジュールをすべて初期化して取得
git submodule update --init --recursive
違いの整理
git init：ディレクトリを新規リポジトリ化git submodule init：サブモジュールの設定だけを準備git submodule update：中身を実際に取得
実務の感覚：
- ゼロから始めるとき →
git init- 既存プロジェクトを clone したとき →
git submodule update --initを忘れずに
FAQ（よくある質問）
Q1. git init とは何ですか？
git init は、指定したディレクトリを Git リポジトリに初期化するコマンドです。
実行すると .git/ ディレクトリが作られ、以後そのフォルダ内の変更をバージョン管理できるようになります。
新規プロジェクトを始めるときや、既存のソースコードを履歴管理下に置きたいときに最初に使います。
Q2. git init の初期化を取り消すには？
初期化直後であれば、.git/ ディレクトリを削除すれば取り消せます。
rm -rf .git # Windows: rmdir /S /Q .git
既に履歴がある場合や消すのが不安な場合は、.git/ をリネームやバックアップしてから削除するのがおすすめです。
mv .git ../git-backup-$(date +%Y%m%d-%H%M%S)
Q3. git init した後にリモートリポジトリを設定するには？
リモート URL を追加して、最初の push を行います。
git remote add origin git@github.com:USER/REPO.git
git push -u origin main
originがリモートのデフォルト名-uで追跡設定を行うため、以後git push/git pullだけで同期可能
Q4. bare リポジトリと通常リポジトリの違いは？
- 通常リポジトリ（デフォルト）
- 作業ツリーあり
- ファイルを編集して
add/commitできる - 個人作業やローカル開発向け
- ベアリポジトリ（–bare）
- 作業ツリーなし
- 履歴だけを保持（中で編集はできない）
- 共有サーバーや中央リポジトリとして利用する
例：GitHub や GitLab 上のリポジトリはベアリポジトリの一種です。
Q5. サブモジュールと git init はどう連携するの？
git init：新しいリポジトリを作成するコマンドgit submodule init：親リポジトリに登録済みのサブモジュール設定を有効化git submodule update --init --recursive：サブモジュールの中身を取得して、親で指定された状態に揃える
つまり サブモジュールを使うときは git init 自体ではなく、submodule 系コマンドを追加で実行します。
親リポジトリを clone した後に submodule update --init を忘れると、サブモジュールが空ディレクトリのままになる点に注意してください。
まとめ・実践チェックリスト
git init を調べているということは、これから自分の手元でコードやファイルを「履歴管理していきたい」という段階にいるはずです。
まず大切なのは、Git は単なるコマンド集ではなく「変更を記録して再現する仕組み」だという理解です。git init はその入り口であり、「ここからはこのディレクトリの中身を全部記録していくよ」という宣言にあたります。
心構えとして覚えておきたいのは、次の2点です。
- 履歴を残すこと自体が資産になる
→ 後から「どの時点で」「誰が」「なぜ」変更したのかを追えるのは、チーム開発でも個人学習でも大きな力になります。 - 小さく区切ってコミットする習慣をつける
→ 最初は「動いたから一回コミット」「README を追加したからコミット」で十分。細かく積み上げることで後で見返す価値が高まります。
次に学ぶべきステップは、以下の流れです。
git statusを習慣にする
→ いまの状態（変更があるか、ステージ済みか）を確認するクセをつけましょう。git addとgit commitのセットを身につける
→ 変更を選んで履歴に残す、という Git の基本操作です。- リモートリポジトリを設定して push/pull
→ GitHub や GitLab を使えば、バックアップや共有の仕組みが一気に広がります。 - ブランチを活用する
→ main とは別に試したいコードを書けるのが Git の大きな強み。
「git init を実行して終わり」ではなく、そこから バージョン管理の流れを実感することが次の学習テーマです。小さな練習でもよいので、自分のプロジェクトを一つ Git 管理に置いてみると理解が早まります。
👉 一歩進んだ学習へのおすすめ
- コミットログを整理する方法（
git log,git diff） - リモートリポジトリとの連携（
git remote add,git push） - 間違えたときのやり直し方（
git reset,git checkout,git restore） - Git全体の使い方 （Gitとは）
git init はスタートラインです。ここから「状態を確認する」「変更を記録する」「履歴を残す」という一連の流れを体験していけば、Git の理解は自然と深まっていきます。
参考リンク / 関連記事
外部リファレンス
- Git 公式ドキュメント（git-scm.com）
→ コマンドの完全な仕様、オプション一覧、最新の挙動が確認できます。 - Git 公式ドキュメント 日本語訳
→ 日本語で読める公式ドキュメント。翻訳の更新頻度は英語版に比べると遅めなので注意。 - Atlassian Git チュートリアル：git init
→ チーム開発に強い Atlassian による初心者向けの実践的解説。
コメント