Gitを使った開発のイメージをつかもう

#はじめに
この記事はstairsのgit勉強会１日目での内容を記事にしたものです。
ここでは、記事の流れに沿って実際に手を動かすことで、開発経験の浅い人でもGitを使って開発するイメージを掴んでもらうことを目標にしています。
ですのでGitについてわかりやすくまとめた記事ではないのでご注意ください。

#1. Gitについて
##Gitとは
wikipediaによると
>プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システム

うーん、よく分からない。
##結局、Gitで何ができるの？
###**ファイルの変更履歴が管理できる**
Gitを使えば、「◯月◯日に、◯◯さんが◯◯を変更した」という変更履歴を管理できるので、ファイル名をいちいち変更して保存しておく必要がなくなります。

ファイルが増えないので、自分のフォルダがすっきりしますね。
###**過去のファイルに戻せる**
ファイルを編集していて、「あ、やっぱり変更前に戻したいな」って時ありますよね。
Gitを使えば、変更履歴をそれぞれ管理しているので、いつでも任意の時点のファイルに戻せます。
###**チームで共有できる**
ネット環境を使えば、同じチーム内の仲間とファイルの変更履歴などが共有できます。
複数人で仕事をやる時に起こりがちな問題なども回避することができます。

参照：<a href = https://www.sejuku.net/blog/5756>【絶対理解できる】Gitとは？特徴やできることまとめ！</a>

#2. Gitのインストール
windowsユーザーの方は以下のサイトを参考にGitをインストールしてください。
<a href =https://prog-8.com/blogs/git-preparation-windows>【Windows】Gitの環境構築</a>
macユーザーの方は最初からgitが入っているので何もしなくて大丈夫です。

#3. Gitで開発#入門編〜コミット〜

では早速、Gitを使っていきましょう。
##Gitで管理するディレクトリの作成
任意の場所に作業を行うディレクトリを作成し、移動します。以下は一例です。

```
mkdir git_practice
cd git_practice
```
そして、このgit_practiceディレクトリをgitで管理します。
そのためのコマンドはこれだけです。

```
git init
```
これで、git_practiceをGitで管理できるようになりました。簡単ですね！

##ファイルを作成し、コミットする
コミットとは、ファイルの変更履歴を保存することです。

まだディレクトリの中身は空なので、まずはファイルを作成します。

```
touch index.html style.css
```

作成したら、この**"index.html, style.cssを作成した"**という**履歴**を保存（コミット）していきます。

まず最初に、コミットするためのコマンド**add**と**commit**について説明します。
**<h3>add</h3>**addとは**どのファイルをコミットするのか指定する**ためのコマンドです。
以下のように使います。

```
git add <ファイル名>
```
一度に複数のファイルを指定することもできます。
また、全てのファイルを指定する時は以下のように指定できます。

```
git add .
```


**<h3>commit</h3>**commitとは**何が変更されたかという履歴を保存する**ためのコマンドです。
addで事前にコミットするファイルを指定する必要があります。
以下のように使います。

```
git commit -m "コミットメッセージ"
```
コミットメッセージは、このコミットでの変更内容の説明をするものです。分かりやすく簡潔に書きましょう。  
    
では、以上を踏まえてaddとcommitを実行します。
今回の場合は以下のようになります。

```
git add index.html style.css　　 [git add . でもOK]

git commit -m "create file"
```

これで、**"index.html,style.cssを作成した"**という**履歴**が保存できました。
これで、今後ファイルを変更しても、このファイルを作成したばかりの状態に戻ることができます。




##変更したファイルの確認
様々なファイルを変更していると、「あれ、前のコミットからどのファイルを変更したっけ？このファイルaddしたっけ？」というような状況がよくあります。

ここでは、このようなファイルの状態を**status**コマンドで確認しながら開発を進めていきます。

まずは、それぞれのファイルの中身を以下のように変更します。

```index.html
<!DOCTYPE html>
<html lang="jp">
 <head>
  <meta charset="UTF-8">
  <title>Git Practice</title>
  <link rel="stylesheet" type="text/css" href="style.css">
 </head>
 <body>
  <h1>I am studying Git</h1>
 </body>
</html>
```

