Git入門 init add commit diffで履歴管理

Linuxエンジニア養成講座 第34回｜全36回・フェーズ4「サーバー構築と運用」の7回目（7/9回目）です。
前回: 第33回で CVE の読み方、fail2ban による攻撃緩和、aide によるファイル改ざん検知を実践しました。
今回学ぶこと: Git の基本操作（init / add / commit / diff / log / branch）を習得し、設定ファイルの変更履歴を管理する方法を実践します。

前回の予告で「git init / add / commit / diff / log / branch の基本操作を学び、/etc 配下の設定ファイルを Git で管理する実践を行います。aide が『ファイルの変化を検知する』ツールだとすれば、Git は『ファイルの変更履歴を記録し、いつでも過去の状態に戻せる』ツールです」とお伝えしました。aide は「何かが変わった」ことを検知するツールでしたが、Git は「いつ・誰が・何を・なぜ変更したか」を記録し、過去の状態に戻すことまでできるツールです。

この記事を読み終えると、以下のことができるようになります。

• バージョン管理がなぜ必要かを説明できる
• git init / add / commit / diff / log の一連の操作ができる
• branch の概念を理解し、作成・切り替えができる
• 設定ファイルの変更履歴を Git で管理し、障害時に「何が変わったか」を確認できる

なぜバージョン管理が必要か

あなたが sshd_config を変更した後に SSH 接続できなくなったとします。変更前の状態に戻す方法はあるか、考えてみてください。

まず思いつくのは「変更前に cp でバックアップを取っておく」方法です。

$ sudo cp sshd_config sshd_config.bak
$ sudo cp sshd_config sshd_config.bak2
$ sudo cp sshd_config sshd_config.20260401

この方法には問題があります。ファイルが増えるにつれて「どのバックアップが最新か」「どのバックアップで何を変更したか」「誰がいつ変更したか」がわからなくなります。半年後に .bak と .bak2 の違いを説明できる人はいません。

ここで考えてみてください。もしあなたが10台のサーバーを管理していて、ある日障害が起きたとします。「昨日誰かが設定を変えたらしい」という情報だけで、原因を特定できるでしょうか。どのサーバーの、どのファイルの、どの行を、誰が、なぜ変えたのか。.bak ファイルからこれらを読み取ることはできません。

この問題を解決するのがバージョン管理システム（VCS: Version Control System）です。Git はその中で最も広く使われているツールです。Git は変更のたびに「いつ・誰が・何を・なぜ変更したか」を記録します。記録された履歴は一覧で確認でき、任意の時点の状態に戻すこともできます。

Git の設計思想の核は、変更の「理由」を記録することにあります。.bak ファイルにはファイルの中身しか残りませんが、Git のコミットメッセージには「なぜこの変更をしたか」を書き残せます。これは単なる便利機能ではなく、チーム運用やセキュリティ監査で求められる「変更の追跡可能性（トレーサビリティ）」を実現するための仕組みです。障害が起きたとき、セキュリティ監査で問われたとき、「いつ・誰が・なぜ変えたか」に即答できることが、サービスを利用する顧客と事業を守ることにつながります。

インフラの現場では /etc 配下の設定ファイルを Git で管理することがあります。障害が発生したときに git log で「直前に何が変わったか」を即座に確認できるため、原因特定までの時間を大幅に短縮でき、その間のサービス停止による影響を最小化できます。

Git をインストールする

Git は AppStream リポジトリからインストールできます。

alma-mainで実行

実行コマンド:

$ sudo dnf install -y git

インストール後、バージョンを確認します。

実行コマンド:

$ git --version

実行結果:

git version 2.47.3

初回設定（user.name / user.email）

Git を使い始める前に、ユーザー名とメールアドレスを設定する必要があります。Git はコミット（変更の記録）のたびに「誰がこの変更をしたか」を記録するため、この情報がないとコミットできません。

実行コマンド:

$ git config --global user.name "developer"
$ git config --global user.email "developer@alma-main"

--global を付けると、そのユーザーの全リポジトリに適用されます。設定値は ~/.gitconfig に保存されます。確認してみます。

実行コマンド:

$ git config --global --list

