Gitの基本コマンド入門｜インフラエンジニアが押さえるバージョン管理の実践

※本記事はプロモーションを含みます。

Gitはインフラエンジニア…

Gitは単なるプログラマー向けツールではなく、TerraformやAnsibleなどのインフラストラクチャ・アズ・コード（IaC）を扱うインフラエンジニアにとって、今や欠かせない日常業務のスキルです。本記事では、インフラエンジニアが実際の現場で活用するGitの基本コマンドから実践的なワークフローまで、体系的に解説します。読了までの目安時間は約8分です。

Gitの基本概念とインフラ…

バージョン管理の重要性

Gitはファイルの変更履歴を記録・管理するバージョン管理システムです。インフラエンジニアがサーバー設定やネットワーク構成をコードで管理する場合、以下のような場面でGitの価値が明確になります。

構成設定を変更した際に「いつ誰が何を変えたか」を追跡できる
本番環境の変更を実誤った時に、以前のバージョンに戻せる
複数のエンジニアが同じインフラコードを編集する場合の競合を防ぐ
変更理由をコミットメッセージで記録し、将来の参考にできる

これらの機能により、インフラストラクチャの運用品質が大幅に向上するとされています。

リポジトリ・コミット・ブラ…

Gitの基本的な用語を理解することが重要です。

概念	説明	インフラでの活用例
リポジトリ（repo）	ファイルの変更履歴を保存する場所。ローカルとリモート（GitHub等）の2種類	Terraform設定ファイルやAnsibleプレイブック全体を一元管理
コミット	変更内容のスナップショット。メッセージとともに変更を記録	「Nginxタイムアウト設定を30秒から60秒に変更」と記録
ブランチ	開発の分岐。mainブランチを汚さずに作業を進める	本番運用のmainから「feature/new-vpc-config」を切る
マージ	ブランチを統合し、変更をメインラインに取り込む操作	テスト完了したVPC設定をmainにマージ

インフラエンジニアが習得す…

従来、インフラの構成情報は各サーバーの設定ファイルに散在していました。しかし現在では、Terraformによるクラウドリソース管理やAnsibleによるサーバー設定自動化が標準化され、これらのコードはすべてテキストファイルです。つまり、インフラエンジニアも開発エンジニアと同じようにバージョン管理が必須となっています。

特に以下のような場面でGitの知識が活躍するとされています。

チームでインフラコードをレビューする際のプルリクエスト機能
本番環境の変更を記録し、トラブル時に「この変更が原因かもしれない」と原因追跡できる
ステージング環境で試した設定を本番環境に反映する際の安全な手順確保

インフラエンジニアが最初に…

リポジトリの初期化と複製

Gitを使う第一歩は、リポジトリを作成（初期化）するか、既存のリポジトリを自分のマシンに複製することです。

新規プロジェクトの場合：

git init

このコマンドで、カレントディレクトリが新しいGitリポジトリとして初期化されます。その後、ファイルを追加して管理を始めます。

既存プロジェクトの場合：

git clone https://github.com/your-org/terraform-config.git

このコマンドでリモートリポジトリ（GitHubなど）の全内容がローカルマシンにダウンロードされます。インフラコード管理では、組織のGitHubにアップロードされたTerraformコードやAnsibleプレイブックを取得する場面で頻繁に使用されます。

変更の追跡と記録

ファイルを編集した後、その変更をGitに記録する流れは以下の通りです。

1. ステージングに追加

git add .

または、特定のファイルのみ：

git add main.tf variables.tf

変更を「ステージング」という一時的な待機エリアに追加します。これにより、どのファイルをコミット対象にするかを選別できます。

2. コミットして記録

git commit -m "VPC設定を新バージョンに更新"

ステージングされたファイルを永続的に記録します。メッセージには「何を変更したか」を簡潔に書くことがベストプラクティスです。例えば「Subnet CIDR範囲を拡大し、インスタンス数100台に対応」のように具体的な内容を記載すると、後でコミット履歴を追跡する際に非常に役立ちます。

3. リモートに送信

git push origin main

ローカルで記録したコミットをリモートリポジトリ（GitHub等）に送信します。これにより、他のチームメンバーもあなたの変更を確認でき、本番環境へのデプロイ前にレビューを受けられます。

ブランチ操作と切り替え

本番環境のコードを直接編集するのは危険です。そこでブランチを活用します。

新しいブランチの作成と切り替え：

git checkout -b feature/security-group-rules

このコマンドで「feature/security-group-rules」という新しいブランチが作成され、自動的にそこに切り替わります。ブランチ名は目的が分かりやすいように命名するのが慣例です。

既存ブランチへの切り替え：

git checkout main

メインブランチに戻ります。

現在のブランチ確認：

git branch -a

ローカルとリモートのすべてのブランチ一覧を表示します。複数プロジェクトを並行して管理する場合に、どのブランチで作業中かを確認するのに便利です。

インフラエンジニアの実践的…

フィーチャーブランチによる…

実際のプロジェクトでは、以下のような流れでGitを運用することが一般的とされています。