```style.css
h1{
color: red;
}
```
index.htmlを開くと以下のようになります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/199827/dddbe880-73ac-a796-a5e4-83147f308367.png)

では、この変更を保存する前にファイルの状態を確認します。

```
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:   index.html
	modified:   style.css

no changes added to commit (use "git add" and/or "git commit -a")
```

この出力は、index.htmlとstyle.cssが変更された`(modified)`けど、まだコミットできる状態`(Changes not staged for commit)`じゃない、ということを表しています。

では、コミットできる状態にするにはどうすればいいでしょう？

そうです、**add**すればいいんです。
`git status`の出力でも以下のように言われていますね。
`use "git add <file>..." to update what will be committed`

では、addしてファイルの状態がどう変わったか確認します。

```
git add index.html style.css
git status
```
すると、以下のように出力が変化します。

```
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   index.html
	modified:   style.css
```

これは、index.htmlとstyle.cssの変更がコミットできる状態`(Changes to be committed)`であることを表しています。

ではお持ちかねのコミットをし、最後にもう一回、コミットした後の状態を確認します。

```
git commit -m "change file"
git status
```
以下のように出力されます。

```
On branch master
nothing to commit, working tree clean
```
直前のコミットからまだ何も変更されてないことを表しています。




##コミットを確認する
次は、これまで行なった２回のコミットがちゃんと残っているか確認したいと思います。　
今までのコミット履歴を確認するには、**log**コマンドを使います。使い方は以下です。

```
git log
```
そうすると以下のように出力されます。

```
commit 6ee3c210838efa15c8daa9cff83f1ccde2d2648e (HEAD -> master)
Date:   Sat May 19 22:20:49 2018 +0900

    change file

commit ce7214dejug2883vh435kk962449jdbu2c879f3c
Date:   Sat May 19 21:55:38 2018 +0900

    create file
```

ご覧の通り、logは先ほどコミットした時の日時とコミットメッセージなどを一覧で表示しています。
これで、ちゃんとコミットが出来ているのを確認出来ました。一安心です。

ちなみに、`commit`の後に書かれた長いランダムな文字列を**コミットID**と言います。
（最新のコミットのでいうと`6ee3c...2648e`）


##直前のコミットの状態に戻る
ここでは、少しgitの恩恵をみなさんに体験してもらおうと思います。  

今この記事を読んでいるあなたを、**おっちょこちょいなエンジニア**だとします。
そんなおっちょこちょいなあなたは、これまで丹念に開発してきたファイルを全て消去してしまいます。

```
rm index.html style.css  
```

なんという悲劇でしょう。これまでの頑張りが全て消えてしまいました。
でも安心してください。あなたにはgitがついています。
gitを使えば、直前のコミットの状態に戻ることで消してしまったファイルを復元することが出来ます。

直前のコミットの状態に戻るには以下のコマンドを実行します。

```
git reset --hard HEAD
```

では、ディレクトリを確認してみてください。
なんと先ほど消してしまったファイルが全て元どおりに戻っています

このような失敗も、たった一つのコマンドで元の状態に戻すことができるのです。**そう、gitならね。**

では、gitの恩恵を体験してもらったところで、直前のコミットに戻るために利用した**reset**コマンドついて軽く説明します。

**<h3>reset</h3>**resetとは、**指定したコミットの状態まで戻ることができる**コマンド。
基本的には以下のように使います。

```
git reset [option] <戻りたいコミットのコミットID>
```
先ほど実行したresetについて解説します。

```
git reset --hard HEAD
```
**HEAD**は**直前のコミット**を表し、**--hard**はソースコードの状態を変更するためのオプションです。
つまり今回のコマンドは、直前のコミットのソースコード(ファイル)の状態まで戻す、ということです。

*ここでは、gitのコマンドについて表面上の簡単な説明しかしません。
あくまでgitを使った開発のイメージが目標ですので、ご理解ください。


