前回、GitBucketにリポジトリをつくりました。そして、それをPCへ複製してきましたね。
今回はこの複製してきたリポジトリをつかったファイルのマネジメントについてお話ししていきます。
リポジトリを更新する
myrepoリポジトリには、現在「README.md」というファイルが１つありますよね。
これから次のような変更を加えていくことにします。
- 別のファイルをつくる
- README.mdファイルを更新する
ファイルを追加する
ひとつひとつじっくりいきましょう。まずは別のファイルをつくってみます。
メモ帳でもなんでも結構ですので、次のようなテキストファイルをmyrepoフォルダ内につくってみてください。
Hello!!
これを「first.txt」とでもして保存してください。そうするとmyrepoフォルダ内には２つのファイルがあることになりました。ここで、コマンドプロンプトから次のコマンドを実行してみてください。
git status
いかがでしょうか、何やら英語でメッセージが出てきました。
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
first.txt
nothing added to commit but untracked files present (use "git add" to track)
このメッセージの内容は次のような内容になっています。
masterブランチにいます
あなたのブランチは最新の「origin/master」です。
追跡していないファイルはこちら
（コミットに含めるなら「git add <file>」を使ってください）
first.txt
コミットに追加するものが何もありません。追跡していないファイルがあります（追跡するには「git add」を使ってください）
よくわからないキーワードがたくさん登場してきました。
「ブランチ」「master」「origin/master」「追跡」「コミット」…
また後程お話ししますので、ここでは先ほど作成した「first.txt」が変更として挙げられているんだな、ということだけ覚えておいてください。
ファイルを更新する
では次に、「README.md」を更新してみましょう。メモ帳などのテキストエディタで開いてみると、次のような内容しかありません。
myrepo
===============
これはマークダウンという形式のテキストファイルなのですが、イコール記号が並んだ次の次の行に「this is myrepo.」と追加して保存しましょう。
myrepo
===============
this is myrepo.
上書き保存しましたか？それでは再び「git status」してみてください。
またもやメッセージが出ましたが、先ほどとは少し内容が変わっています。
On branch master
Your branch is up-to-date with 'origin/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: README.mdUntracked files:
(use "git add <file>..." to include in what will be committed)
first.txt
no changes added to commit (use "git add" and/or "git commit -a")
長くなりましたね。最初の2行は全く同じですが、3行目からは違います。
コミットへステージされていない変更：
（コミット内容を更新するには「git add <file>」を使ってください）
（ワーキングディレクトリの変更を破棄するには「git checkout -- <file>」を使ってください）
modified: README.md
追跡していないファイルはこちら
（コミットに含めるなら「git add <file>」を使ってください）first.txt
コミットに追加するものが何もありません（「git add」か「git commit -a」を使ってください）
さらに意味のわからない「ステージ」「ワーキングディレクトリ」というキーワードが登場しました。
変更されたものをステージに上げよう
では変更もひと段落しましたので、少し説明していきたいと思います。
「ワーキングディレクトリ」「ステージ」「コミット」についてです。
Gitにおいてはファイルのマネジメントにおいて４つの状態があります。これらの状態を適切に行き来することで最新のファイルをマネジメントしています。
４つの状態というのは次のものです。
- 最新の状態から変更されていない
- 変更された
- 変更が追跡されていない
- 変更が追跡されている
「ワーキングディレクトリ」「ステージ」「コミット」はこれら４つの状態が置かれている論理的な場所で、１と２の状態にあるファイルが置かれている場所を「ワーキングディレクトリ」と呼びます。そして、３の状態にあるファイルのインデックスが置かれている場所を「ステージ」と呼びます。残る４の状態は保存された状態で、この場所を「コミット」と呼びます。
絵に描いてみると次のようになります。
この図に当てはめてみると、先ほど作成した「first.txt」は上記３の「変更が追跡されていない」状態であり、更新を行った「README.md」は上記２の「変更された」状態にあることがわかります。そして、いずれもワーキングディレクトリに存在しているということになります。
ということでこれらをまとめて「変更」と呼んでしまいますが、これらの変更をリポジトリに登録するために候補者をステージへ上げてしまいましょう。舞台のステージに上がるイメージでいたらいいと思います。スポットライトを浴びますよね。こうしてスポットライトの当てられたファイルについてGitはリポジトリへ変更するようになります。
ではステージに上げましょう。ステージに上げるにはいままでGitがメッセージで繰り返し伝えてきていたコマンドを思い出してください。そうです、「git add」です。
ステージに上がっているメンバーへ新たに仲間入りさせるので「add」ということですね。ということで次のコマンドを実行しましょう。
git add README.md first.txt
これでステージに上がりました。今回は何らメッセージが表示されないので不安になりますね。確認するために再び「git status」を見てみましょう。すると、今度はまた別のメッセージになりました。3行目からを抜粋するとこうなっていると思います。
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README.md
new file: first.txt
どういうことかというと、
コミットされる変更：
（ステージから降ろすには「git reset HEAD <file>」を使ってください）
変更された: README.md
新しいファイル: first.txt
ということです。状態もそれぞれ想定したとおりになっていますね。
ステージに上げたファイルを変更する
あとはコミットを残すだけなのですが、ここで「ステージに上げたんだけど、もうちょっと直したいんだよね…」ということが発生するのは目に見えています。ということで、それもやってみましょう。「first.txt」に新たに行を追加して以下のような内容にしてみます。
Hello!!
myrepo!!
うん…するまでもないような変更ですが、やってみました。これで「git status」してみてください。さらにメッセージが変化していることに気付くと思います。
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README.mdnew file: first.txt
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: first.txt
なんと、同じファイルなのに変更が別モノとして扱われているではありませんか！！
いま行った変更はステージされていないのです。別物だからですね。とすると、このままコミットすると先ほど行った変更は保存されない！？と思うかもしれませんが、その通りです。
さて、再び「git add」することになったのですが、ここで「何を変えたんだっけ」を見たくなりませんか？今回の場合はわかりきっているでのそんなことはありませんが、複数の変更を行っているとステージに上がっているものとどう違うのか気になるところです。
そうした場合は「git diff」というコマンドを実行します。「diff」は「different」の先頭4文字です。つまりは「違い」を発見するためのコマンドです。では「git diff」としてみてください。
diff --git a/first.txt b/first.txt
index 872bf62..4d539b8 100644
--- a/first.txt
+++ b/first.txt
@@ -1 +1,2 @@Hello!!
+myrepo!!
なるほど、「myrepo!!」というのが追加されたんですね！白々しいですが…
「+」で始まっているところが追加されたところです。また、削除された場合は「-」で始まります。このメッセージに「index」というキーワードが登場していますが、これはステージに上がったファイルはそのファイルの状態への索引がつけられるということです。この索引に掲載されているファイルがコミットされるということになります。
最後に「git add .」としておいてください。こうすると、いまここにあるファイルすべてをステージに上げることになります。
この結果、「git status」の結果は変更する前のものと同じになりますし、「git diff」しても何もメッセージが表示されなくなります。
コミットしよう
長々とやってきましたが、やっとコミットします。コミットをGitに命令するには「git commit」で行います。コミットを行うときにはコメントというかメッセージを合わせて残しておくことができます。メッセージを残すには次のように実行します。
git commit -m "first commit."
もしも「-m」オプションを付けずに実行した場合はテキストエディタが起動してきます。設定していればいつも使っているエディタでもメッセージを書くことができますが、そうでない場合はVimというエディタが起動してきます。Vimの操作はやりづらいかもしれませんので、今回は「-m」オプションを付けたほうがいいでしょう。ということでコミットが完了したことでしょう。コミットの履歴は「git log」というコマンドで見ることができます。
commit 1f1d90e3236100af22d2e07993daa2fad2a592cb
Author: m0t0k1 <aaaaaaaa@gmail.com>
Date: Tue Mar 1 11:05:24 2016 +0900
first commit.
this is my first commit.commit b4cca8a8ae8fc78e07367924c1215354637adddb
Author: nalulabo <nalu.labo@gmail.com>
Date: Mon Feb 29 11:33:42 2016 +0900
Initial commit
手元ではこんな感じになりました。
最後に
今回はファイルのマネジメントについて説明してきました。次回はこれをおさらいしつつ、GitBucketへバックアップする方法をお話ししたいと思います。
0コメント