はじめに
こんにちは、GMOコネクト野口です。
前回は、Gitのインストールと基本的な用語解説を行いました。
今回は予告通り、実際に手を動かしてGitを使っていきます。
「コミット」や「ブランチ」といった概念も、実際にコマンドを叩いて結果を見ることで理解が深まるはずです。
私自身、現場によってTortoiseGit・VS Code・GitLabを使ってきたため、最近コマンドプロンプトやGit Bashのみで管理する機会があったとき、コマンドをサクサク打つことができませんでした。
これはヤバイとGit入門を一通り読み、実際にコマンドを打ってファイル操作や管理をお試しで行うことで、改めて理解できたと感じました。これが今回Gitを記事にしようと決めた理由でもあります。
その経験に習い、今回はGitの基本であるローカル（自分のPC）での操作に集中して解説します。
※GitHubへのアップロード（プッシュ）などは次回解説します。
今回実施する内容
前回の記事で紹介した7つの用語のうち、以下の4つを実際に行います。
- リポジトリ (入れ物を作る)
- コミット (変更を記録する)
- ブランチ (作業場所を分ける)
- マージ (変更を統合する)
前提環境
- OS: Windows
- ツール: Git Bash
- フォルダ: Cドライブ直下（
C:\git_practiceを作成して使用） - デフォルトブランチ名は
mainとする - 前回の記事でGitの初期設定（user.name / user.email）は完了済みとする
① リポジトリを作る（git init）
まずは、Gitで管理するためのフォルダ（リポジトリ）を用意します。
今回は分かりやすく、Cドライブの直下に作業用フォルダを作成します。
1.Git Bashを起動してください。
2.以下のコマンドを入力して、Cドライブ直下に移動し、フォルダを作成します。
※Git Bashでは、Cドライブは /c と表現されます。
# Cドライブに移動
cd /c
# git_practice というフォルダを作成
mkdir git_practice
# 作成したフォルダに移動
cd git_practice
3.現在のフォルダをGitで管理できるようにします。
git init
実行結果：
Initialized empty Git repository in C:/git_practice/.git/
これで、このフォルダはただのフォルダではなく、Gitが監視する「リポジトリ」になりました。
この時点で、git_practiceフォルダ内に.gitという隠しフォルダが作成されます。
（Windowsのエクスプローラーで確認する場合は、「表示」→「隠しファイル」にチェックを入れると見えます）
※この.gitフォルダの中に、全てのコミット履歴やブランチ情報が保存されます。このフォルダを削除すると、Git管理が失われるため注意してください。
② 変更を記録する（git add / git commit）
次に、ファイルを作成して、その履歴を保存（コミット）します。
今回は開発現場でよく使われるMarkdown形式（.md）のファイルを作成します。
1. ファイルの作成
ファイルを作成します。
echo "# Git練習用プロジェクト" > index.md
※コマンドでファイル作成していますが、フォルダをエクスプローラーで開いて、メモ帳などで index.md を作成しても構いません。その際は文字コードをUTF-8で保存してください。
2. 状態の確認（git status）
このタイミングで、現在のGitの状態を確認するコマンドを使います。非常によく使うコマンドです。
git status
実行結果（例）：
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.md
nothing added to commit but untracked files present (use "git add" to track)
Untracked files（追跡されていないファイル）としてindex.mdが表示されます。
まだGitの管理対象になっていない状態です。
3. ステージング（git add）
ファイルを「コミットする準備状態（ステージングエリア）」に上げます。
前回の解説でいう「買い物かごに入れる」作業です。
git add index.md
もう一度状態を確認します。
git status
実行結果（例）：
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: index.md
Changes to be committed（コミット予定の変更）に移動しました。
これは「ステージングエリア（買い物かご）」に入った状態です。
補足
VS CodeなどのGUIやIDEでGitを使用する際は、変更を自動検知し、git addの準備が行われます。
これらのツールでのステージング（add相当）操作は、変更ファイル一覧のチェックボックスにチェックを入れることです。
そのため、コマンドラインで直接git addを打つ機会は少ないかもしれません。
4. コミット（git commit）
履歴として保存（購入確定）します。
git commit -m "最初のコミット：index.mdを追加"
git commit でステージングエリアの変更を履歴として確定します。
-m "メッセージ" オプションで、変更内容を説明するメッセージを追加します。メッセージがないと後で履歴を見返したときに何をしたか分からなくなるため、必ず付けましょう。
以下のコマンドにて履歴を確認できます。
git log
実行結果例：
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 (HEAD -> main)
Author: Your Name <you@example.com>
Date: Mon Jan 15 10:30:00 2024 +0900
最初のコミット：index.mdを追加
この情報から分かること：
- commit a1b2c3d...: コミットを識別するID（ハッシュ値）
- Author: 誰がコミットしたか
- Date: いつコミットしたか
- 最初のコミット...: コミットメッセージ
③ ファイルを変更してコミットする
1. ファイルを編集
index.mdを開いて、以下のように追記します。
追記後のindex.md：
# Git練習用プロジェクト
## 学習項目
- リポジトリの作成
- コミットの作成
※メモ帳などで編集する場合は、文字コードをUTF-8で保存してください。
2. 変更内容を確認
git status
実行結果例：
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.md
no changes added to commit (use "git add" and/or "git commit -a")
modified: index.mdと表示され、ファイルが変更されたことが分かります。
どこが変わったか詳しく見る：
git diff
実行結果例：
diff --git a/index.md b/index.md
index a1b2c3d..e4f5678 100644
--- a/index.md
+++ b/index.md
@@ -1 +1,4 @@
# Git練習用プロジェクト
+## 学習項目
+- リポジトリの作成
+- コミットの作成
+（プラス記号）が付いている行が追加された部分です。
3. 変更をコミット
git add index.md
git commit -m "学習項目セクションを追加"
4. 履歴を確認
# 1行で簡潔に表示するオプション
git log --oneline
実行結果例：
e4f5678 (HEAD -> main) 学習項目セクションを追加
a1b2c3d 最初のコミット：index.mdを追加
2つのコミットが記録されていることが確認できます。
④ 作業場所を分ける（git branch）
開発現場では、メインのファイルを直接いじるのではなく、「作業用のコピー（ブランチ）」を作って作業するのが基本です。
今回は2つのブランチ（feature-A, feature-B）を作り、それぞれのブランチがどう独立しているか確認します。
git checkoutについて
この記事では git checkout コマンドを使用していますが、Git 2.23以降では git switch（ブランチ切り替え）と git restore（ファイル復元）への移行が推奨されています。
ただし、現場ではまだ git checkout が広く使われているため、本記事ではこちらを採用しています。
参考：git checkout -b ブランチ名 は git switch -c ブランチ名 と同じ動作です。
1. ブランチAを作成して作業
まずは feature-A ブランチを作成し、index.md に追記を行います。
# feature-A を作成して切り替え
git checkout -b feature-A
# ファイルに追記する
echo "## 機能Aを追加しました" >> index.md
# コミットする
git add index.md
git commit -m "機能Aを追加"
2. 一旦メインに戻る
次に、もう一つのブランチを作るために、一旦土台である main ブランチに戻ります。
git checkout main
この時点で index.md の中身を確認してみてください。
cat index.md
さきほど feature-A で追記した内容は消えているはずです。
3. ブランチBを作成して作業
今度は feature-B ブランチを作成します。こちらでは index.md はいじらず、新しいファイルを作成してみます。
# feature-B を作成して切り替え
git checkout -b feature-B
# 新しい空ファイルを作成
echo "" > feature-B.md
# コミットする
git add feature-B.md
git commit -m "機能B用ファイルを追加"
※echo "" > feature-B.md について、Unix系の touch コマンドも使えますが、統一のため echo を使用しています。
4. ブランチごとのファイル状況を確認する
現在、ブランチが3つ存在しています。
コマンドで切り替えながら、ファイル一覧（ls）とファイルの中身（cat）がどう変わるか見てみましょう。
① feature-B
ls
# 結果: feature-B.md index.md (ファイルが2つある)
cat index.md
# 結果: 「機能A」の記述はない
② feature-A
git checkout feature-A
ls
# 結果: index.md (feature-B.md は存在しない！)
cat index.md
# 結果: 「機能Aを追加しました」という記述がある
③ main
git checkout main
ls
# 結果: index.md (feature-B.md はない)
cat index.md
# 結果: 「機能A」の記述もない（初期状態）
以下がブランチの本質です：
- ブランチを切り替えると、ファイルの内容もそのブランチの状態に切り替わる
- それぞれのブランチで独立して作業ができる
※次回以降のプルリクエストの解説で、ファイル編集の際にこのブランチを切り替えながら、視覚的に確認しますので、今はなんとなくで問題ありません。
⑤ 変更を統合する（git merge）
それぞれのブランチでの作業が終わったと仮定して、変更を main ブランチに統合します。
1. feature-A をマージ
現在は main ブランチにいるはずです（念のため git branch で確認してください）。
まずは feature-A の変更を取り込みます。
git merge feature-A
実行結果（例）：
Updating e4f5678..a2b3c4d
Fast-forward
index.md | 1 +
1 file changed, 1 insertion(+)
これで index.md に機能Aの内容が反映されました。
2. feature-B をマージ
続けて feature-B の変更も取り込みます。
git merge feature-B
実行結果（例）：
Merge made by the 'ort' strategy.
feature-B.md | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 feature-B.md
※エディタ等が自動で開いてコミットメッセージの入力を求められた場合は、そのまま閉じて保存してください（Vimが開いた場合は :wq と入力してEnter）。
3. 最終確認
これで全ての変更が main に集まりました。確認してみましょう。
ls
# 結果: index.md feature-B.md
cat index.md
# 結果: 機能Aの追記が含まれている
これが**「開発用ブランチで作業して、完成したらメインに統合する」**というGitの基本的な開発サイクルです。
おまけ：なぜ .txt ではなく .md (Markdown) なのか？
今回はサンプルファイルとして index.md を作成しました。
「ただのメモなら .txt（テキストファイル）でいいのでは？」と思った方もいるかもしれません。
しかし、開発現場ではドキュメントやメモを残す際、.txt ではなく Markdown形式（.md） を使うことが強く推奨されます。
理由は以下のメリットがあるからです。
-
見やすさが段違い
- GitHub、VS Code、多くのテキストエディタで、見出しや太字が綺麗に整形表示されます。
- BoxやGoogle Driveなどのクラウドストレージ上でも、プレビュー時に整形して表示されるため共有しやすいです。
-
文書構造が簡単に作れる
-
#や-などの簡単な記号だけで、見出し・箇条書き・強調・インデントなどを表現できます。 - README（説明書）や設計書もこの形式で書かれることが一般的です。
-
-
チーム開発に有利
- 書き方のルールが統一されているため、テンプレートを一つ置いておくだけで、初心者でもフォーマットに沿った綺麗なドキュメントが書けます。
-
QiitaもMarkdown
- 今読んでいただいているこの記事もMarkdownで書かれています。
システムが出力するログファイルなどは .txt が使われますが、人が読み書きするドキュメントについては、ぜひ Markdown（.md） を使う習慣をつけていきましょう。
まとめ
今回は、ローカル環境でGitの基本サイクルを実行しました。
次回以降は以下について解説予定です。
- Push / Fetch / Pull の動作解説（cloneについても触れます）
- GitHubとの連携設定（認証周りも解説します）
- Pull Request（プルリク）を使った「マージ依頼」の流れ
実際の現場では、今回のようにコマンドで git merge して統合することは稀で、GitHub上で「Pull Request」を使ってレビューを受けてからマージするのが一般的です。そのあたりを詳しく掘り下げます。
ここまで読んでいただき、ありがとうございます。
次回もよろしくお願いします。