#4. Gitで開発#発展編〜ブランチ〜

発展編として、gitの一番の特徴と言っても過言ではないブランチについて簡単に説明します。
##**ブランチとは**
作業履歴(コミット)を枝分かれさせて記録していくためのもの。
分岐したブランチは他のブランチの影響を受けない。
最初にコミットすると**master**というブランチが作成される。


##ブランチの確認
まず、今いるブランチを確認します。

```
git branch
```
すると、`* master`が表示されたと思います。
`*`は作業しているブランチを表しています。
つまり、今はmasterブランチで作業しているということです。
##ブランチの作成
新しいブランチを作成します。
ここでは**practice**というブランチを作成します。

```
git branch practice
```

ブランチを確認します。

```
git branch
```
すると、新たに`practice`が増えていると思います。
しかし、まだ`*`はmasterに付いているのでブランチは変わっていません。

では、practiceブランチに移動します。

```
git checkout practice
```
もう一度、ブランチを確認すると

```
git branch
```

`* plactice`となっているので、practiceブランチに移動できました。


##ファイルの変更
practiceブランチでファイルの変更を行います。

```style.css
h1{
color: red;
}

body{
background-color: yellow
}
```
このように、適当にcssファイルを変更します。


index.htmlも開くとこのようになります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/199827/ccb29acb-8636-82a9-d9d1-9a36512cfe6b.png)


変更したら**add、commit**を行ってください。コミットメッセージは適当に。
**log**コマンドでコミットの確認も行ってください。ちゃんとコミットできてましたか？

では、practiceブランチでの編集がmasterブランチに影響が出ているのか確認します。
masterブランチに移動します。

```
git checkout master
```

cssファイルの中身を確認してみてください。
placticeブランチで変更した内容がmasterブランチでは変更されていません。
  
index.htmlを開いても元に戻ってます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/199827/dddbe880-73ac-a796-a5e4-83147f308367.png)


ついでに、logコマンドで先ほどのコミットが残っていないことを確認してください。



このように、ブランチは他のブランチの影響を受けることがありません。

##ブランチのマージ
最後に、practiceの変更をmasterに取り組みます。

```
git merge practice
```
これでpracticeの変更がmasterに適応されました。
cssファイルの中身を確認してみてください。変わってるでしょ？


このようにブランチを使えば、現在の安定した状況を残したまま、並行して機能追加やバグ修正などができます。
このブランチ機能は個人での開発よりもチーム開発を行う時に威力を発揮します。  

まだあまりブランチの良さがピンとこないと思いますが、今は大丈夫です。
以下のURLを見ればブランチの使い方がイメージできるかも。
<a href= https://backlog.com/ja/git-tutorial/stepup/stepup1_1.html>サルでもわかるGit入門 ブランチとは</a>

#5. まとめ
・gitはファイルの変更履歴を保存できる。 -> addしてcommit
・保存した変更点（過去の状態）に戻せる。 -> reset
・安定した状態を残しつつ、新機能の追加などができる。 -> branch

#6. Gitコマンドチートシート
これまでに使ったgitコマンドのおさらいです。

|gitコマンド                        | 概要               |
|:-------------------------------|:------------------|
|git add <ファイル名>               |コミットするファイルの指定|
|git commit -m "コミットメッセージ"    |変更履歴の保存|
|git status                      |ファイルの状態を確認する|
|git log                         |コミットログの確認|
|git reset [option] <戻りたいコミットのコミットID>|指定したコミットの状態まで戻る|
|git branch|ブランチの確認|
|git branch <ブランチ名>|ブランチの作成|
|git checkout <ブランチ名>|ブランチの移動|
|git merge <ブランチ名>|指定したブランチの変更を現在のブランチに取り込む|

#終わりに
こんな長くて拙い文章を最後まで読んでくださってありがとうございます!

「あぁ、こんな感じでgitを使って開発するんだ」とイメージが出来るようになりましたか？？
そのイメージが出来ていれば、一先ずこの記事の目標は達成です!
お疲れ様です！