ローカルリポジトリでGitの練習

バージョン管理をする箱を作る

Gitはバージョン管理をしてくれる機能があるが、その管理をするための入れ物が必要である。それをリポジトリと言う。

リポジトリとは

リポジトリとは、Gitの管理下にあるファイルやディレクトリの変更履歴を保管しておく入れ物。
投稿画面

リポジトリにはローカルリポジトリとリモートリポジトリの2種類がある。

ローカルリポジトリ

ローカルリポジトリとは、自分のPC上（ローカル環境）に置くリポジトリのこと。自分のPC上にあるファイルやディレクトリのバージョン管理をしたい場合に用いる。

リモートリポジトリ

リモートリポジトリとは、外部のサーバなどのネットワーク上に置くリポジトリのこと。ネットワーク上に置くことで複数人で管理下のファイルやディレクトリを共有することが出来る。複数人でサービスを開発するときにはリモートリポジトリが必須である。リモートリポジトリを介することで、複数人が同じアプリケーションを開発することができる。

まずはローカルリポジトリのみを操作する。

ローカルリポジトリを作成

sampleディレクトリをGitで管理するようにすることで、sampleディレクトリにローカルリポジトリを付与することができる。

現状ではsampleディレクトリはGitで管理されている。Gitで管理されているかどうかは、当該ディレクトリに.gitという隠しディレクトリが存在しているかどうかで判断することができる。

ターミナル

1
2
3

$ cd ~/projects/sample  #sampleディレクトリに移動
$ ls .git  #隠しディレクトリである.gitがあるかどうか確認
ls: .git: No such file or directory

そのようなディレクトリは無いとエラーが出る。

ターミナル

$ git init  #当該ディレクトリをGitの管理下に置く
Initialized empty Git repository in /Users/username/projects/sample/.git/
$ ls .git  #隠しディレクトリである.gitがあるかどうか確認
HEAD  config  hooks  objects  refs

上記のようにgit initコマンドを実行すると、.gitディレクトリが現れ、中に何かしらの情報が入っていることがわかる。すなわち、sampleディレクトリにおいてgit initコマンドを実行することで、sampleディレクトリはGitで管理できるようになる。

git init

新たにGitで管理したいディレクトリ（今回の場合はsampleディレクトリ）において実行すると、隠しディレクトリである.gitが作成され、Gitで管理できるようになる。Gitで管理できるということは、今回で言うsampleディレクトリに対してリポジトリが付与されていること。すなわち、「ディレクトリがバージョンを記録しておく入れ物を携えた」ということになる。

バージョンを記録する台に、変更修正を登録する

リポジトリを作成して、バージョン管理の準備が整った。Gitにおけるバージョン管理の流れは以下のとおり。

1. 変更修正が一覧になっている
2. 同じバージョンとして記録したいデータを抜きだして登録する
3. バージョンを記録する

この内の「2. 同じバージョンとして記録したいデータを抜きだして登録する」場所のことをインデックスという。

インデックスとは

バージョンを記録するためにファイルを一時的に登録する場所。インデックスに登録されているファイル群の変更が記録される。つまり、同じバージョンとして記録したい編集についてはまとめてインデックスに追加し、このタイミングでは記録したくない編集についてはインデックスに追加しない。

アプリケーションの全てをインデックスに追加

まずはどのファイルがインデックスに追加することができるのか確認。

ターミナル

$ git status #現状を確認する
On branch master
No commits yet
Untracked files:
    (use "git add <file>..." to include in what will be committed)
        sample.rb
        site/
nothing added to commit but untracked files present (use "git add" to track)

ここではUntracked files以降に注目するとsample.rbとsite/という2つのファイルまたはディレクトリが記載されている。この2つがインデックスに追加することができるもので、この2つについては特に変更修正は加えていないが、そもそも初めてGitで管理することになったファイルなので、「新規ファイル」として変更修正の対象になっている。

Untracked files:の中に、DS_Storeというファイルも現れることがあるが、関係の無い自動生成のファイルなので無視してOK

まずは順番にインデックスに追加していく。

ターミナル

$ git add sample.rb #sample.rbをインデックスに追加
$ git status
On branch master
No commits yet
Changes to be committed:
    (use "git rm --cached <file>..." to unstage)
        new file: sample.rb
Untracked files:
    (use "git add <file>..." to include in what will be committed)
        site/

するとsample.rbが移動したことがわかる。siteディレクトリはインデックスに追加していないのでそのまま残っている。siteディレクトリを今回記録しないのであればこのまま次のステップに進むが、今回は分ける必要は無いのでsiteディレクトリもインデックスに追加しておく。

ターミナル

$ git add site #siteディレクトリをインデックスに追加
$ git status
On branch master
No commits yet
Changes to be committed:
    (use "git rm --cached <file>..." to unstage)
        new file: sample.rb
        new file: site/style.css
        new file: site/test.html

site/style.cssとsite/test.htmlはsiteディレクトリ内に既に存在していたファイル。

git status

インデックスに追加されている変更修正、されていない変更修正を確認することができる。

git add

インデックスに追加して、変更修正記録の対象とすることができる。

バージョンを記録

バージョンを記録すべき変更修正がインデックスに出揃ったので、これらを実際に記録していく。以下の3番目のステップ。

1. 変更修正が一覧になっている
2. 同じバージョンとして記録したいデータを抜きだして登録する
3. バージョンを記録する

このバージョンを記録する作業のことをコミットという。

コミットとは

インデックスに追加された変更修正をバージョン記録する操作のことを、コミットと言う。

git commit

インデックスに追加されている変更修正を、コミットするためのコマンド。-mのオプションはコミットメッセージと呼ばれ、どのような変更を行ったのかメモを残せる。このコミットメッセージをしっかり書くことによって、「いつ、どのような修正をしたのか」が明瞭になり、いざという時に遡りやすくなる。

