プログラム開発や文書作成をしていると、過去に書いたコードや文章を「ちょっと前の状態に戻したい」「どこをいつ変更したのか履歴を見たい」ということがよくあります。こうしたニーズに応えるのがバージョン管理システムであり、その代表格として今やデファクトスタンダードになっているのがGitです。
この記事ではGitの基本的な使い方として「ローカルリポジトリを構築し、ファイルの変更を記録する」という流れを学びつつ、Gitの本質的な仕組みを理解していきましょう。
この記事をご覧いただく前に、以下のページでGitの本質的な考え方を理解しておくとよりスムーズに学習することができるはずです。未読の方は、是非一度ご覧になってください。
- ローカルリポジトリとは? 〜 Gitの世界における「自分だけの管理空間」
- Gitを使い始める前の準備:初期設定
- Gitリポジトリの作成:git init の仕組み
- ワーキングツリー(作業ツリー)・ステージ(インデックス)・リポジトリの関係
- ファイルを作成してステージ領域に追加する:git addの使いどころ
- コミットして変更を履歴として残す:git commit
- git statusで状態を確認する:変更があるかどうかを常にチェック
- 変更の確認:git diffで何が変わったかを見る
- コミット履歴を覗く:git logで変更履歴を確認する
- 不要なファイルをGit管理から外す:.gitignoreの活用
- 「あっ、間違えた!」そんな時:コミットの取り消しややり直し
- ローカルリポジトリを活用して作業をスムーズにするコツ
- この先に待つGitの世界:ブランチやリモートリポジトリとの連携へ
- まとめ:ローカルリポジトリを知ることから始めよう
ローカルリポジトリとは? 〜 Gitの世界における「自分だけの管理空間」
Gitには大きく分けて2種類のリポジトリがあります。
1つは今回学ぶローカルリポジトリで、自分の手元のコンピュータ内に作成されるリポジトリです。もう1つはネットワーク越しに存在するリモートリポジトリ(GitHubなどが提供するリポジトリ)です。ローカルリポジトリでは、あなたが管理したいファイル・フォルダを「追跡対象」とし、それらのファイルの変更履歴を自分のコンピュータ内に保存する仕組みが作られます。
ローカルリポジトリを活用する最大の魅力は、ネットワークに接続していなくても自由に履歴を管理できるという点です。データはすべて自分のマシン内にあるため、コミット(変更の記録)やgit log
(履歴確認)といった操作が即座に行えます。これが「分散型バージョン管理システム」の強みなのです。
リモートリポジトリは、複数人での共同開発や別マシンとの同期に大変便利ですが、最初にバージョン管理の仕組みを理解するにはローカルリポジトリの操作から始めるのがおすすめです。
Gitを使い始める前の準備:初期設定
Gitを利用する際には、まずユーザー名とメールアドレスを設定しておく必要があります。これらはコミットを行った時に「誰が変更したのか」を明確に記録するために使われます。以下のコマンドでグローバル設定を行いましょう。
git config --global user.name "Your Name" git config --global user.email "your_email@example.com"
ここで指定する名前とメールアドレスは、あなたがGitをインストールしている環境であれば、すべてのローカルリポジトリに適用されます。もちろん、後から変更も可能です。--global
オプションを外し、リポジトリごとにユーザー名やメールアドレスを切り替えるといった使い方もできます。
設定内容を確認したい場合は、以下のようにコマンドを入力すると設定の一覧が表示されます。
git config --list
表示された情報の中にuser.name
やuser.email
が含まれていれば、設定が反映されています。
Gitリポジトリの作成:git init の仕組み
では、いよいよローカルリポジトリを作成してみましょう。まずは、Gitで管理したいプロジェクトフォルダ、あるいは新規フォルダを作成し、そこへ移動します。例としてmy-git-project
というフォルダを作りましょう。
mkdir my-git-project cd my-git-project
その上で、以下のコマンドを実行します。
git init
これにより、現在のディレクトリ(my-git-project
フォルダ)内に隠しフォルダである.git
が生成されます。.git
フォルダこそがGitの管理領域であり、このフォルダ内にコミット履歴やブランチ情報などが保存されます。言い換えると、この.git
フォルダがあるディレクトリがローカルリポジトリである、ということです。
Gitの管理は基本的に「今いるディレクトリの.git
フォルダ」を基点に行われますので、もしどこか別のフォルダで作業しているつもりが.git
がなかった…となると、Git管理が適切に行われない原因となります。プロジェクトのルートとなる場所でgit init
を実行することを意識しましょう。
ワーキングツリー(作業ツリー)・ステージ(インデックス)・リポジトリの関係
Gitでは、作業ファイルの状態を把握する際に以下の3つの領域を認識すると理解しやすくなります。
- ワーキングツリー(作業ツリー): 実際にファイルを編集している手元のディレクトリ。普段の作業はこの領域で行う
- ステージ(インデックス): 次にコミットする候補(変更内容)を一時的に登録しておく場所
- ローカルリポジトリ: コミット済みの変更履歴が保存されている場所。Gitの中枢
ファイルに何らかの変更を行ったら、まずはその変更をステージに追加(git add
)し、その後コミット(git commit
)を行うことで、最終的にローカルリポジトリに変更が記録されます。この流れをしっかり押さえておくとGitの基本操作で迷うことが少なくなります。
ファイルを作成してステージ領域に追加する:git addの使いどころ
それでは、実際にファイルを作成し、Gitで追跡させてみましょう。以下の例では、hello.txt
というファイルを新規作成してみます。コマンドはOSによって多少異なりますが、LinuxやmacOSの場合は以下でOKです。
echo "Hello Git!" > hello.txt
Windowsの場合は、コマンドプロンプトやPowerShellでecho Hello Git! > hello.txt
などと入力しても同様です。これで現在のディレクトリにhello.txt
が作成され、中身としてHello Git!
というテキストが書かれた状態になります。
次に、この新規ファイルをステージに登録します。コマンドは以下の通りです。
git add hello.txt
ここで「ステージに追加する」とは、「次回のコミットに含める変更として印を付ける」イメージです。1回のコミットで複数のファイルをまとめて記録することもあるため、git add
はある種の「候補リストに入れる」操作ともいえます。
もし変更したファイルが多数ある場合、一括でgit add .
(ドット)を使って現在のディレクトリ以下にある変更すべてをステージに追加することも可能です。しかし、慣れないうちは「意図しないファイルもコミット対象になる」リスクを避けるために、個別にgit add
した方が安全かもしれません。
コミットして変更を履歴として残す:git commit
ステージに追加した変更は、コミットという操作を行うことでリポジトリに正式に保存されます。コミットは、変更履歴に「スナップショット(変更の塊)」を刻む行為です。以下のように入力してコミットを実行してみましょう。
git commit -m "Add hello.txt"
-m
オプションに続けて記述するのが「コミットメッセージ」です。コミットメッセージには、その変更で何を行ったかを簡潔かつ明瞭に書くことが望ましいとされています。例えば「Fix login bug」「Update README for installation steps」のように、「誰が見ても理解しやすい形」に整えるのが理想です。後々、自分自身が過去の履歴を読み返す時にも役に立ちます。
コミットを行うと、Gitはステージにあったすべての変更ファイルを一つの固まりとしてリポジトリに保存します。これにより、hello.txt
を作ったという履歴が正式に記録されたことになります。
git statusで状態を確認する:変更があるかどうかを常にチェック
Gitを使いこなす上で最も多用するコマンドの一つがgit status
です。これは、現在のリポジトリがどのような状態になっているのか(コミットされていない変更はあるか、ステージに追加されていないファイルはあるか、など)を一覧表示してくれます。
git status
このコマンドを実行すると、例えば「何も変更されていない」「新たに追加されていないファイルがある」「ステージに未登録の変更がある」などのメッセージを返してくれます。慣れないうちは「まずはgit status
」が合言葉になるくらい、頻繁に確認すると良いでしょう。特に複数のファイルを編集した時などは、git status
を使用してどのファイルがまだステージに追加されていないかを把握することが大切です。
変更の確認:git diffで何が変わったかを見る
コミット前に「ファイルのどこがどう変わったのか」を可視化する方法として、git diff
コマンドがあります。例えば、hello.txt
の内容を編集した後にgit diff hello.txt
を実行すると、編集前後の差分が表示されます。
Gitにおける差分表示は慣れるまで少し読みづらいかもしれませんが、「+
」から始まる行が新しく追加・変更された部分、「-
」から始まる行が削除・変更前の部分」を示します。差分を細かくチェックできるのはGitの非常に便利な点であり、コミット前の最終確認としても重宝します。
コミット履歴を覗く:git logで変更履歴を確認する
すでに行われたコミットの履歴を見る場合は、git log
コマンドを使います。以下を実行してみましょう。
git log
すると、これまでに行ったコミットのハッシュ値(英数字が多数並んだID)や、コミットメッセージ、日時、コミッターの情報などが時系列順に表示されます。もし表示が長くてスクロールが面倒な場合はgit log --oneline
のようにすると、1行ずつの要約表示になるので、履歴をざっと確認したい時に便利です。
さらに詳細なオプションも数多く存在し、例えばgit log -p
を実行すると、各コミットの差分を同時に表示できます。いろいろ試してみると、今後の開発において「いつ、何をコミットしたか」を手早く把握する助けとなるでしょう。
不要なファイルをGit管理から外す:.gitignoreの活用
通常のプロジェクトでは、ログファイルやビルド生成物、個人設定ファイルなど、バージョン管理に含める必要がないファイルが多々存在します。こうした不要ファイルを毎回git add
で追加しないようにするには、.gitignore
というファイルを活用します。
.gitignore
ファイルの中に「無視したいファイルやディレクトリのパターン」を記述しておくと、Gitはそれを自動的に無視し、ステージにも上げないようにしてくれます。例えば、以下のように書くとlogs
フォルダと*.log
(拡張子が.log
のすべてのファイル)を無視対象にできます。
.gitignore ファイルの内容: logs/ *.log
これにより、ローカルで生成されたログ関連のファイルが誤ってリポジトリにコミットされることを防げます。.gitignore
はプロジェクトの中で非常に重要な役割を果たすので、どんなファイルを無視すべきかを最初のうちに整理しておくと後が楽になります。
「あっ、間違えた!」そんな時:コミットの取り消しややり直し
Gitを使っていると、コミットメッセージのスペルミスに気づいたり、別のファイルを加えるのを忘れたままコミットしてしまったりと、「やり直したい」場面が出てきます。その時によく使われる手段がgit commit --amend
です。
直前のコミットを修正したい場合、以下のように実行するとコミットをまとめ直すことができます。ただし、すでにリモートにプッシュ(後述)してしまったコミットを--amend
で書き換えると、履歴が書き換わって混乱を引き起こす場合があるので注意が必要です。
# 例: 直前のコミットメッセージを修正したい git commit --amend -m "Fix commit message"
また、git revert <コミットID>
を使うことで、過去のコミットを「取り消すための新たなコミット」を行うことができます。これは、「過去の変更をなかったことにする」イメージです。リポジトリの履歴は絶対に消えませんが、変更を打ち消すコミットを追加することで「取り消し」状態が実現します。
ローカルリポジトリを活用して作業をスムーズにするコツ
ここまでで、ローカルリポジトリを作成し、ファイルをステージしてコミットするというGitの基本的なフローを体験しました。効率的に作業するためのポイントをいくつか挙げてみましょう。
- こまめにコミットする: ある程度まとまった変更ができたらコミットを行い、履歴を小さく区切っておく。後でトラブルがあったときに戻りやすい
- コミットメッセージを分かりやすく: 「何を変更したのか」を一目でわかるように書く。将来の自分や他の開発者にとって重要なドキュメントになる
- ステージに上げるファイルを意識して選ぶ: すべてを一度に
git add .
で追加するのではなく、変更意図に応じて必要なファイルだけをステージに追加すると、不要なミスコミットを防げる - Gitの状態チェックを怠らない:
git status
やgit diff
を活用し、想定外のファイル変更や差分がないか頻繁に確認する
この先に待つGitの世界:ブランチやリモートリポジトリとの連携へ
Gitにはまだまだ多くの機能が存在します。特に大型プロジェクトでは下記のような操作が重要になります。
- ブランチ(branch): 作業の流れを分岐させ、複数の並行開発を安全に進めるための機能。
git branch
やgit checkout -b
などのコマンドで使用 - マージ(merge): 分岐したブランチを本流に統合する操作
- リモートリポジトリとの連携: GitHubやGitLabなどを利用して、他の開発者と作業を共有。
git push
やgit pull
、git clone
などのコマンドを使う
しかし、これらを活用する前に、まずはローカル環境だけでGitの基本操作をしっかりと体験することが大切です。「ローカルリポジトリを扱うスキル」は、後々大きな規模のプロジェクトに参加する際のベースになってくれます。
まとめ:ローカルリポジトリを知ることから始めよう
本ステップでは、以下の一連の流れを紹介しました。
- Gitの初期設定(ユーザー名・メールアドレス)
git init
でローカルリポジトリを作成- ファイルを作り、
git add
でステージに登録 git commit
でリポジトリに変更履歴を保存git status
やgit diff
、git log
で状態や履歴を確認
これらはGitを使う上での最も基本的なステップです。少し慣れてくると、ブランチを作成して並行作業をしたり、リモートリポジトリを活用して他の人と共同開発を行ったり、Gitの強力な機能を存分に使いこなせるようになります。
まずは自分のPC上で小さなプロジェクトを作り、何度もファイルの編集・コミットを繰り返してみてください。その過程で.git
フォルダの存在意義やステージ・コミットの流れ、コミット履歴の確認と取り消しの方法などを体感的に理解できるでしょう。
こうした基礎を踏まえた上で、次のステップでは複数の変更を同時に扱うためのブランチや、インターネット上(GitHubなど)にリポジトリを配置する方法について学んでいくと、より深くGitを理解できるはずです。まずはローカルリポジトリでの基本操作をしっかりと身につけることが、Gitを本質的に理解する第一歩となります。