実行結果:

user.name=developer
user.email=developer@alma-main

基本操作を体験する

実際に Git の操作を一つずつ体験していきます。練習用のディレクトリを作成するところから始めます。

リポジトリを作成する（git init）

Git で変更を記録するには、まず「リポジトリ」を作成する必要があります。リポジトリとは、Git が変更履歴を保存する場所のことです。git init コマンドでディレクトリを Git リポジトリに変換します。

実行コマンド:

$ mkdir -p /tmp/git-practice && cd /tmp/git-practice
$ git init

実行結果:

Initialized empty Git repository in /tmp/git-practice/.git/

初回の git init では、デフォルトブランチ名に関する hint メッセージが表示されることがあります。これは Git のデフォルトブランチ名が master であることを知らせるメッセージです。今回の演習では master のまま進めるため、このメッセージは無視して構いません。

現在の状態を確認してみます。

実行コマンド:

$ git status

実行結果:

On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

まだ何もファイルがなく、コミットもない空の状態です。Git は「git add でファイルを追跡してください」と教えてくれています。

ファイルを記録する（add → commit）

ファイルを作成して、Git に記録してみます。

実行コマンド:

$ echo "Hello Git" > README.txt

ファイルを作成した後の状態を確認します。

実行コマンド:

$ git status

実行結果:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.txt

nothing added to commit but untracked files present (use "git add" to track)

README.txt が「Untracked files」（追跡されていないファイル）として表示されています。Git はファイルの存在を認識していますが、まだ記録の対象にはしていません。ここで登場するのが git add です。

なぜ git add が必要なのか。 Git には「ステージングエリア」という仕組みがあります。これは、変更したファイルのうち「次のコミットに含めるもの」を選ぶための一時的な置き場です。たとえば 5 つのファイルを変更したが、そのうち 2 つだけをコミットしたいという場合に、git add でその 2 つを選んでステージングエリアに載せます。ステージングエリアに載ったファイルだけが、次の git commit で記録されます。

実行コマンド:

$ git add README.txt

実行コマンド:

$ git commit -m "最初のコミット"

実行結果:

[master (root-commit) 26be508] 最初のコミット
 1 file changed, 1 insertion(+)
 create mode 100644 README.txt

ハッシュ値（26be508 の部分）は環境によって異なります。これは各コミットを一意に識別するための値で、同じ値になる必要はありません。

-m オプションでコミットメッセージを指定しています。コミットメッセージは「何をしたか」だけでなく「なぜその変更をしたか」を書くことが重要です。たとえば「sshd_config を変更」ではなく「パスワード認証を無効化してブルートフォース攻撃を防止」と書くと、後から見返したときに変更の意図が伝わります。

履歴を確認する（git log）

コミットした履歴を確認します。

実行コマンド:

$ git log --oneline

実行結果:

26be508 最初のコミット

--oneline は各コミットを 1 行で表示するオプションです。ハッシュ値の短縮版とコミットメッセージが表示されます。履歴が少ないうちは git log（オプションなし）でも構いませんが、コミットが増えてくると --oneline が便利です。

現在の状態も確認します。

実行コマンド:

$ git status

実行結果:

On branch master
nothing to commit, working tree clean

「nothing to commit, working tree clean」は「すべての変更が記録済みで、未記録の変更はない」という意味です。

変更を確認して記録する（diff → add → commit）

次に、ファイルを変更してから記録するまでの流れを体験します。

実行コマンド:

$ echo "Second line" >> README.txt

変更後の状態を確認します。

実行コマンド:

$ git status

実行結果:

On branch master
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:   README.txt

no changes added to commit (use "git add" and/or "git commit -a")

README.txt が「modified」（変更あり）と表示されていますが、まだステージングエリアには載っていません。コミットする前に、何が変わったかを確認しましょう。

実行コマンド:

$ git diff

実行結果:

diff --git a/README.txt b/README.txt
--- a/README.txt
+++ b/README.txt
@@ -1 +1,2 @@
 Hello Git
+Second line

git diff は、前回のコミットからの変更点を表示します。+ が付いている行が追加された行です（削除された行には - が付きます）。設定ファイルを変更した後に git diff で差分を確認してからコミットする、という流れは現場でも基本的な操作です。

