始めに
Gitの主な目的であるVersion管理について説明していきます。
今回の記事は「Git CLI - 2. Gitでバージョンを管理する」_①になります。
目次
2-1 Git repositoryを作る
2-2 Versionを作る
2-3 Commit内容を確認する
2-4 git diff 一気にまとめよう
2-5 Versionを作る度、各段階のファイル状態を知る
2-6 作業を取り戻す
「Git CLI - 2. Gitでバージョンを管理する」_①：目次の2-3まで
「Git CLI - 2. Gitでバージョンを管理する」_②：目次の2-4
「Git CLI - 2. Gitでバージョンを管理する」_③：目次の2-6まで
2-1 Git repositoryを作る
レポジトリを作りたいディレクトリに移動し、Gitを初期化すればそのときから該当ディレクトリにあるファイルのバージョンを管理できます。
●Git初期化：git init
① ホームディレクトリにhello-gitというディレクトリを作り、cdコマンドでhello-gitディレクトリに移動します。
$ mkdir hello-git
$ cd hello-git
② hello-gitディレクトリの中身を確認するため、'ls -la'を入力します。
まだ何も作らなったため、ファイルは存在しません。
./ は現在のディレクトリ
../ は上位ディレクトリ
③ このディレクトリにレポジトリを作るため、git initコマンドを入力します。Gitを使用できるようにディレクトリを初期化する作業です。
'Initialized empty Git repository‥'というメッセージがでたら、これから該当ディレクトリでGitを使用できます。
$ git init
④ lsコマンドを使ってもう一度ディレクトリの中身を確認すると、先とは違って'.git'というディレクトリが作成されています。このディレクトリがGitを使用しながらバージョンがセーブされるレポジトリ(repository)です。
2-2 Versionを作る
Gitでバージョンとは、文書を修正・セーブする度に生成されるものだと考えればわかりやすいです。バージョン管理のため最も重要なのは、「Working tree, Staging area, Repository」の３つの段階について理解することです。
●作業ツリー(Working tree)
絵で一番左にある作業ツリー(Working tree)はファイルの修正、セーブなどの作業をするディレクトリです。2-1で作ったhello-gitディレクトリが作業ツリーになります。つまり、私たちの目に見えるディレクトリが作業ディレクトリです。
●ステージ(Staging area)
ステージはバージョン化するファイルたちが待機する場所です。例えば、10個のファイルの中で５個のファイルだけをバージョンに作りたい場合は5個のファイルだけをステージに移動させます。
●レポジトリ(Repository)
レポジトリはステージで待機していたファイルたちをバージョンに作りセーブする場所です。
※ステージとレポジトリは目に見えません。gitを初期化した際に作られる '.gitディレクトリ' の中で隠しファイルの形式で存在する領域です。
・ステージの内容：.git/indexファイルにセーブされる
・レポジトリの内容：.git/HEADファイルにセーブされる
2-2全体の内容を図にすると以下になります。
Working treeで文書を修正 ＞ 修正したファイルの中でバージョンにしたいファイルを Staging areaに addコマンドでセーブ ＞ Staging areaにいたファイルを commitコマンドでコミットすれば Repositoryにバージョンが生成されセーブ
※ 簡単まとめ：修正 > 追加(add) > コミット(commit)
$ git status で、Gitの状況確認
● git status コマンドでGitの状況確認と状況メッセージの意味
・No commits yet : まだコミットしたファイルがないです
・nothing to commit : 現在コミットするファイルはないです
↓
hello.txtという新しいファイルを作り、git statusを確認
hello.txtという Untracked filesがあるとでました。(現在 working treeに存在)
・Untracked files：Gitでまだ一度もバージョン管理をしたことがないファイル
↓
$ git add hello.txt
(staging areaへステージング)
↓
git statusを確認
「Untracked files：」というメッセージが「Changes to be committed：」に変わりました。そして、hello.txtファイルの前に「new file：」という説明が出ています。
(コミットする前に staging areaへ載せた状況)
↓
ファイルをコミットし、git statusを確認
$ git commit -m "message1"
staging areaに存在しているファイルを、git commitコマンドでコミットします。
-m オプションを付けるとコミットする際にセーブするメッセージが書けます。
ここでは今回のバージョンに"message1"と記録しました。次に何かファイルの内容を修正した際に、"message2"などでコミットすることでバージョンを管理しやすくなります。
(バージョンが作成され、Repositoryにセーブされた状況)
git statusをみると
・nothing to commit：バージョンにするファイルがさく、
・working tree clean：working treeも修正事項なしできれいです
と確認できます。
2-3 Commit内容を確認する
バージョンがちゃんと作られたか確認する時は git logコマンドを使用します。
先ほどコミットしたバージョンについての説明が表示されます。
Author : commitを作った人
Date : 作った日時
その下には"message1"とコミットメッセージが表示されます。
$ git log で、コミット記録を詳しく確認する
Hello.txtファイルの内容を修正し、新しいバージョンを作りました。
$ git commit -am "message2"
※一度コミットしたことがあるファイルは、git commitコマンドに -amオプションを付けてステージングとコミットを一気に処理できます。
(初回は、ファイルをまず staging areaに git addコマンドで載せてから git commitコマンドでコミットする必要があります。)
新しくコミットした後、git logでコミット記録を調べました。
"message2"というコミットメッセージも表示され、ちゃんとバージョンが作成されたことを確認できます。
● git log コマンドで画面に表示されるメッセージの意味
・commitという項目の後に英語と数字でできた長い文字列：
commit hash(コミットハッシュ)、もしくは git hashといいます。
各コミットを区別する IDみたいなものです。
・(HEAD -> master)：このバージョンが一番最新バージョンという表示です。
バージョンが増えるほど git logで確認できる情報量も増えます。
こうして git logコマンドで出てくる履歴・情報を'commit log'といいます。
終わりに
次回の投稿は「Git CLI - 2. Gitでバージョンを管理する_②」にて、
とても便利でお得なコマンド、git diffについて、一気にまとめたいと思います。
投稿者
エンジニアファーストの会社 株式会社CRE-CO
Shin Boyoung