インストール後に Git で行う設定
— 初心者向けにここまでの流れをまとめて

2026年3月 公開

Git をインストールしたあと、「次に何をすればいいか」「ターミナルで何を打つか」が分からなかったので、実際にやった手順と、その過程で出た疑問（名前はどこで登録する？　git が認識されないときは？　コミットは Web に公開される？　など）を、初心者向けにまとめました。Git 入門・インストールの続きとして、インストール後から最初のコミットまでと、日々の使い方・よくある質問を書いています。

1. インストール後にやっておく設定

1.1 ユーザー名とメールアドレス（ターミナルで実行する）

「名前とメールはどこで登録するの？」→ ターミナル（Cursor の統合ターミナルや PowerShell）でコマンドを打ちます。 Git 用の「設定画面」はなく、すべてコマンドで設定します。

次の2つを、自分の名前とメールアドレスに置き換えて実行します。GitHub を使う場合は、GitHub に登録したメールと揃えるとよいです。

git config --global user.name "あなたの名前"
git config --global user.email "your.email@example.com"

実行後、何もメッセージが出なくて正常です。確認するときは git config --global user.name と git config --global user.email を実行し、設定した値が表示されれば OK です。

1.2 エディタを Cursor にする（インストール時に選べなかった場合）

インストール画面で「Use Visual Studio Code」を選ぶと Next が押せないことがあります。その場合は、インストール後にターミナルで次を実行します。

git config --global core.editor "cursor --wait"

git がまだ認識されないときは、後述の「git が認識されないとき」を先に読んでください。

1.3 「git が認識されません」と出るとき（PATH と Cursor の起動タイミング）

ターミナルで git と打つと「用語 'git' は、コマンドレット…として認識されません」と出ることがあります。これは、Git をインストールする前に Cursor を起動していたために、Cursor が「Git の入っていない PATH」を覚えたままになっているためです。

対処1： Cursor を一度終了してから、もう一度起動する。新しいターミナルでは PATH が更新され、git が使えることが多いです。

対処2： 同じターミナルで、いったん PATH に Git を追加してから実行する。

$env:Path += ";C:\Program Files\Git\cmd"
git --version

git version 2.53.0.windows.1 のように表示されれば、そのターミナルでは git が使えます。新しいターミナルを開いたときにまた git が見つからない場合は、上記の $env:Path += ... をその都度実行するか、PC を再起動（または Windows からログオフして再ログオン）すると、インストール時に追加された PATH が反映されます。

2. プロジェクトを Git で管理し始める

2.1 どこで git init するか（test フォルダはどうする？）

プロジェクトのルートフォルダ（例：make-001）で 1 回だけ git init します。中にある test フォルダは、別に指定せず、同じリポジトリに含めておくのがおすすめです。test 内のゲームが親フォルダの app.py を編集して動いている場合は、app.py と test を同じ履歴で管理したほうが、あとで「どの変更で不具合が出たか」を追いやすくなります。

cd C:\Users\あなたのユーザー名\OneDrive\デスクトップ\make-001
git init

Initialized empty Git repository in .../.git/ と出れば、そのフォルダが Git のリポジトリになりました。

コミットしたデータ（履歴）は、すべてそのフォルダの直下にある .git フォルダに保存されます。このプロジェクトなら C:\Users\wrina\OneDrive\デスクトップ\make-001\.git\ の中です。.git の中に、コミット内容やブランチなどの情報があり、ここを一緒にコピーすれば、別の場所でも同じ履歴をそのまま再現できます（逆に、中身を直接いじると履歴が壊れるので触らないのがおすすめです）。

2.2 .gitignore はどうする？　「不要なファイル」が分からない

「不要なファイルを除外する .gitignore を置く」とよく言われますが、このプロジェクトにはすでに .gitignore があります。 仮想環境（venv/）、.env（秘密情報）、__pycache__/ などはすでに除外されているので、新たに作る必要はありません。最初のコミットの前に「どれが不要か分からない」と困った場合は、既存の .gitignore のまま進めて問題ありません。

2.3 最初のコミットの手順（git add と git commit）

ターミナルで次を実行します。

git add .
git commit

git add . のあとに、「LF will be replaced by CRLF」などの warning がたくさん出ることがあります。これは Windows での改行の変換をお知らせしているだけで、エラーではありません。 そのまま git commit を実行して大丈夫です。

git commit を実行すると、Cursor で COMMIT_EDITMSG というファイルが開きます。 ここにコミットメッセージ（例：最初のコミット）を 1 行目に書きます。2 行目以降に説明が並んでいても、Git が使うのは基本的に 1 行目だけです。書いたら 保存（Ctrl+S）して、そのタブを閉じます。 タブを閉じると、Git が「編集完了」と判断してコミットが実行され、ターミナルに結果が表示されます。

「hint: Waiting for your editor to close the file...」と出ているあいだは、Git が Cursor で開いたファイルの編集完了を待っています。保存してタブを閉じればコミットが完了します。

3. よくある質問（初心者がつまずきやすいこと）

3.1 コミットの内容は Web に公開される？

いいえ。 git init と git commit は、すべてあなたの PC の中だけの操作です。GitHub などに git push で送るまで、履歴もコミットメッセージも Web には出ません。

3.2 Git のアプリを立ち上げる必要がある？