コミット

まずはgit statusで現状を確認。

ターミナル

$ git status
On branch master
No commits yet
Changes to be committed:
    (use "git rm --cached <file>..." to unstage)
        new file: sample.rb
        new file: site/style.css
        new file: site/test.html

Changes to be committed:という記載の後にインデックスに追加されたファイルが並んでいる。これは日本語に直訳すると「コミットされる変更」と読める。つまりインデックスに存在する、コミット待ちの修正ということ。

ターミナル

$ git commit -m 'initial commit' #'initial commit'というタイトルを付けてコミットする
[master (root-commit) cf63881] initial commit
    3 files changed, 18 insertions(+)
    create mode 100644 sample.rb
    create mode 100644 site/style.css
    create mode 100644 site/test.html

すると先程インデックスに追加されていた3ファイルがコミットされた。git statusを確認。

ターミナル

1
2
3

$ git status
On branch master
nothing to commit, working tree clean

nothing to commitとある。すなわち、「コミットの対象となっている変更修正は無いよ」というメッセージ。

上記でエラーが出たら、以下の対策を行う

上記でコミットをする際、Please tell me who you areというエラーが出た場合は、以下の作業を行ってから再度コミットを行う。

①GitHubに登録する

GitHubというサービスの登録を以下のカリキュラムに沿って行う。アカウントの登録のみ行う。

②以下のコマンドを実行する

GitHubに登録した、usernameとemailアドレスを以下のようにコマンドで入力。

ターミナル

1
2

$ git config --global user.email "you@example.com" #GitHubに登録したメールアドレスを入力します
$ git config --global user.name "YourName" #GitHubに登録したusernameを入力します

上記が完了したら、再度コミットを行う作業を実行。

Gitのログを確認

Gitのログとは

コミットの履歴のことを、Gitにおいてはログという。

ログを確認

ターミナル

$ git log #コミットのログを確認する
commit cf638816a5840cdfb43d89f1441630afd5752bf8 (HEAD -> master)
Date: Wed Jun 19 17:14:37 2019 +0900
    initial commit

上記のような形で表示される。initial commitという名前のコミットを、2019年6月19日に行ったことがわかる。また、commit cf638816a5840cdfb43d89f1441630afd5752bf8という文字列はこのコミットのバージョン番号（コミットID）。

git log

コミットの履歴を表示するための操作。様々なオプションが存在し、より詳細な情報を表示することも可能。

コードを変更修正してコミットしてみる

これが一通りコミットまでの流れだが、これまでに操作を行ったのは最初の新規ファイルのコミットだけである。実際にコードに修正を加えて、コミットまでしてみる。

変更修正を加える

sample/sample.rbを修正。

sample/sample.rb

def hello
  p "hello, Git."
end
hello

git add する

次に修正をインデックスに追加。

ターミナル

$ git status #変更修正状況を確認
On branch master
Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
        modified: sample.rb
no changes added to commit (use "git add" and/or "git commit -a")

$ git add . #インデックスに追加

$ git status #コミット待ちの変更修正があることがわかる
On branch master
Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
        modified: sample.rb

都度ファイル名を指定するのは面倒なので、git add .とする。.は「全て」という意味。git statusで列挙される変更修正全てを一度にインデックスへ追加できる。

git commit する

コミットメッセージはreplaced the word in sample.rbとする。日本語でもコミット出来るが、なるべく英語で書くようにする。

ターミナル

1
2
3

$ git commit -m 'replaced the word in sample.rb'
[master c42d66f] replaced the word in sample.rb
1 file changed, 2 insertions(+), 2 deletions(-)

git logでログを確認

commitの履歴を確認。

ターミナル

$ git log
commit c42d66fd654a0a76bfcc5b87c3e3228ad73c00df (HEAD -> master)
Date: Wed Jun 19 17:44:03 2019 +0900
    replaced the word in sample.rb

commit cf638816a5840cdfb43d89f1441630afd5752bf8
Date: Wed Jun 19 17:14:37 2019 +0900
    initial commit

先程のコミットが追加されたことがわかる。

なぜaddしてcommitするのか

毎回インデックスに登録してからコミットするのは、なんだかひと手間多いように感じてしまうかもしれない。なぜadd→commitの手順を経る必要があるのか、その答えはインデックスという概念が無い状況を想像してみるとわかる。

上図において、インデックスの概念が無い場合では、コードを書く作業とGitの操作とを行ったり来たりする必要がありそう。これでは効率のいい仕事はできない。

一方、インデックスの概念があれば、一気にコードを書いて、後からバージョンごとに選別する（インデックスに登録する）という流れが可能になる。コードを書く作業とGitの操作を行ったり来たりすることはなくなり、効率の良い仕事ができそうである。

hiyoko-programingの日記

プログラミングを勉強したてのひよっ子。　　　エンジニア目指して勉強中。

Git

ローカルリポジトリでGitの練習

バージョン管理をする箱を作る

リポジトリとは

ローカルリポジトリ

リモートリポジトリ

ローカルリポジトリを作成

git init

バージョンを記録する台に、変更修正を登録する

インデックスとは

アプリケーションの全てをインデックスに追加

Untracked files:の中に、DS_Storeというファイルも現れることがあるが、関係の無い自動生成のファイルなので無視してOK

git status

git add

バージョンを記録

コミットとは

git commit

コミット

上記でエラーが出たら、以下の対策を行う

①GitHubに登録する

②以下のコマンドを実行する

Gitのログを確認

Gitのログとは

ログを確認

git log

コードを変更修正してコミットしてみる

変更修正を加える

git add する

git commit する

git logでログを確認

なぜaddしてcommitするのか