変更を記録します。

実行コマンド:

$ git add README.txt
$ git commit -m "2行目を追加"

実行結果:

[master 0f29697] 2行目を追加
 1 file changed, 1 insertion(+)

履歴を確認すると、2 つのコミットが記録されています。

実行コマンド:

$ git log --oneline

実行結果:

0f29697 2行目を追加
26be508 最初のコミット

新しいコミットが上に表示されます。ここまでの操作が Git の基本サイクルです。変更 → status で確認 → diff で差分確認 → add → commit。この流れを体に覚えさせてください。

Git のサブコマンドにはそれぞれマニュアルが用意されています。man git-commit や man git-diff でオプションの詳細を確認できます。git help commit でも同じ内容が表示されます。すべてのオプションを覚える必要はなく、必要になったときに調べられることが重要です。

branch で分岐する

Git には「ブランチ」という仕組みがあります。ブランチとは、履歴の流れを分岐させる機能です。「本番の設定に影響を与えずに変更を試したい」という場面で使います。

現在は master ブランチにいます。ここから feature という名前のブランチを作成して切り替えてみます。

実行コマンド:

$ git branch feature

実行コマンド:

$ git branch

実行結果:

  feature
* master

* が付いているのが現在のブランチです。feature ブランチに切り替えます。

実行コマンド:

$ git checkout feature

実行結果:

Switched to branch 'feature'

feature ブランチで変更を加えてコミットします。

実行コマンド:

$ echo "Feature work" >> README.txt
$ git add README.txt
$ git commit -m "feature ブランチで変更"

実行コマンド:

$ git log --oneline

実行結果:

7fb3446 feature ブランチで変更
0f29697 2行目を追加
26be508 最初のコミット

feature ブランチには 3 つのコミットがあります。ここで master ブランチに戻ってみます。

実行コマンド:

$ git checkout master

実行結果:

Switched to branch 'master'

実行コマンド:

$ git log --oneline

実行結果:

0f29697 2行目を追加
26be508 最初のコミット

master ブランチの履歴は 2 つのままです。feature ブランチでの変更は master には反映されていません。ファイルの中身も確認してみます。

実行コマンド:

$ cat README.txt

実行結果:

Hello Git
Second line

feature ブランチで追加した「Feature work」は表示されません。このように、ブランチを使えば本番の設定を一切変更せずに試行錯誤ができます。

ブランチでの変更を master に取り込む操作を「マージ」と呼びます（git merge コマンド）。概念として「ブランチで分岐した変更を合流させる操作」と覚えておいてください。

マージとコンフリクト

マージは多くの場合、Git が自動で処理してくれます。しかし、1つだけ Git が自動で処理できないケースがあります。それは master と feature の両方で同じファイルの同じ行を別々に変更した場合 です。

たとえば、sshd_config の PermitRootLogin が元々 yes だったとします。master ブランチで prohibit-password に変更し、feature ブランチでは no に変更した場合、同じ行を別々の値に変えているため Git はどちらが正しいか判断できません。マージを途中で止めて人間に判断を委ねます。この状態を「コンフリクト（衝突）」と呼びます。

コンフリクトが発生すると、Git は該当ファイルに以下のようなマーカーを挿入します。

<<<<<<< HEAD
PermitRootLogin prohibit-password
=======
PermitRootLogin no
>>>>>>> feature

<<<<<<< HEAD から ======= までが master 側の内容、======= から >>>>>>> feature までが feature 側の内容です。正しい方を残してマーカーを削除し、git add → git commit すれば解決です。

コンフリクトは怖いものではありません。Git が「ここが衝突した」と正確に教えてくれるので、人間は正しい方を選ぶだけです。初めて遭遇するとパニックになりがちですが、「Git が助けてくれている」と思い出してください。ブランチは第35回 Ansible でも登場します。

/etc 配下の設定ファイルを Git で管理する

ここからは実践的な使い方として、設定ファイルを Git で管理する方法を体験します。

なぜ /etc を Git 管理するか

