生活する上で最低限困らない程度のGitコマンド【随時更新】

# 初めに
これまでSource treeやGitHub Desktopなど何かにつけてGUIに頼ってきた。
でも、そろそろGitコマンドを使いこなしてターミナルから開発を進めたい！
そう決心して自分のプロジェクトをGitコマンドを使いながら作り上げるつもりでいます。

その過程で学習したGitコマンドをまとめていきます。
そうは言ってもすでに先輩方が素晴らしくわかりやすい記事を挙げてくれているので、一から説明するよりはざっくりした説明と自分が参考にした記事をセットで紹介する形式でいきます。


# Gitコマンド
## git init
すべてはこのコマンドから始まります。
ローカルリポジトリを作るコマンドですね。

## 確認系
### git status
ワーキングツリーで変更されたファイルの一覧を教えてくれます。

### git log
コミットログを確認します。

### git log --graph
コミットログを縦グラフで表示します。

### git log --decorate
コミットログのHEADの位置を明示する

### git diff
変更されたファイルの差分を教えてくれる

### git diff --cached
`git add`したあとcommit前の差分を確認する

## ワーキングツリーの変更を取り消す
### git checkout .
ワーキングツリーの変更を全て元に戻す

### git checkout ディレクトリ
特定のディレクトリ以下を元に戻す

## git add
ワーキングツリー（ローカル）での作業をインデックス（コミットの対象を管理する場所？）に上げるコマンド。
インデックスに上げたもたものをコミットすると、ローカルリポジトリに反映される。

### git add .
ワーキングツリーに新規作成されたり変更されたファイルをインデックスに上げる

### git add -u
一つ前と最新の変更があった部分だけをインデックスに上げる。
新しく作成したファイルはインデックスには上がらない。

### git add -A
新規作成、修正、削除されたファイルを全てインデックスに上げる

上の3つのaddについては、この記事とかで学んだ
[git add -A と git add . と git add -u の違い](http://nekova.hatenablog.com/entry/2013/02/20/013909)

### git add filepattern
ファイル名を直接指定したり、`*.rb`のようにワイルドカードを使って該当するファイルを全てインデックスに上げることができる。

### git add -p
多く編集したけど、コミットでは分けたいというときにおすすめ。

これらの記事がわかりやすい
[横着で神経質な私とあなたに贈るgit add -p](http://qiita.com/crifff/items/1abf08bca4ce51db4775)
[Gitで部分的にコミットする方法](http://qiita.com/miyohide/items/79ab0ff3b3852289a6be)
細かいオプションはこの記事が説明してくれている
[git add -pをさらに分割する](http://d.hatena.ne.jp/ken_c_lo/20130216/1361035601)
[横着で神経質な私とあなたに贈るgit add -p](http://qiita.com/crifff/items/1abf08bca4ce51db4775)

コマンドでs（手動でハンクを修正するコマンド）を選択したときの振る舞いはこの記事が詳しい
[git add -p のときの e(手動編集)](http://sotarok.hatenablog.com/entry/20111208/1323227088)


## コミットを修正する
### git commit --amend
直前のコミットメッセージを修正できる。
このコマンドを実行すると、エディタが立ち上がるのでよしなに修正してエディタを終了する。

### git add → git commit --amend
もし、一つ前のコミットに含めるべきファイルが漏れていた場合。
git addで漏れたファイルを追加してからgit commit --amendを実行すると漏れたファイルも含めた状態で前のコミットのコミットメッセージを修正できる。
つまり、前のコミットを修正できるということ。ついでにコミットメッセージも修正できちゃう。

### 2つ以上前のコミットを修正する
2つ以上前のコミットメッセージを修正するには、git rebase -iを使用します。
手順は以下。

1. git logでコミットのログを確認する。
2. 直近のコミットを1として、修正したいコミットが何番目か確認する。（0から数え上げるのではないことに注意）
3. git rebase -i HEAD~◯（◯には先程確認した数字が入る）3つ前のコミットメッセージを修正したければgit rebase -i HEAD~3となる
4. エディタが立ち上がり、修正したいコミットの「pick」を「edit」に修正する。
5. git commit --amendを使ってコミットを修正する
6. git rebase --continueを実行する

この記事が詳し
[Gitのコミットメッセージを後から変更する方法をわかりやすく書いてみた](http://www.granfairs.com/blog/staff/git-commit-fix)

## git rm ファイル名
ファイルごと削除する

### git rm -r ディレクトリ名
ディレクトリごと削除するとき

### git rm --cached ファイル名
ファイルを残したままgitの管理対象から外す


## コミットを取り消す
### git reset --hard
直近のcommitとaddとcommit, addしたファイルの変更が全て取り消される。
resetには、ワーキングツリー、インデックス、ローカルリポジトリが関わってくるが、この記事が全てを教えてくれます。
[[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法](http://qiita.com/shuntaro_tamura/items/db1aef9cf9d78db50ffe)
### git reset --mixed
直近のcommitとaddを取り消す。

### git reset --soft
commitのみ取り消し

## ブランチ系
### git branch
ブランチ一覧を確認する

### git branch ブランチ名
新しいブランチを作成する


### git checkouot ブランチ名
ブランチを切り替える

### git chckout -b ブランチ名
ブランチを作って、作ったブランチに切り替える
### git branch -m ブランチ名 新しいブランチ名
ブランチ名を変更する

### git branch -d ブランチ名
ブランチを削除する

## リモートリポジトリ系
### git remote add 名前 リモートリポジトリのURL
リモートリポジトリとローカルリポジトリを紐付ける
名前はoriginのことが多いのかな？

### git remote -v
現在のリモートリポジトリのアドレスを確認できる

### git remote set-url origin 新しいURL
リモートのリポジトリ先を変更する


### git push 名前 ブランチ名
リモートリポジトリにプッシュするときに使う。
`git push origin master`で初めによく使う。
このコマンドの意味は、originというリモートリポジトリのmasterブランチにプッシュするという意味。

## コミットしていないファイルの変更を退避させる
### git stash
コミットしていない状態の変更ファイルをいっっっったん退避させてくれるので便利
使い時（他にあったらおしえてください）
- 気づいたら前のブランチで新しい作業をしていた
- 作業中に急に新しい実装を依頼された

### git stash list
退避（git stash）したものの一覧を確認できる。
git stashは複数回使用可能ということ。

```
$ git stash list

stash@{0}: WIP on install-slim: 4301868 Convert erb files to slim
```

結果の見方は、こう

```
stash名: WIP on stashを行ったブランチ名: ハッシュ コミットコメント
```
ハッシュ、コミットコメントはstashを行った時のHEADのものになる

### git stash list -p
リストに加えて変更履歴も確認できちゃう。

### git stash apply スタッシュ名
stashした変更を取り出す。

### git stash drop スタッシュ名
stashを指定して消せる。

git stashはこの記事を読んだ
[変更を一時的に退避！キメろgit stash](http://qiita.com/fukajun/items/41288806e4733cb9c342)
## 最後に
コマンドをある程度使えるようになったら、コミットの切り分けやコミットメッセージに頭を悩ませることになる（自分はなった）
英語がめちゃめちゃできるわけではないので、できる人の真似をしてコミットメッセージ書けば良いと思う。
これとか読んで

- [GitHubで使われている実用英語コメント集](http://qiita.com/shi_chicken/items/a5f922a3ef3aa58a1839)
- [Gitのコミットメッセージの書き方](http://qiita.com/itosho/items/9565c6ad2ffc24c09364)