こんにちは、インフラエンジニアのryuです。
「Gitって、プログラマーが使うものでしょう？」
インフラの勉強を始めたばかりの方から、こんな声をよく聞きます。サーバーやネットワークを触るのに、なぜソースコード管理の道具を覚えないといけないのか。そう感じるのは、とても自然なことだと思います。
でも、結論から言うと、これからのインフラエンジニアにとってGitは避けて通れない道具になりつつあります。設定ファイル、構築手順、運用スクリプト。私たちが日々扱うものの多くは、実は「テキストファイル」だからです。
今日は、未経験の方に向けて、Gitとは何かという話から、最初に覚えるべきたった5つのコマンド、そしてGitHubで成果を共有するところまでを、できるだけ身近なたとえで説明していきます。
そもそもGitって、何をする道具なのでしょうか？¶
Gitを一言で言うと、ファイルの変更履歴を記録・管理してくれる仕組みです。専門的には「バージョン管理システム（VCS）」と呼びます。
とはいえ、これだけではピンと来ませんよね。まずは、ふだんのファイル保存と何が違うのかから見ていきましょう。
バージョン管理とは？「上書き保存」との違い¶
みなさんは、こんなファイルを作った経験はないでしょうか。
資料_最新.docx、資料_最新_修正版.docx、資料_最新_修正版_これで完成.docx。
笑い話のようですが、これはまさに「手作業のバージョン管理」です。いつ、誰が、どこを変えたのか分からなくなり、結局どれが本物なのかも曖昧になっていきます。
Gitは、この面倒な作業を肩代わりしてくれます。ファイルを一つに保ったまま、「この時点の状態」に名前と説明をつけて記録していく。そんなイメージです。
たとえるなら、Gitは作業のたびに写真を撮ってくれる几帳面な記録係のようなものです。あとから「3日前の状態に戻したい」と思ったとき、そのときの写真（記録）を選ぶだけで、まるごと元に戻せます。
この「戻せる」という安心感が、実は初心者にとって一番のメリットかもしれません。設定を壊してしまっても、記録が残っていれば怖くありません。
なぜ「分散型」だと便利なのか¶
Gitは「分散型」のバージョン管理システムと呼ばれます。ここも、たとえで理解してしまいましょう。
昔ながらの中央集権型の仕組みは、会社に一冊しかない台帳のようなものでした。全員がその一冊に書き込むので、台帳がある部屋に行かないと作業できません。台帳が火事で燃えたら、記録もすべて失われます。
一方でGitは、全員が台帳の完全なコピーを手元に持ちます。自分のパソコンの中に、これまでの全履歴が丸ごと入っているのです。だからネットにつながっていなくても記録を残せますし、誰かのコピーが無事なら復元もできます。
Gitは2005年、あのLinuxを生んだリーナス・トーバルズが、Linuxカーネル開発のために作った歴史ある道具です。今もなお活発に開発が続く、世界標準のオープンソースソフトウェアです。インフラの世界で使う多くの道具がそうであるように、Git自身もLinuxの文化から生まれたのですね。
インフラエンジニアにこそGitが必要な理由¶
さて、ここが今日の本題です。なぜコードを書かない（と思っている）インフラエンジニアにも、Gitが必要なのでしょうか。
理由はシンプルで、現代のインフラは「コード」として扱われるようになったからです。
手順書からコードへ ― Infrastructure as Code¶
昔のインフラ構築は、手順書を見ながらサーバーに一つずつコマンドを打ち込む、職人技の世界でした。しかしこの方法だと、打ち間違いも起きますし、同じ環境をもう一台作るのも一苦労です。
そこで広まったのが「Infrastructure as Code（IaC）」という考え方です。サーバーの構成やネットワークの設定を、すべてテキストのコードで書いておく。そのコードを実行すれば、いつでも同じ環境が自動で組み上がる、という発想です。
コードになったということは、それはもう管理すべき大切な資産です。誰がいつ設定を変えたのか、なぜ変えたのかを記録し、問題があれば前の状態に戻せなければいけません。その記録役として、Gitが自然と使われるようになったわけです。
具体的には、こんな変化が起きています。以前は「サーバーにログインして手順書どおりにコマンドを打つ」のが仕事でしたが、今は「構成を書いたファイルを直し、それをGitに記録して反映する」のが仕事になりつつあります。触る対象がサーバーそのものから、サーバーを定義したテキストへと移ったわけです。
だからこそ、テキストの変更を丁寧に管理できるGitのスキルが、そのまま仕事の質に直結します。ちょっとした設定変更でも、記録が残っていれば「いつ・なぜ変えたか」を後から追える。トラブルが起きたときに原因を切り分ける力にもつながっていきます。
構築の自動化については、コンテナ技術も欠かせません。手を動かして学びたい方は、Dockerを自分のLinux環境に入れて試す手順から始めると、コードで環境を作る感覚がつかめると思います。
「誰かと一緒に作る」ための共通言語¶
もう一つの理由は、チームで働くうえでGitが共通言語になっているからです。
インフラの仕事は、一人で完結することはほとんどありません。設定ファイルを複数人で編集し、レビューし合い、本番に反映する。この一連の流れを支えているのが、GitとGitHubのような仕組みです。
たとえば、あなたが直したファイアウォールの設定を、先輩が一度チェックしてから反映する。こうした「変更をお願いして、確認してもらう」やり取りも、Gitの上で行われます。就職・転職の面接でも、Gitを触ったことがあるかどうかは、地味に見られているポイントです。
こうしたチーム作業では、「ブランチ」という考え方もよく登場します。本番の流れとは別に、自分専用の作業スペースを枝分かれさせて、そこで安心して試すための仕組みです。最初のうちは名前だけ知っておけば十分で、慣れてきたら少しずつ使えるようになれば問題ありません。
ネットワークの基礎からじっくり固めたい方は、あわせてネットワークの学び方も読んでみてください。土台があると、設定ファイルの意味も理解しやすくなります。
最初に覚えるGitコマンドは、たった5つだけ¶
Gitには膨大なコマンドがありますが、最初から全部覚える必要はまったくありません。日々の作業のほとんどは、次の5つでまわせます。
つなぎとして、まずは一覧で全体像をつかんでおきましょう。
| コマンド | 役割 | たとえるなら |
|---|---|---|
git status |
今の状態を確認する | 作業机の上を見渡す |
git add |
記録する変更を選ぶ | 提出する書類を箱に入れる |
git commit |
変更を履歴に記録する | 箱に封をして日付印を押す |
git push |
GitHubへ送って共有する | 封をした箱を郵送する |
git pull |
GitHubから最新を取り込む | 届いた最新の箱を受け取る |
この5つの関係が分かれば、Gitの8割は理解したようなものです。難しそうに見える他のコマンドも、多くはこの基本の流れを補助するものにすぎません。まずはこの土台を、体で覚えてしまいましょう。ひとつずつ、実際の流れで見ていきます。
git init から commit までの流れ¶
まずは自分のパソコンの中に、Gitで管理する場所（リポジトリ）を作ります。ここは一度きりの準備です。
# 作業フォルダに移動して、Gitの管理を開始する
cd my-infra-project
git init
# ファイルを編集したら、今の状態を確認
git status
# 記録したいファイルを選ぶ（. は全部という意味）
git add .
# 説明をつけて履歴に記録する
git commit -m "ファイアウォールの初期設定を追加"
git commit の -m のうしろに書くのが「コミットメッセージ」です。これは未来の自分やチームへの手紙のようなもので、「何を・なぜ変えたか」が伝わるように書くのがコツです。
ここまでで、変更が一つの記録として手元に保存されました。ただし、まだこの記録はあなたのパソコンの中だけにあります。
GitHubへ push して、成果を共有する¶
ここで登場するのがGitHubです。GitHubは、Gitのリポジトリをインターネット上に置いて、共有・公開できるサービスです。Gitが「記録の仕組み」なら、GitHubは「その記録を置く倉庫であり、みんなで作業する広場」だと考えてください。
手元の記録をGitHubに送るのが git push、逆に最新を受け取るのが git pull です。
# 送り先（GitHubのリポジトリ）を登録する（最初の一度だけ）
git remote add origin https://github.com/yourname/my-infra-project.git
# 手元の記録をGitHubへ送る
git push -u origin main
# チームの誰かが更新していたら、最新を取り込む
git pull origin main
commit（コミット）はあくまで手元のリポジトリへの記録にすぎません。GitHubなどのリモートに反映するには、pushという別の操作が必要です。この「手元」と「リモート」の二段構えが、最初のうちは混乱しやすいポイントです。
GitHubには、記録を置くだけでなく、変更点を見やすく表示したり、その変更についてコメントで議論したりする機能もそろっています。現場では、こうした場で設定変更のレビューをしてから本番に反映する、という流れが一般的です。つまりGitHubを使えるようになることは、チーム開発の作法を身につけることでもあるのです。
自分の書いたコードや設定ファイルがGitHub上に並んでいく様子は、そのまま学習の記録にもなります。転職活動でポートフォリオとして見せることもでき、努力が目に見える形で残っていくのは、なかなか励みになりますよ。日々の積み重ねが、そのまま自分の実力の証明になっていくわけです。
つまずきやすいポイントと、練習のしかた¶
最後に、初心者がよく引っかかる場所と、無理なく上達するコツをお伝えします。
一番多いのが、「add と commit の違いが分からない」という悩みです。addは提出する書類を箱に入れる作業、commitはその箱に封をして記録する作業、と役割が分かれています。全部の変更をまとめて記録したいなら git add . してから git commit、と流れで覚えてしまいましょう。
次に多いのが、pushしようとしてエラーになるケースです。多くは、リモート側が先に更新されているのが原因です。あわてず git pull で最新を取り込んでから、もう一度pushすれば解決することがほとんどです。エラーメッセージには、たいてい次にどうすればよいかのヒントが英語で書かれています。読み飛ばさずに一度目を通す習慣をつけると、上達がぐっと早くなります。
三つ目は、「commitメッセージに何を書けばいいか分からない」という悩みです。難しく考える必要はありません。「〇〇を追加した」「△△の設定を修正した」のように、変更の内容を短く言い切るだけで十分です。未来の自分がひと目で分かることを目安にすれば、自然と良いメッセージになっていきます。
練習の環境づくりに、特別な準備はいりません。Linuxのコマンド操作に慣れておくと、Gitの理解も一気に進みます。ターミナルにまだ不安がある方は、先にLinuxコマンドの基本に目を通しておくと安心です。
練習のテーマも、身近なところで構いません。たとえば、勉強したコマンドをまとめたメモや、構築してみたサーバーの設定ファイル。そうした自分だけの小さなプロジェクトをGitで管理してみるのが、遠回りのようで一番の近道です。実際に「戻す」「差分を見る」といった操作を体験すると、Gitのありがたみが腹の底から分かってきます。
そして何より大切なのは、小さくてもいいので毎日手を動かすことです。自分の学習メモをGitで管理するだけでも、立派な練習になります。書籍でじっくり体系立てて学びたい方は、Git学習におすすめの本も参考にしてみてください。
独学で迷わないための地図を持とう¶
Gitは強力な道具ですが、それ単体を覚えても、インフラエンジニアにはなれません。Linux、ネットワーク、クラウド。学ぶべきことは幅広く、順番を間違えると遠回りになりがちです。
だからこそ、全体像を示してくれる地図が大切になります。何をどの順で学べばいいのか、まずはインフラエンジニアの学習ロードマップで流れをつかんでみてください。
InfraAcademyでは、Linux・ネットワーク・クラウドを未経験からでも段階的に学べるように、実際に手を動かすカリキュラムを用意しています。「独学だと続かない」「一人だと不安」という方は、まずLinuxの学習ロードマップから、最初の一歩を踏み出してみてはいかがでしょうか。
まとめ¶
今日は、インフラエンジニアにとってのGit/GitHubについてお話ししました。
Gitはファイルの変更履歴を記録してくれる几帳面な記録係で、インフラの世界でも設定やスクリプトを「コード」として管理するために欠かせない存在になっています。まず覚えるべきは status add commit push pull の5つだけ。手元で記録し、GitHubで共有する、という流れさえつかめば十分です。
最初は用語や操作に戸惑うかもしれませんが、それは誰もが通る道です。私自身も、addとcommitの違いに何度もつまずきながら覚えてきました。使ううちに、だんだん体になじんでいきます。
大切なのは、完璧に理解してから始めることではなく、小さく手を動かしながら慣れていくことです。壊しても記録があれば戻せる。その安心感を味方に、ぜひ気軽に触ってみてください。
一歩ずつ積み重ねれば、Gitはきっとあなたの心強い相棒になってくれます。それでは、また次の記事でお会いしましょう。
