僕がいつも開発でやってるgitの使い方

#はじめに
九州工業大学の学生団体stairsの新代表になりました、やまこーです。今年は例年にはない試みである「一ヶ月チーム開発」をやってますけど、その中でgitの使い方に困っていると勝手に思っています。ここに僕なりのgitの使い方を紹介します。

#開発環境
git： 今回ここで紹介するのはgithubですが、gitlabでも利用できるテクニックです。

# gitとは
バージョン管理システムです。自分の開発の履歴をコミットという形で残す事でバージョンごとに管理したり、チーム開発を行うことができます。ブランチは切ったりつなげたりすることができ、木のような構造になります。

#おおまかな開発全体の流れ
## 開発準備
1. githubでリポジトリを作成し、git cloneしてくる。
2. developブランチを用意する

###githubでリポジトリを作成する
githubで画面右上のプラスボタンからnew repositoryを選択すると以下の画面になると思います。

<img width="734" alt="スクリーンショット 2018-06-17 13.28.19.png" src="https://qiita-image-store.s3.amazonaws.com/0/188539/ccb9e244-7916-c419-65ca-30953f78b1e7.png">

ここでリポジトリ名を入力すると下のCreate Repositoryが緑に色になるので作成可能になります。

 - Description: このリポジトリの説明を入れることができる。
 - Public: 誰でもアクセスして中のソースコードを見ることができる。無料
 - Private:　自分もしくは自分が許可した人のみが見れることができる。有料
 - README: 自分のリポジトリのプロジェクトについて説明する。たとえば、サーバーの場合はAPIで取得可能なデータとそのデータ型などを表記することがある。個人的には開発自体にはあまり関係ないので開発が終わる時に作成してもいい気がする。
 - .gitignore: リポジトリに含まれるもののうち、gitの管理下に置いてはいけないものを意図的にgitの管理から外すファイル。これは**絶対に必要**

その後、githubの画面左上のcodeを開き、Clone or Downloadを選択し、手元にgit clone しましょう。
##開発スタート

```
$ git checkout -b develop
```

2. issueを立てる(githubのホームページ上で）
3. issue番号と紐づくブランチを作成

```
$ git checkout -b 4-header //ヘッダーを作成するというissue（番号が４）がある時
```

4. 3.のブランチで作業
5. developブランチへのpull requestを作成（githubのホームページ上で）
6. 開発が終わる段階で、masterへマージします（githubのホームページ上で）


##.gitignore
これは言語ごとにテンプレートが設定されています。例えば、iOS開発の場合だと、Xcodeデフォルトのプロジェクトのファイルのgitignoreが設定されています。そして、外部のライブラリを利用する場合はCocoapodsもしくはCarthageを利用するので、そのgitignoreの設定を反映させる必要があります。ただし、最初からこのgitignoreにCocoapodsとCarthageのignoreがコメントアウトの形で書いてあるのでそのコメントアウトを随時削除すればいい。他の言語についてはそれぞれ調べてみてください。

また、gitignoreは途中からプロジェクトに追加する場合は、追加された以降のファイルにしか適用されないので、途中からgitignoreを追加する場合は[こちら](http://vdeep.net/gitignore)を参考にしてみてください。

#コミットの仕方
　最初は一回コミットするのも一苦労ですよね、僕も今でもかなり慎重にやっています。なぜなら１箇所でも間違えると最悪のケースでは自分の作業分を泣きながら戻すことになります。

##コミットするまでの流れ
1. git statusで変更ファイルとその状況の確認
2. git add .
3. git statusでcommitしたいファイルが緑色で表示されているか確認してみましょう
3. git commit -m "コメント"
4. git statusでnothing to commitみたいな


```
$ git status
$ git add .
$ git status
$ git commit -m "#33 changed color"
$ git status // nothing to commit みたいになのがでてくればcommit成功です。
```

##git add .
git addでは、コミットしたいファイルをひとまとめにするためにインデックスというものに登録するためのコマンドです。最後の「.」 はコマンドを打ち込んでいるディレクトリより下の階層の変更ファイルすべてを含めますよーということを示しています。したがって、一つのファイルの変更分だけをインデックスに登録したい場合は、

```
$ git add images/icon.png
```

のようにファイルを指定できます。また、どこかのディレクトリのファイルだけを反映させたい場合は

```
$ git add images/
```

のようにできます。この例の場合は、写真とかの変更分だけインデックスに登録することになるので、コミットメッセージに「写真だけを変更しました」と書くことができるのでコミットがスマートになると思います。

##git commit -m "#番号 write a message here"
これはメッセージとともにコミットできるコマンドです。ここで、今回はメッセージにちょっとした工夫をします。それは、メッセージの初めに「#22」のようにシャープと番号をつけて、そのあとにメッセージをつけることで、issueと紐づいたコミットをすることができます。
例を以下にあげます。　自分が「emailViewControllerの作成」というissueを立てていて、その番号が157の時

```
$ git commit -m "#157 email view controller"
```

とすると、githubでissueの詳細を確認した時に以下の写真のようになります。

<img width="602" alt="スクリーンショット 2018-06-16 18.55.33.png" src="https://qiita-image-store.s3.amazonaws.com/0/188539/eee9b1c9-83de-169a-a482-65c0d959d4fc.png">

こうすることで、issueの詳細画面で表示した時にどれくらい進展しているのかなどが一目で確認できます。

##git status
これは現在自分が変更したファイルが表示されます。表示される時に、赤色と緑色で表示されるのでそれぞれここに説明します。
赤色：　 addすらされていない状況のファイル一覧
緑色： 　addされているがcommitはされていない。

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

##間違って意図していないファイルを変更をした場合
checkoutの後には変更を取り消したいファイルへのパスが入ります。例) images/icon.png

```git
$ git checkout images/icon.png
```

もし、全てのファイルの変更を取り消したい場合は、ファイルのパスの部分に「.」を入れます。

```
$ git checkout .
```

##間違って意図していないファイルをgit addした場合
下のやつをやればそのファイルのgit addを取り消すことができます。

```
$ git reset HEAD <file>
```

#ブランチの説明
ブランチ名とそれぞれの役割について説明します。

#ブランチ　about branches
ここではそれぞれのブランチの名前、および使い方について以下の３つに分けて説明します。

##masterブランチ
これはデフォルトですべてのgit管理下のプロジェクトにあるブランチです。
 1. このブランチ上では絶対に開発をしない
 2. 　必ずdevelopブランチからマージされる
 3. 　バグがあるはずがない（バグは他のブランチでちゃんと修正しましょう）

##developブランチ
これは、開発で利用するブランチです、

##番号ーhegehoge　ブランチ
これはgithubにあるissueという部分と紐づいたブランチです。番号をふることでブランチとissueが紐付き、よりプロジェクトの管理しやすくなります。
例として、とあるページのヘッダーを作成するというissueがあり、その番号が２だとすると、 ブランチ名は「2-header」のようになります。

#コンフリクト(conflict)
コンフリクトとは、同じファイルを二人(二つ)以上変更があるとおきるもので、いわば「衝突」です。これを解消すれば、*どちらひとつの変更*を適応すれば解決します。

#最後に
これはあくまで一つのやり方です。最終的には開発チームの皆さんと話し合いながらやりやすいやり方を探すのがいいでしょう。