mainブランチから新しいブランチを作成
```
git checkout -b fix/elb-health-check
```
セキュリティグループやELBの設定変更など、機能ごとにブランチを分ける
ローカルで変更を加える
Terraform設定ファイルやAnsibleプレイブックを編集し、ローカル環境で動作確認

段階的にコミット

git add main.tf

git commit -m "ELB ヘルスチェック設定を追加"



git add outputs.tf

git commit -m "ELB エンドポイント出力を定義"

変更内容ごとに細分化してコミットすることで、後の追跡が容易になります

リモートにプッシュ
```
git push origin fix/elb-health-check
```
プルリクエストを作成
GitHubのWebインターフェースからプルリクエスト（PR）を作成し、チームメンバーにレビューをリクエスト
レビュー後にマージ
```
git merge fix/elb-health-check
```
または、GitHubのUIからマージ操作を実行

プルリクエストとコードレビ…

インフラコードの品質を保つには、プルリクエスト（PR）を活用したコードレビューが重要です。

PRのメリット：

変更内容が可視化され、本番適用前に誰でも検証できる
セキュリティ設定の漏れやベストプラクティス違反を事前に防ぐ
新しいチームメンバーが既存のコードを学ぶ教材になる
本番環境への予期しない変更を防ぐ仕組みが構築できる

GitHubでは、特定のブランチへのマージを承認ルール（例：最低2名の承認が必須）として設定することも可能です。本番環境を管理する場合は、このような強化されたレビュープロセスを導入するのが推奨されています。

コンフリクト解決の基本

複数のエンジニアが同じファイルを編集した場合、マージ時にコンフリクト（競合）が発生する可能性があります。

コンフリクトが発生した場合の手順：

git status

まず、どのファイルに競合があるかを確認します。ステータス出力で「both modified」と表示されたファイルが該当します。

該当ファイルをエディタで開くと、以下のような形式で競合内容が表示されます。

<<<<<<< HEAD
resource "aws_security_group" "web" {
  ingress {
    from_port = 80
  }
=======
resource "aws_security_group" "web" {
  ingress {
    from_port = 8080
  }
>>>>>>> feature/update-port

この場合、どちらの設定を採用するかを決め、不要な部分を削除して保存します。その後、

git add conflicted-file.tf

git commit -m "コンフリクトを解決"

で確定させます。ただし、複雑なコンフリクトやセキュリティに関わる設定の場合は、チームメンバーに相談してから解決するのが安全です。

Gitの安全な運用とセキュ…

認証情報とトークンの管理

インフラコードにはAWSやGCPなどのアクセスキーが含まれることがあります。これらの認証情報を誤ってGitリポジトリに登録することは重大なセキュリティリスクとされています。

本番のAWSアクセスキーやAPIトークンはリポジトリに含めない
local.tfvarsのような個別設定ファイルは.gitignoreで除外
環境変数またはSecrets Managerなどのツールで管理
万が一リポジトリに登録してしまった場合は、すぐに該当トークンをローテーション（失効させ、新しいものを発行）

gitignoreファイル…

Gitで管理すべきでないファイルを除外するために、.gitignoreファイルを活用します。

インフラエンジニアにとって一般的な除外対象：

*.tfstateと*.tfstate.backup — Terraformの状態ファイル（機密情報含有）
terraform.tfvars — 環境固有の変数値
.env — 環境変数ファイル
*.keyと*.pem — SSH秘密鍵
.terraform/ — Terraformキャッシュディレクトリ

これらをあらかじめ.gitignoreに記載することで、誤登録を防げます。

コミットメッセージのベスト…

Gitの追跡性の価値は、コミットメッセージの質に大きく左右されるとされています。

良いコミットメッセージの例：

「RDSのバックアップ保持期間を7日から14日に延長」
「SQLインジェクション対策としてセキュリティグループのインバウンドルールを制限」
「本番環境のログ出力レベルをDEBUGからINFOに変更」

避けるべき例：

「更新」「修正」「change」など、具体性を欠いたメッセージ
複数の無関連な変更を1つのコミットに混在させる

まとめ：Gitマスターへの道

Gitの基本コマンド——git init、git add、git commit、git push、git branch、git merge——をマスターすれば、インフラエンジニアの日常業務の約9割に対応できるとされています。

本記事で解説した内容を整理すると：

リポジトリの作成と複製：git init / git clone でプロジェクトを開始
変更の記録：git add / git commit / git push で履歴を保存・共有
ブランチ管理：git checkout / git branch で本番環境を保護しながら開発
チーム運用：プルリクエストとレビュープロセスでコード品質を確保
セキュリティ：.gitignore と認証情報管理で機密漏洩を防止

Gitは一度習得すれば、IaC時代のインフラエンジニアにとって強力な武器になります。本記事で紹介したコマンドを何度も実践し、自分の手で試しながら習熟を深めることをお勧めします。

セキュリティ設定やベストプラクティスの詳細については、Git公式ドキュメントや各クラウドプロバイダー（AWSやGCP）の推奨ガイドで最新情報をご確認ください。