障害が発生したとき、最初に確認すべきことの一つが「直前に何か変更したか」です。第15回の初動コマンド集でも触れましたが、障害の原因は直前の変更であることが多いです。

設定ファイルを Git で管理していれば、git log で「最後の変更がいつ、何だったか」を確認し、git diff で具体的な変更内容を見ることができます。aide がファイルの「変化」を検知するのに対し、Git は「何が、どう変わり、なぜ変えたのか」まで記録します。

テスト用ディレクトリで実践する

実際の /etc は root 権限が必要なファイルが多く、演習で直接操作すると意図しない変更のリスクがあります。今回は /tmp/etc-git-practice にファイルをコピーして練習します。

alma-mainで実行

第20回で設定した firewalld.conf をコピーして使います。

実行コマンド:

$ mkdir -p /tmp/etc-git-practice
$ sudo cp /etc/firewalld/firewalld.conf /tmp/etc-git-practice/
$ sudo chown developer:developer /tmp/etc-git-practice/*

sudo cp でコピーしたファイルは root 所有になるため、chown で developer ユーザーに所有権を変更しています。これにより、以降の Git 操作を sudo なしで実行できます。

Git リポジトリを初期化して、初期状態をコミットします。

実行コマンド:

$ cd /tmp/etc-git-practice
$ git init
$ git add -A
$ git commit -m "設定ファイルの初期状態を記録"

実行結果:

Initialized empty Git repository in /tmp/etc-git-practice/.git/
[master (root-commit) 551b52f] 設定ファイルの初期状態を記録
 1 file changed, 103 insertions(+)
 create mode 100644 firewalld.conf

git add -A はディレクトリ内のすべてのファイルをステージングエリアに追加します。初期状態の記録では全ファイルを対象にするため -A を使っています。

履歴を確認します。

実行コマンド:

$ git log --oneline

実行結果:

551b52f 設定ファイルの初期状態を記録

次に、設定ファイルに変更を加えて、差分を確認してからコミットする流れを体験します。

実行コマンド:

$ echo "# Test change" >> firewalld.conf

実行コマンド:

$ git diff

実行結果:

diff --git a/firewalld.conf b/firewalld.conf
--- a/firewalld.conf
+++ b/firewalld.conf
@@ -101,3 +101,4 @@ RFC3964_IPv4=yes
 # rules, then you will have to set this to "no".
 # Defaults to "yes".
 NftablesTableOwner=yes
+# Test change

+# Test change が追加された行です。変更内容を確認したら、コミットします。

実行コマンド:

$ git add firewalld.conf
$ git commit -m "firewalld.conf にテスト変更を追加"

実行結果:

[master c8a31f6] firewalld.conf にテスト変更を追加
 1 file changed, 1 insertion(+)

実行コマンド:

$ git log --oneline

実行結果:

c8a31f6 firewalld.conf にテスト変更を追加
551b52f 設定ファイルの初期状態を記録

障害が発生したとき、この git log を見れば「直前の変更は firewalld.conf へのテスト変更だった」と即座にわかります。さらに git diff 551b52f c8a31f6 のようにハッシュ値を指定すれば、2 つのコミット間の差分を確認することもできます。

etckeeper の紹介

今回は手動で /etc の設定ファイルを Git 管理しましたが、実際の運用では「etckeeper」というツールを使うことがあります。etckeeper は /etc 配下を自動的に Git で管理し、dnf でパッケージを導入・更新した際にも自動でコミットを行います。手動のコミット忘れを防げるため、本番サーバーの設定管理に便利です。

間違えたときに戻す — Git を使う本質的な理由

冒頭で「設定を壊したとき、元に戻す方法はあるか」と問いかけました。Git はそのためのツールです。ここでは、間違えたときに過去の状態に戻す方法を体験します。

ファイルを間違えて変更・削除してしまった場合

コミット済みのファイルを間違えて削除してしまった場合、git checkout で直前のコミットの状態に戻せます。

alma-mainで実行（/tmp/git-practice ディレクトリで）:

実行コマンド:

$ rm README.txt
$ ls README.txt

実行結果:

ls: 'README.txt' にアクセスできません: そのようなファイルやディレクトリはありません

ファイルが消えました。しかし Git で管理しているので、復元できます。

実行コマンド:

$ git checkout -- README.txt
$ cat README.txt

実行結果:

Hello Git
Second line

直前のコミットの状態に復元されました。git checkout -- ファイル名 は「作業ディレクトリの変更を取り消す」コマンドです。

過去のコミットを取り消したい場合

2週間前にコミットした変更が原因で問題が起きていると判明した場合、git revert でそのコミットを打ち消す新しいコミットを作れます。履歴を書き換えるのではなく「取り消しの記録」を残す方法なので、チームでの運用でも安全です。

実行コマンド:

$ git log --oneline

実行結果:

0f29697 2行目を追加
26be508 最初のコミット

「2行目を追加」のコミットを取り消したい場合:

実行コマンド:

$ git revert 0f29697 --no-edit

実行結果:

[master xxxxxxx] Revert "2行目を追加"
 1 file changed, 1 deletion(-)

※ ハッシュ値は環境によって異なります。--no-edit はデフォルトのコミットメッセージをそのまま使うオプションです。

git log --oneline で確認すると、元のコミットは残ったまま「Revert」コミットが追加されています。cat README.txt で中身を見ると、2行目が消えて1行目だけに戻っています。

Git を使う本質的な理由はここにあります。間違えても戻せるから、安心して変更できる。バックアップファイルを手動で管理するのとは根本的に異なる安心感です。

実務での Git 運用パターン

基本操作を覚えたら、次は現場でどう使うかです。ここでは、インフラエンジニアの日常業務で役立つ Git の運用パターンを紹介します。以下のコマンドは新しいテスト用リポジトリで試します。

alma-mainで実行:

実行コマンド:

$ mkdir -p /tmp/git-ops && cd /tmp/git-ops
$ git init -q
$ git config user.name "developer"
$ git config user.email "developer@alma-main"
$ echo "PermitRootLogin yes" > sshd_config
$ echo "PasswordAuthentication yes" >> sshd_config
$ echo "MaxAuthTries 6" >> sshd_config
$ git add sshd_config
$ git commit -q -m "sshd_config 初期状態を記録"
$ sed -i "s/PermitRootLogin yes/PermitRootLogin no/" sshd_config
$ git add sshd_config
$ git commit -q -m "PermitRootLogin を no に変更（セキュリティ監査 #42 対応）"
$ sed -i "s/MaxAuthTries 6/MaxAuthTries 3/" sshd_config
$ git add sshd_config
$ git commit -q -m "MaxAuthTries を 3 に変更（ブルートフォース対策）"

3回のコミットで設定変更の履歴を作りました。この状態で以下の運用パターンを試します。

git blame — 「この行を変えたのは誰か」を特定する

障害が発生したとき、原因となった設定変更を特定する必要があります。git blame は、ファイルの各行が「いつ・誰のコミットで変更されたか」を表示します。

実行コマンド:

$ git blame sshd_config

実行結果:

c86a4777 (developer 2026-04-04 21:25:30 +0900 1) PermitRootLogin no
^9ff0d15 (developer 2026-04-04 21:25:30 +0900 2) PasswordAuthentication yes
b59a4271 (developer 2026-04-04 21:25:30 +0900 3) MaxAuthTries 3

各行の先頭にコミットハッシュ、変更者、日時が表示されます。「PermitRootLogin を変更したのはコミット c86a477 だ」とわかれば、git show c86a477 でそのコミットの詳細を確認できます。障害調査の起点として覚えておいてください。

git tag — メンテナンス前に「安全な状態」に印をつける

サーバーのメンテナンス作業の前に、現在の状態にタグ（名前付きの印）を打っておくと、作業が失敗したときにタグの状態に戻せます。

実行コマンド:

$ git tag before-maintenance
$ git log --oneline --decorate

実行結果:

b59a427 (HEAD -> master, tag: before-maintenance) MaxAuthTries を 3 に変更（ブルートフォース対策）
c86a477 PermitRootLogin を no に変更（セキュリティ監査 #42 対応）
9ff0d15 sshd_config 初期状態を記録

最新のコミットに before-maintenance というタグが付きました。作業後に問題が起きた場合、git checkout before-maintenance -- ファイル名 で特定のファイルをタグ時点の状態に戻せます。

git stash — 作業中に緊急対応が入ったとき

設定ファイルを編集中に緊急の障害対応が入ったとします。編集途中の変更をコミットしたくはないが、捨てたくもない。そんなときに git stash で一時退避できます。まず編集途中の状態を作ります。

実行コマンド:

$ echo "ClientAliveInterval 300" >> sshd_config

この未コミットの変更を一時退避します。

実行コマンド:

$ git stash

実行結果:

Saved working directory and index state WIP on master: b59a427 MaxAuthTries を 3 に変更（ブルートフォース対策）

編集中の変更が一時退避され、作業ディレクトリはクリーンな状態に戻ります。緊急対応が終わったら git stash pop で退避した変更を復元できます。

git log –since — 「直近で何が変わったか」を調べる

障害調査で「直近2週間の変更」を確認したいとき、--since オプションが使えます。

実行コマンド:

$ git log --oneline --since="2 weeks ago"

指定した期間内のコミットだけが表示されます。「障害が発生した時刻の前後で何が変わったか」を素早く特定できます。

コミットメッセージに「なぜ」とチケット番号を書く

コミットメッセージは未来の自分やチームメンバーへの伝言です。「何を変更したか」だけでなく「なぜ変更したか」と「関連するチケット番号」を書く習慣をつけてください。

悪い例: sshd_config 変更
良い例: PermitRootLogin を no に変更（セキュリティ監査 #42 対応）

良い例のコミットメッセージなら、半年後に git log を見たときに「なぜこの変更をしたか」がわかります。セキュリティ監査で「この設定はいつ、なぜ変更したか」と聞かれたときにも、コミット履歴がそのまま回答になります。

メンテナンス前後の commit — 作業記録としての Git

第2回で学んだ「作業記録」を Git で残す運用です。メンテナンス作業の前と後にコミットすると、差分が自動的に作業記録になります。

1. 作業前: git add -A && git commit -m "メンテナンス作業前の状態"
2. 設定変更を実施
3. 作業後: git add -A && git commit -m "httpd.conf のKeepAliveTimeout変更（チケット #105）"

作業前と作業後のコミットを git diff で比較すれば、「この作業で何が変わったか」が正確にわかります。手書きの作業報告書よりも正確で、改ざんもできません。

ヒヤリハット: 現場で起きる Git のトラブル

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.

*_key
*.key
*.pem
shadow
shadow-

やってみよう

以下の課題に取り組んでください。

課題: テストディレクトリで Git の基本サイクルを実践する

1. /tmp/git-exercise ディレクトリを作成し、git init でリポジトリを初期化する
2. 以下の 3 ファイルを作成する（中身は自由）
   • server.conf
   • network.conf
   • backup.conf
3. git add で 3 ファイルをステージングし、git commit -m "初期設定ファイルを作成" でコミットする
4. server.conf に 1 行追加する
5. git diff で変更内容を確認する
6. git add → git commit -m "server.conf にパラメータを追加" でコミットする
7. git log --oneline で 2 件の履歴が表示されることを確認する
8. git branch test-change でブランチを作成し、git checkout test-change で切り替える
9. network.conf に 1 行追加し、git add → git commit する
10. git checkout master で戻り、cat network.conf で追加した行が表示されないことを確認する

ポイントは、各ステップの間に git status を実行して「今 Git がどういう状態か」を確認する癖をつけることです。

演習が完了したら、rm -rf /tmp/git-exercise でクリーンアップしてください。先ほどの /tmp/git-practice と /tmp/etc-git-practice も不要であれば削除して構いません。

まとめと次回予告

今回は Git の基本操作を学びました。git init でリポジトリを作成し、add → commit で変更を記録し、diff で差分を確認し、log で履歴を辿る。この基本サイクルが Git 操作の核です。ブランチを使えば本番に影響を与えずに変更を試せること、設定ファイルを Git 管理すれば障害時に「何が変わったか」を即座に特定できることも体験しました。

Git は開発者だけのツールではありません。インフラエンジニアにとっても、設定ファイルの変更管理や障害時の原因特定に欠かせないツールです。今回学んだ init / add / commit / diff / log の 5 つの操作ができれば、現場で Git を使い始めるには十分です。

次回は第35回「自動化と構成管理（Ansible）」です。ansible-core を導入し、ad-hoc コマンドと簡単な playbook で alma-sub へのリモート操作を体験します。今回 Git で管理した設定ファイルを、複数サーバーに一括で配布する。その自動化の第一歩を踏み出します。

理解度チェック

今回の内容を○×形式で確認します。

問1: Git はファイルの変更を記録し、任意の時点の状態に戻すことができるバージョン管理システムである。

→ ○。Git は変更のたびに「いつ・誰が・何を・なぜ変更したか」を記録し、過去の任意の時点に戻すことができる。cp によるバックアップと異なり、変更の理由も履歴に残せる。

問2: git add を実行すると、ファイルの変更が即座にコミット（記録）される。

→ ×。git add はファイルを「ステージングエリア」に追加するだけで、コミットはされない。ステージングエリアに載せたファイルを git commit で記録する。この 2 段階の仕組みにより、変更したファイルのうちコミットに含めるものを選択できる。

問3: git diff は、前回のコミットからの変更点を表示するコマンドである。

→ ○。git diff はまだステージングされていない変更の差分を表示する。追加行には +、削除行には - が付く。設定変更後にコミットする前の確認に使う。

問4: Git のブランチ機能を使うと、本番の設定に影響を与えずに変更を試すことができる。

→ ○。ブランチで履歴の流れを分岐させ、別ブランチで変更を加えても元のブランチには影響しない。試した変更を取り込みたい場合はマージ（git merge）を行う。

問5: git config --global user.name と user.email を設定しなくても、コミットは実行できる。

→ ×。Git はコミットに「誰が変更したか」を必ず記録するため、user.name と user.email が未設定だとコミットを拒否する。新しいサーバーで Git を使い始めるときに忘れやすい設定。

問6: git add . を実行すると、秘密鍵などの機密ファイルも Git に追加される可能性がある。

→ ○。git add . はカレントディレクトリの全ファイルをステージングするため、秘密鍵やパスワードファイルも対象になる。.gitignore に除外パターンを書いておくことで、機密ファイルが誤って追加されるのを防げる。

シリーズ一覧

フェーズ1: エンジニアのいろは

• 第1回 エンジニアの仕事と学び方
• 第2回 作業記録と報連相
• 第3回 セキュリティ意識の基本

フェーズ2: Linux基礎

• 第4回 Linuxとは何か＋環境確認
• 第5回 SSH接続とターミナル操作
• 第6回 ファイルシステムとディレクトリ構造
• 第7回 基本コマンド（ファイル操作）
• 第8回 基本コマンド（テキスト処理・パイプとリダイレクト）
• 第9回 viエディタ
• 第10回 ユーザーとグループ管理
• 第11回 パーミッションと所有権
• 第12回 プロセス管理
• 第13回 systemd
• 第14回 シェルスクリプト入門
• 第15回 フェーズ2まとめ演習

フェーズ3: ネットワークとインフラ基盤

• 第16回 ネットワーク基礎
• 第17回 ネットワーク設定と疎通確認
• 第18回 企業ネットワークの仕組み
• 第19回 パッケージ管理
• 第20回 ファイアウォール（firewalld）
• 第21回 ボンディング/チーミング
• 第22回 VLAN
• 第23回 ログ管理
• 第24回 cron / systemd timer
• 第25回 ストレージ管理（LVM）
• 第26回 シェルスクリプト実践
• 第27回 SSH応用

フェーズ4: サーバー構築と運用

• 第28回 SELinux
• 第29回 Webサーバー構築（Apache/Nginx）
• 第30回 データベース基礎（MariaDB）
• 第31回 バックアップと復旧
• 第32回 監視入門
• 第33回 セキュリティ実践
• 第34回 Git基本操作
• 第35回 自動化と構成管理（Ansible）
• 第36回 トラブルシューティング（総合演習・最終回）