ありません。 Git は「アプリ」ではなく、コマンド（ツール）です。Cursor を立ち上げたら、その中でターミナルやソース管理から Git が使えます。 別に「Git 用のアプリ」を起動する必要はありません。

3.3 コミットするとプロジェクトの表示や動きに影響する？

しません。 コミットは「今の状態を履歴に記録するだけ」で、ファイルの内容やアプリの挙動は変えません。不具合の原因になるのは、あなたや AI が行った「編集」であり、コミットはその編集を記録しただけです。「このコミットの変更で不具合が出る」という言い方は、「そのコミットに含めた編集内容が原因で不具合が出ている」という意味で、コミットという操作そのものが悪いのではありません。

3.4 いつコミットすればいい？

「いまは表示も動きも正常だ」と思えたタイミングでコミットしておくのがおすすめです。正常な状態が履歴に残るので、あとで不具合が出たときに「この時点までは大丈夫だった」と比べやすくなります。大きな修正をする前と後（正常に動いたことを確認したあと）の 2 回でコミットしておくと、原因の切り分けがしやすくなります。

3.5 履歴を残し続けると容量はどれくらいになる？

「1 か月、漏れなくコミットするとどれくらいのデータになる？」という疑問に対しては、目安として数 MB ～ 20 MB 前後になることが多いです。Git は毎回ファイルの全コピーではなく「差分」を保存するため、コミット数が増えても急に巨大にはなりません。作業量（トークン使用量）が多めの月でも、数十 MB 程度の範囲に収まることが多いので、通常の PC の容量を気にせずコミットして問題ありません。

3.6 コミットを「消したい」のはどんなとき？

4. 日々の流れ（履歴を残す・原因を追う）

4.1 普段の流れ

• 大きな修正を始める前：「コミットして」と依頼する → git add . と git commit で作業前の状態を記録。
• 大きな修正が終わり、正常に動いたと確認したあと：「コミットして」と依頼する → 作業後の状態を記録。

会話の中で「コミットして」と言ってもらえれば、AI がターミナルでコマンドを実行し、必要ならコミットメッセージも提案できます。完全に自動でコミットする仕組みは、会話していないときには動かせませんが、「区切りのときに一言言う」だけで履歴は残せます。

4.2 エラー・不具合・表示崩れの原因を追いたいとき

1. いつ頃からおかしいかをおさえる（「昨日までは動いていた」「今日の〇〇の変更のあとから」など）。
2. ターミナルで git log --oneline -20 を実行し、直近のコミット一覧を見る。その中から「このコミットのあとからおかしくなった」というものを特定する。
3. 原因になりそうなコミットの ID が分かったら、git show コミットID で、そのコミットでどのファイルのどの行がどう変わったか（差分）を確認する。
4. 必要なら、そのファイルだけ昔の状態に戻して試す（git checkout コミットID -- ファイルパス）か、git revert コミットID でその変更を取り消すコミットを作る。

4.3 Cursor を 2 つ開いて同時進行するときの注意点

同じプロジェクトを「親フォルダで開いた Cursor」と「test フォルダなど別フォルダで開いた Cursor」の 2 つで同時に作業することがあります。そのときは次の点に気をつけると、競合や上書きを防げます。

• 同じファイルを同時に編集しない — 両方のウィンドウで app.py や同じテンプレートを開いたまま保存すると、あとで保存した方で先の変更が上書きされることがあります。編集するファイルがかぶらないようにするか、片方のウィンドウだけでそのファイルを触るようにします。
• コミットはどちらか一方に任せる — 両方からコミットすると、同じブランチに別々にコミットされて履歴が分かれたり、コンフリクトが起きたりしやすくなります。原則「コミットする人」を 1 人（例：親側で作業する人）に決めておくと安全です。
• コミットする前に他ウィンドウの変更を確認する — どうしても両方でコミットする場合は、git status で他ウィンドウで変更されたファイルがないか確認してから git add ・git commit するとよいです。
• どちらかが親側（app.py やテンプレート全体）を変えたらメモに残す — もう一方のウィンドウではその変更が見えていないので、「いつ・何を変えたか」を md などに短く書いておくと、あとで追いやすくなります。

5. まとめ

インストール後は、(1) ターミナルで user.name と user.email を設定し、(2) git が認識されないときは Cursor を開き直すか PATH を足し、(3) プロジェクトのフォルダで git init して (4) git add . と git commit で最初のコミットまで進めます。コミットは「記録するだけ」で Web には出ず、表示や動きにも影響しません。「正常だと思ったとき」に「コミットして」と依頼する習慣にしておくと、不具合の原因をあとから追いやすくなります。

← 立ち上げストーリー
← プログラム構築の記録
← デプロイの記録
← ボタン1つデプロイの記録
← デプロイでまたハマった話
← ログイン設定の記録
← 改善記録
← ファイル紹介の使い方
← OGP・SEOの記録
← 統合ログインの設計・経緯
← Search Console・サイトマップ
← 環境変数・.env の管理
← Git 入門・インストール
← カード神経衰弱の記録
← 異世界シューティングの記録
← 異世界シューティングの難易度
← 異世界戦記（全画面・迷路レイアウト）の記録
← 複数人でのゲーム進行
← 異世界衰弱（不具合の修正）
← 異世界衰弱（機能別フローチャート）
← 異世界ポイントの活用について
← 異世界ポイント市場の実装記録