Gitの導入方法と基本的な使い方(1)
カテゴリ:開発環境
企業などのある程度の規模の開発現場では必ずと言っていいほどGitが使われています。
もしこれから仕事で開発に携わろうと思っている方は、将来ほぼ間違いなくGitを使うことになります。
もちろん、Gitは個人の開発者にとっても非常に有用なツールです。
そこで今回はそのGitの導入および基本的な使用方法について解説したいと思います。
Gitとは?
Gitを一言でいえば分散バージョン管理システムです。
https://git-scm.com/より
Gitは無料のオープンソースの分散バージョン管理システムであり、小規模プロジェクトから大規模プロジェクトまで、すべてを迅速かつ効率的に処理するように設計されています。
Gitは簡単に習得でき、非常に高速でパフォーマンスが非常に小さいフットプリントを備えています。 Subversion、CVS、Perforce、ClearCaseなどのSCMツールよりも安価なローカルブランチ、便利なステージングエリア、複数のワークフローなどの機能を備えています。
バージョン管理とは?
何故バージョン管理ツールが必要なのでしょうか?
1つの理由は、企業で開発するソフトウェア(アプリ)は一般的に複数人で開発をしますが、そのソフトウェアを構成する各コンポーネントを複数のチーム、あるいは1つのコンポーネントも複数人が手を加えたりします。
そこで問題になるのはバージョンの競合です。
例えば誰かがAファイルのバージョン1.0ソースコードを修正したとします。
しかしほぼ同じタイミングで他の人が同様にAファイルを変更した場合、1つのファイルについて別仕様の更新ファイルができてしまうことになります。
さらに両者がそのファイルを共有フォルダに上書き保存した場合、一方の変更内容が消失してしまいます。
そういった事故を防止するためには、バージョン管理システムが必要になります。
Gitでは、あらかじめソフトウェアの全構成ファイルをローカルの倉庫(リポジトリ)にダウンロードしておき、開発者はローカルのファイルを編集した後、そのファイルの変更履歴(ヒストリー)と共に変更後のファイルをローカルの倉庫に保存(コミット)します。
つまり、個人のPCで定期的にローカルリポジトリ内のファイルをコミットしながら開発を進めます。リポジトリに変更履歴と共にコミットしておく利点は、後から履歴を頼りにコミットした各地点にファイルを戻すことができるようになる事です。
これはゲームでいうところのチェックポイントのようなものです。チェックポイントをこまめに作りながら開発を進めるというのがGitを用いた開発の主な作業になります。
そしてローカルリポジトリのファイルは最終的にはリモートリポジトリ(みんなが編集したファイルが保存されている共有フォルダ)に保存(git push)します。
リモートリポジトリに保存する際、もし他の人が編集済みのファイルが存在すれば競合として検出されるため誤って上書き保存してしまうことはありません。
また、Gitでは各地点のコミットしたファイルの差分を確認(git diff)したり、マージ(git merge)することも可能です。
Gitをインストールする
それではまずGitをインストールしましょう。
Gitは以下の公式ページからダウンロードできます。
https://git-scm.com/downloads
Windows環境用では、Gitコマンドを実行するためのGUIツールやbashプログラム(Git bash)も一緒にインストールされます。
Notebashはシェルの1つとなり、殆どのLinuxで標準のシェルとなっています。
Mac、Linux/Unix環境の場合は、ターミナル(端末)が最初からbashであるため、Git bashはインストールされません。
また、Linuxの場合はOS標準のパッケージ管理ツール(yum、apt-get等)から簡単にインストールが行えます。
例)
Debian/Ubuntu系の場合:
apt-get install git
Red Hat系の場合:
yum install git
Windows環境で「Windows Subsystem for Linux」を使用してUbuntu環境で開発する場合はOSがUbuntuであるため、apt-getコマンドを使用します。
Gitプロフィールの作成
Gitをインストール後は、まず以下のコマンドを実行して自分の名前とメールアドレスをGitに登録します。
git config --global user.email "自分の電子メールアドレス"
git config --global user.name "自分の名前"
リポジトリの作成(git init)
次にプロジェクトファイル(ソースコード)が保存されているフォルダのトップに移動してgit initコマンドを使用してリポジトリ(倉庫)を作成します。
git init
例)
app01という名前のプロジェクトフォルダの場合:
cd app01
git init
上記コマンドを実行すると、app01ディレクトリ直下に.gitフォルダが作成されます。
これがリポジトリ情報が保存されるフォルダになります。
$ ls -a1
.
..
.git
app01.js
Noteドットから始まる名前はLinux/Unixでは隠しファイル/ディレクトリとして扱われます。したがって.gitフォルダは-aオプション無しのlsコマンドでは表示されません。
コミットするファイルの確認(git status)
前の説明で「更新したファイルは定期的にコミットしながら作業をする」と言いましたが、その前に「コミットすべきファイルをGitに知らせておく」という作業が必要になります。これをステージングと言います。
つまり商品を陳列(コミット)する前に、陳列予定の商品をテーブルに並べておく(ステージング)ようなものです。
ステージングされていないファイルは、Gitはコミットしなければならないファイルとして認識しないため、コミットコマンドを実行してもコミットは行いません。
例えばステージングせずにコミットコマンドを実行した場合、以下のような結果が返されます。
例)
$ git commit -m "1st Commit"
On branch master
Initial commit
Untracked files:
app01.js
nothing added to commit but untracked files present
「Untracked files」はトラック上にない(ステージングされていない)ファイルを意味しています。
つまり、app01.jsファイルが見つかったが、トラック上にはファイルが何もないためコミットしなかったという旨のメッセージになります。
このため変更予定のファイルや変更を加えたファイルをまずステージングしておく必要があります。
変更を加えたファイルはgit statusコマンドで確認できます。
例)
$ git status
On branch master
No commits yet
Untracked files:
(use "git add ..." to include in what will be committed)
app01.js
nothing added to commit but untracked files present (use "git add" to track)
コミット予定のファイルとして何も追加されていないが、追跡されていないファイルapp01.jsが存在する事、そして追跡するには「git add」を使用する旨のヒントが出力されているのが分かりますね。
コミットすべきファイルをGitに知らせる(git add)
コミットすべきファイルをGitに知らせるためには、git addコマンドを使用します。
app01.jsファイルをコミット対象にしたい場合は次のコマンドを実行します。
git add app01.js
これでapp01.jsがコミット対象になりました。(これをステージングしたと言います)
このステージングの作業は面倒ですがコミットするたびに実行する必要があります。
コミットする(git commit)
ステージング済みの更新ファイルを履歴と共にリポジトリに保存する事を「コミットする」と言いますが、コミットする場合はgit commitコマンドを-mスイッチと共に指定します。
-mスイッチはコミットするファイルの説明を記述するためのスイッチとなり必須です。
コミットする場合は以下のように実行します。
git commit -m "1st Commit"
例)
$ git commit -m "1st Commit"
[master (root-commit) 9e89450] 1st Commit
1 file changed, 3 insertions(+)
create mode 100644 app01.js
コミットの履歴を調べる(git log)
コミットした履歴はgit logコマンドあるいはgit reflogコマンドで確認が行えます。
今回は例であるためメッセージを「1st Commit」としていますが、通常はコミットする際のメッセージ(-mスイッチ)に、どのような変更を加えたかが分かる説明を記述し、後から履歴を見て何を変更したかが分かるようにします。
例)
$ git log
commit 9e894500a9b3713d36c362397cb5cb2f37531441 (HEAD -> master)
Author: mogusa
Date: Sun Nov 17 18:17:19 2019 +0900
1st Commit
$ git reflog
9e89450 (HEAD -> master) HEAD@{0}: commit (initial): 1st Commit
コミットしたファイルとの差分を調べる(git diff)
コミットしたファイルとの差分を調べる場合はgit diffコマンドを使用します。
まず、app01.jsファイルを変更し、再度addおよびcommitします。(2回目のコミット)
$ git add app01.js
$ git commit -m "2nd Commit"
[master 6c96b0e] 2nd Commit
1 file changed, 1 insertion(+), 1 deletion(-)
ちなみにcommitする際に-aスイッチを付与することで、addとcommitを同時に行う事もできます。
git commit -a -m "2nd Commit"
これで「1st Commit」と「2nd Commit」の2つのチェックポイントができました。
$ git reflog
6c96b0e (HEAD -> master) HEAD@{0}: commit: 2nd Commit
9e89450 HEAD@{1}: commit (initial): 1st Commit
「1st Commit」と「2nd Commit」の2つのチェックポイントのファイルの差分を調べる場合は、以下のようにgit diffコマンドを実行します。
git diff 比較対象のSHA1
NoteSHA1は各コミット履歴の冒頭に表示されているハッシュ値(例の場合9e89450や6c96b0e)です。
例)
$ git diff 9e89450
diff --git a/app01.js b/app01.js
index 00cecf5..2f20da1 100644
--- a/app01.js
+++ b/app01.js
@@ -1,3 +1,3 @@
function getDaysOfMonth(year, month) {
- //コード
+ return new Date(year, month, 0).getDate();
}
行頭の「-」は削除された行、「+」は追加された行を示します。つまり、1つの行が変更されているということが分かりますね。
コミットしたファイルを戻す(git reset)
最後にGitの醍醐味であるファイルを任意のチェックポイントに戻す機能を使ってみましょう。
今回は、最初にコミットしたチェックポイント「1st Commit」(9e89450)に戻してみます。
ファイルを戻す場合は、git resetコマンドと--hardスイッチを使用します。
git reset --hard 対象のSHA1
例)
$ git reset --hard 9e89450
HEAD is now at 9e89450 1st Commit
app01.jsファイルの中身を見てみます。
$ cat app01.js
function getDaysOfMonth(year, month) {
//コード
}
「1st Commit」の地点に戻っていることが確認できますよね。
ではもう一度「2nd Commit」に戻してみたいと思います。「2nd Commit」のSHA1は6c96b0eですから以下のように実行します。
$ git reset --hard 6c96b0e
HEAD is now at 6c96b0e 2nd Commit
$ cat app01.js
function getDaysOfMonth(year, month) {
return new Date(year, month, 0).getDate();
}
はい、無事「2nd Commit」の状態に戻っていますね。
それでは今回はここまでにいたします。
次回はブランチの作成やクローン、共有リポジトリへのプッシュ、プルについて解説したいと思います。
オススメ書籍:
こちらの「独習Git」は解説が分かりやすく(翻訳が秀逸)、且つ丁寧に解説されていて非常にお勧めですよ。Gitに関してはこの1冊で十分です。
公開日時:2019年11月17日 18:43:42
最終更新日時:2024年04月09日 02:13:02