自己紹介
こるくといいます。
限界開発鯖 とかいうヤバい開発者コミュニティに所属している茨城の高専生です。
前回に引き続き、私と他3人が今回もGitの使い方を説明していきます。
前回の記事が読み終わっている前提で話を進めます。
はじめに
今回は、実際にGitを使っていきながら、Gitの使い方や概念を覚えます。
ここからが本番です。
この記事は、茨城高専の2I向けに執筆された記事です。
実際に手を動かしなら読み進めてください。
リポジトリとは？
Gitでは、1つのプロジェクトを、「リポジトリ(Repository)」といいます。
基本的に「リポジトリ」内にあるすべてのファイル・フォルダがGitによって管理されることになります。
つくってみよう
百聞は一見にしかず、さっそくリポジトリをつくってみましょう。
まず、ファイルエクスプローラーで、リポジトリを作成したい場所（どこでも構いません）でGit Bashを起動します。
起動できたら、以下のコマンドを実行してください。
$ git init <作成したいリポジトリの名前>
今回はmy-first-repositoryとでもしておきましょう。
そうすると、先程開いたフォルダの中に、リポジトリ名と同じフォルダが出来ていると思います。
これがリポジトリです。
しかしこのままでは、リポジトリを操作することが出来ません。
操作できるようにするために、カレントディレクトリをリポジトリのフォルダに移しましょう。
以下のコマンドを実行してください。
$ cd <作成したリポジトリの名前>
これで作成したリポジトリに入って、操作できるようになりました。
▼ カレントディレクトリとは
カレントディレクトリ (current directory)とは｜
「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
コミットとは？
Gitの基本的な考え方であり、いちばん重要なものがこの「コミット」になります。
ここで一旦、そもそもGitがどんなツールだったかを考えます。
Gitとは、バージョン管理ツールです。
ここでいう「バージョン」とは、作業の区切り区切りを意味しています。
Gitでは、バージョンのことを「コミット(Commit)」と呼び、管理しています。
現在の状態を保存して、コミットとして記録することをコミットするといいます。（まんまですね）
▼ コミットのイメージ （青丸がコミット）
それぞれのコミットには、ID、編集者、日時、変更内容、編集者のコメント、編集内容などがそれぞれ保存されています。
図のように、プロジェクトが進行していくにつれて「コミット」が積み重なっていくイメージです。
作業中のコミットのことを、HEADとよびます。
やってみよう
それでは実際にコミットしてみましょう。
先程の、「リポジトリに入った状態」で、次のコマンドを実行するとコミットできます。
$ git add --all
$ git commit -m "<コメントの内容>"
実行すると、以下のように表示されるはずです。
On branch master
nothing to commit, working tree clean
どうやら失敗してしまったようです。
「コミットするものが登録されていません」と怒られてしまいました。
それでは、リポジトリ内に何かしらファイルをつくってみましょう。
Hello, Git!
今回は試しに、hello_git.txtというファイルをつくってみました。
そのうえで、同じコマンドをもう一度実行してみましょう。
$ git add --all
$ git commit -m "<コメントの内容>"
[master (root-commit) e1883d2] test
1 file changed, 1 insertion(+)
create mode 100644 hello_git.txt
と表示されました。どうやら成功したようです。
コメントについて
コメントは、そのコミットで具体的にどんな変更をしたかわかりやすく書きましょう。
日本語でも英語でも構いませんが、共同開発の場合、プロジェクト単位で書き方を統一しましょう。
コミットの方法まとめ
実際にコミットをする際には、
$ git add --all
$ git commit -m "<コメント>"
というコマンドを使うことが多いです。
このコマンドを実行すると、前回のコミットから変更のあったすべてのファイルをコミットすることが出来ます。
試しに、ファイルを適当に編集して、もう一度コミットしてみましょう。
確認しよう
git log
実際にコミットの履歴を確認してみましょう。
以下のコマンドで確認できます。
$ git log
いかがでしょうか。このように表示されるはずです。
上から、コミットのID、編集者、日時、コメントが記録されているのがわかると思います。
Column
コミット数が増えていくと、単なるgit logでは見づらくなることがあります。
そういうときは、--onelineオプションを使うことがあります。
$ git log --oneline
情報量は少なくはなりますが、非常にスッキリした表示になります。
git diff
次は、ファイルの差分（変更された部分）を見てみましょう。
以下のコマンドで確認できます。
$ git diff HEAD^
最新のコミットと、1つ前のコミットの間でどこが変更されたかがわかります。
ワークツリーとインデックス
先程、「基本的にリポジトリ内のすべてのファイルやフォルダが管理対象になる」と書きましたが、実際には間違いです。
Gitの管理対象になるすべてのファイルとフォルダが登録されている場所を、「ワークツリー」と呼びます。（覚えなくても構いません）
また、今からコミットするファイルが登録されているところを、「インデックス」と言います。
そして、インデックスにファイルを登録することを、「ステージング」と言います。
ワークツリーとインデックス｜サル先生のGit入門【プロジェクト管理ツールBacklog】
https://backlog.com/ja/git-tutorial/intro/04/
ステージングされていないファイルは、コミットされません。
そのため、変更をコミットする際には、必ず「ステージング」を行う必要があります。
先程からコミットのときに実行しているgit addは、実はステージングをするコマンドです。
このgit addコマンドは、
$ git add <ステージング（今からコミットしたい）ファイル名>
という構成になっています。
前回のコミットから変更のあったすべてのファイルをステージングしたい、という時は、
$ git add --all
実行すると、前回のコミットから変更のあったすべてのファイルをステージングします。
git status
現在のインデックスの状態や、変更されたファイルを確認するためのコマンドがあります。
$ git status
サンプルですが、このように表示されます。
このコマンドは、コミットをする前にインデックスを確認する用途に使えます。
そうすることで、コミットされてほしくないファイルがコミットされることを未然に防げます。
（個人情報とか認証情報とか。）
認証情報が含まれたコミットをpush(後述します)すると大変なことになります。
（筆者は何度かやらかしています）
▼ 参考
GCPで約800万円の請求がきた話｜mun｜note
共同開発やリモートリポジトリ（後述）を用いた開発を行う場合、git statusを確認するクセをつけましょう。
ここだけ覚えて！今回のまとめ！
✅ Gitでは、1つのプロジェクトを「リポジトリ」という。
✅ リポジトリを操作するときには、そのフォルダにcdする。
✅ Gitでは、作業履歴を「コミット」として保存する。
✅ 変更したファイルをすべてコミットする時 → git add . → git commit -m "コメント"
✅ git statusを確認するクセをつけよう。
リンク
次回
NITICNoobsによるGit/GitHub講座 第4回 〜並行世界を創世する〜
第1回 インストール編
第2回 設定編
第3回 実際に使ってみよう-基本技能編
第4回 ブランチ(平行世界)編-1
第5回 ブランチ(平行世界)編-2
第6回 GitHub入門編
第7回 fetch/pull編
第8回 issue/Pull Request編