【IT用語】「Git（ギット）」とは？変更履歴を残すタイムマシン

結論：「Git」＝「プロジェクトの変更履歴を記録する仕組み」

Gitは、「いつ、誰が、どのファイルを、どのように変更したか」を記録するバージョン管理システムです。

過去の状態と今の状態を比べたり、問題が起きる前の内容を確認したりできます。ゲームに例えるなら、複数のセーブポイントを管理できる仕組みに近いでしょう。

ただし、Gitが作業中の内容を自動で保存してくれるわけではありません。記録したい変更を選び、次の章で紹介する「コミット」を行って、初めて履歴に残ります。

Gitでできること

1. 変更内容を確認する

「昨日から何を変えたのか」「この行を誰が変更したのか」を調べられます。

2. 過去の状態を確認する

コミットとして記録した時点のファイルを取り出したり、変更を打ち消したりできます。

3. 作業を枝分かれさせる

Gitでは、変更の流れを「ブランチ」として分けられます。

• mainブランチ： 安定した本流。
• featureブランチ： 新機能などを試す作業用の流れ。

本流を保ったまま別のブランチで作業し、完成したら変更を合流できます。この合流が「マージ」です。

GitとGitHubは別物

名前が似ていますが、役割は違います。

• Git： PC上でも使える、変更履歴を管理する道具。
• GitHub： Gitのリポジトリをオンラインで共有し、レビューや共同作業を行えるサービス。

例えるなら、Gitは写真を撮って整理するカメラ、GitHubは写真を共有して話し合えるオンラインアルバムです。

Gitだけでも履歴は作れます。しかし、PC内だけに保存している状態では、そのPCやストレージが故障した時に履歴ごと失う可能性があります。大切な作業は、GitHubなどの別の場所にも送っておくと安心です。

GitはWordやExcelにも使える？

Gitは多くのファイルを管理できますが、特に力を発揮するのは、ソースコードやMarkdownのようなテキストファイルです。

WordやExcelのファイルも保存できますが、中身の差分を人が読みやすい形で比較しにくい場合があります。共同編集や文書の版管理では、Microsoft 365など別の仕組みが向くこともあります。

チーム作業で役立つ理由

複数人が同じ場所を変更すると、Gitは自動で統合できないことがあります。これが「コンフリクト」です。

Gitは衝突を見つける手助けをしてくれますが、どちらの内容を残すかを決めるのは人間です。Gitを使えば事故がゼロになるのではなく、変更を見えるようにし、相談しながら直せるようになります。

KatakataLabで実際に確認したこと

KatakataLabでは、トップページ、各ツール、テスト、公開設定を同じリポジトリで管理しています。修正前には git status --short で変更中のファイルを確認し、git diff で意図しない文章や設定が混ざっていないかを読みます。

公開後に表示が変わった時は、直近の履歴と現在のファイルを比べます。Gitの履歴だけで原因を断定せず、自動テストや本番ページの本文も照合することで、「コードは変わったが公開されていない」「古いキャッシュを見ている」といった別の問題を切り分けられました。

この言葉が会話に出てくるとき

例えば、「先週の見出しに戻したい」となったときです。上書き保存だけだと、途中の版を取り出せません。

例えば、公開前に「何を変えたか」を見直すときです。ファイル単位ではなく、意味のあるまとまりで差分を見ます。

勘違いしやすい点

• GitHubと同じ： Gitは履歴の仕組み、GitHubはその履歴を共有する場所のひとつです。
• チームだけの道具： 一人でも、「いつ・何を・なぜ」を残す説明書になります。
• 保存すれば消えない： 同じPCの中だけなら、故障と一緒に失うことがあります。

使う理由は速さより、戻れることと、変更の意図を残すことです。

まとめ

• Git ＝ 「プロジェクトの変更履歴を管理する仕組み」
• コミット ＝ 「選んだ変更を履歴として記録すること」
• ブランチ ＝ 「本流から分けた作業の流れ」
• GitHub ＝ 「Gitの履歴を共有し、共同作業できるサービス」

Gitは魔法の自動保存ではありません。それでも、正しく記録を残せば、「どこで何を変えたのか」をたどれる頼もしい道具になります。

次の記事では、Gitに履歴を残す「コミット」について解説します。

ここまでお読みいただきありがとうございました！

一人開発でもGitが効いた場面

mainへ直接載せる前に、壊れた状態を切り戻せる安心感があります。KatakataLabでは文章の増減やツール改修をコミット単位で残し、「いつ・何を・なぜ」変えたかを後から追えるようにしています。

• 大きな見た目変更と文言修正を同じコミットに混ぜない
• 公開前に差分を読み、意図しない削除がないか見る
• 戻したいときは「どのコミットまで正常だったか」を先に決める

Gitはチーム専用の道具ではなく、未来の自分への説明書でもあります。