はじめに
こんにちは。株式会社MIXIでGit研修の講師を務めている登内です。本連載では、株式会社MIXIで行っているGit研修の内容をもとに、3回にわたってGitについて解説します。第2回ではGitをチーム開発で使う方法を紹介し、第3回では発展的な内容になりますが、Gitの内部構造について解説していきます。
対象読者
- これからGitを使い始めようと思っている方
バージョン管理とは?
あるファイルに変更を加えた時、念のため元の状態も残しておきたいということは良くあると思います。例えば、こういったファイル名による管理をしていた方もいるのではないでしょうか?
レポート.pdf / レポート(1).pdf / レポート_最新.pdf / レポート_修正版.pdf / レポート_最終稿.pdf
しかし、これだとどれが最新版なのか、1つ前の版はどれか分からなくなってしまうこともあるかと思います。 以下のようにファイル名のサフィックスに日付を付けておく工夫もできますが、新しいバージョンを保存するたびにファイル数が増えて管理の手間がかかるうえ、バージョンごとにどのような更新を行ったかが分からなくなるなどのデメリットがあります。
レポート_20220814.pdf => レポート_20220816.pdf => レポート_20220901.pdf
1人で編集する資料であれば、これだとしてもそこまで問題にはなりません。ただし、100人で数年かけて開発するソフトウェア開発の場面ではどうでしょうか? 編集が複数人により同時並行で行われると、それぞれのファイルの最新状態がどれであるか分からなくなったり、同一ファイルに対する変更が競合したりするなどの問題が生じやすくなります。
Gitを始めとするバージョン管理システム(VCS)を使うと、こういった問題を解決できます。VCSを使うことの主なメリットは以下です。
- 多数のファイルのバージョンをかしこくバックアップできる
- ファイルを任意の時点の状態まで簡単に戻せる
- 変更履歴を簡単に辿ったり、比較したりできる
- 問題が生じた際、誰がいつバグを混入させたかを確認できる
Gitの初期設定
Gitのインストールがまだの方は、こちらのサイトを参考に、ご自身の環境にインストールしてください。インストール後は以下のコマンドを実行し、Gitの初期設定を行ってください。
$ git config --global user.name XXXXXX $ git config --global user.email XXXXX@XXXXXX
また、必要に応じて、ご自身のGitの使用環境に合わせて使いやすいように追加設定してください。例としてBashでGitを使用する方は、こちらのサイトを参考に設定するとGitをより便利に使うことができます。
Gitの使い方
ここからはGitの基本的な使い方を解説していきます。第一回となる本記事ではあくまで基礎的なコマンドの使い方の解説にとどめます。ここで紹介する各コマンドや操作について、より詳しい仕組みの解説は第3回のGit内部構造についての記事で解説予定なので、興味を持たれた方はそちらの記事をお待ちください。
Gitリポジトリの初期化
プロジェクトをGitで管理したい場合は、そのプロジェクトのディレクトリに移動して、git initコマンドを打ちます。
$ mkdir git-tutorial && cd git-tutorial $ git init
これにより、Gitリポジトリが初期化され、つまりGitによるバージョン管理ができるようになります。
具体的に何が起きているかというと、そのプロジェクトのディレクトリに.gitというサブディレクトリが作られ、その中にGitリポジトリに必要なすべてのファイルが格納されます。.gitディレクトリの中身の詳細については、第3回の記事で紹介します。
ファイルを管理対象に追加
初期化しただけの状態では、まだどのファイルもGit管理下にありません。ファイルのバージョン管理を始めるには、そのファイルを管理対象に追加する必要があります。
以下のように、ファイルを作成したあと、そのファイルについてgit addコマンドを実行した後にgit commitコマンドを実行してください。
$ echo Hello > README.md $ git add README.md $ git commit -m "first commit"
これで作成したREADME.mdというファイルをGitの管理対象に加えたことになります。
編集履歴の記録
これでバージョン管理の準備が整いました。それでは、管理対象ファイルであるREADME.mdに変更を加えていきます。変更を加えた際も、先ほどと同じ手順でgit addコマンドの後にgit commitを実行します。git commitを実行するごとに新しくバージョンが記録されていきます。
$ echo "Hello World" > README.md $ git add README.md $ git commit -m "second commit"
ちなみに-mオプションの後に文字列が続いていると思いますが、これはそのコミットについてのメモ・コメントを記録するもので、そのバージョンや差分の意味がわかるようなメモを残しておくと、後で履歴を確認する際に分かりやすくなります。
$ touch report_1.txt $ git add report_1.txt $ git commit -m "Add report_1.txt" $ echo "Git is one of the version control systems." >> report_1.txt $ echo "writing report_1..." > README.md $ git add README.md $ touch report_2.txt
ここで、git statusコマンドを打つと、一つ前のコミットで記録されたバージョンから差分のあるファイルを確認できます。

階層ごとに分けてファイルが表示されていると思いますが、それぞれ以下の意味があります。
-
Changes to be committed- 次回コミットの対象に含まれているファイル
-
変更後に
git addしたファイル
-
Changes not staged for commit- Gitの管理下にあるファイルのうち、差分はあるが次回コミット対象に含まれていないファイル
-
変更後に
git addしていないファイル
-
Untracked files- Gitの管理下にないファイル
ここから分かる通り、git addは次回コミットの対象(Gitではステージングと呼びます)に含めるコマンドになります。まとめて編集したからといって、一度にすべての変更を次のバージョンに記録してしまうと、問題が生じたときに切り分けが難しくなります。新しくバージョンを記録するときは、できるだけ意味のある最小単位で記録するのがおすすめです。
なお、git diffコマンドで変更の内容を見ることもできます。git add済みのREADME.mdは--cachedオプションが必要です。

report_1.txtもgit addしてコミット対象に含め、変更をコミットしておきます。
$ git add report_1.txt $ git commit -m "Update README.md and report_1.txt"
編集履歴の確認
これまで記録したコミットログ(バージョン履歴)は、git logを実行することで確認できます。

黄字で表示されているのがコミットハッシュで、コミットを一意に識別するためのものです。
履歴を遡って任意の時点にチェックアウト
履歴を遡って、特定のバージョン時点の状態にするにはチェックアウト機能を使います。
git logをしたときに最初に表示されたコミットのハッシュ値の横に(HEAD -> main)とあることがわかると思います。このHEADというのが現在参照しているコミット(バージョン)です。mainとあるのはブランチ名ですが、これは後ほど説明します。
この状態で、二つ前のコミット(second commit)の時点に移ることにします。
該当のコミットハッシュを使い、checkoutというサブコマンドを使うことでそのコミットに移ることができます。
$ git checkout e01472f75fb2daa7bebe35c2d874ded1772643e2
$ git log
commit e01472f75fb2daa7bebe35c2d874ded1772643e2 (HEAD)
Author: tonouchi510 <xxxxxx@gmail.com>
Date: Thu Aug 25 11:50:56 2022 +0900
second commit
commit d808fdd96f2fb2861e49929d1e7b85331de84e91
Author: tonouchi510 <xxxxxx@gmail.com>
Date: Thu Aug 25 11:48:14 2022 +0900
first commit
$ cat README.md
Hello World
git logの結果からも、HEADが該当コミットのところに動いていることが分かります。cat README.mdの結果から、ファイルの中身もそのバージョン時点の内容になっていることが確認できると思います。
最後に、元々の状態に戻すために以下のコマンドを実行します。
$ git checkout main
作業のやり直し
Gitのコマンドを間違えて実行してしまったという場合には、その作業をやり直すためのコマンドも存在します。
-
間違えて
git addしまったファイルを取り消す-
例:
git reset HEAD ファイル名 -
git resetで一括で取り消すこともできます
-
例:
-
間違えて行ったコミットを取り消す
-
例:
git reset HEAD
-
例:
ここでは基礎的なコマンド実行例にとどめますが、git resetは実は奥が深いコマンドです。また、git checkoutとも微妙に重なる部分もあります。この辺りを正確に理解するには第3回の記事で解説するGitの内部構造に関する理解が必要なので、興味がある方はそちらも見ていただけたらと思います。
※ちなみに最近ではcheckoutやresetの代替として、switchやrestoreというサブコマンドが使われることが多くなっているので、興味のある方はそちらも調べてみてください。
