業務で本当によく使うgitコマンド(超絶基本)

いろんなgitのサイトや記事がありますが、自分が業務をgitを触ってみないと使い方は覚えません（僕が実際そうだった）。
研修ではsource treeを使っていましたが、業務で使ったことはないですし、正直コマンドの方が使いやすい。むしろコマンドに慣れてから、source treeなどの便利ツールを使うべきです。
今となってはしみじみそう思います。
この記事では、かなり基本的なことしか書きません。git初心者の方、業務に入ったばかりの社員の方~~、マジgitわかんねぇテヘペロな方~~を対象としています。
環境はmacでやっていますので、一部コマンドは動かない場合があります。

## git init
どこでこれやんの！？
初めてこのコマンドを見たときはそう思いました。
**git管理下に置くディレクトリ内で行う**という暗黙のルールがあります。


```
$ mkdir test

$ cd test

$ git init

$ ls -a

.git
```
`.git`が作成されていればおｋ。これでこのディレクトリ内はgit管理下に置かれます。
**`test`ディレクトリ内でgitを使えるようにする**、みたいな感じで覚えておけばおｋです。
詳しくはググりましょ。
書いておいてあれですが、これ実際ほとんど使わないかもです。

## git clone
これも↑と同じです。こっちの方が業務でよく使う。
**「クローンして取ってきて」**よく言われますね。
git cloneはリモートリポジトリのクローンを作成します。

```
$ mkdir test

$ cd test

$ git clone <リモートリポジトリURL> # 入力するときに<>は要りません！

$ ls
<取ってきたディレクトリ>

$ cd <取ってきたディレクトリ> # 以降test2とする

$ ls -a
.git #他リモートの色々なファイルなどあるはず（多分）
```
リモートリポジトリURLは対象のgithubやgitlabなどにあります。
ここでは具体的には言いませんが `Repositories`のどこかにあるかと。探してみましょ。
git cloneを行えばリモートから取ってきたディレクトリ内に `.git`が作成されるので、git initの必要はありません。
…testディレクトリ作る必要はないかもです。

## git remote add(set-url) origin <リモートリポジトリURL>
これはpushする先を設定します。(pushに関しては後述)
リモートリポジトリのURLを毎回サイトからコピるのめんどいですよね。
だから設定をしますっていうコマンド。
git cloneしてれば元から設定されているので、気にしないでおｋです。

```
$ git remote add origin <リモートリポジトリURL>

$ git remote -v
origin <リモートリポジトリURL> (fetch)
origin <リモートリポジトリURL> (push)
```
`git remote -v`で設定されてるリモートURLを確認できます。
originが設定されていればおｋです。

addではなく、set-urlは**今originに設定してあるURLを別のURLに変更する**ときに使います。
一応流れだけ（あんま使いません）。

```
$ git remote set-url origin <別のリモートリポジトリURL>

$ git remote -v
origin <別のリモートリポジトリURL> (fetch)
origin <別のリモートリポジトリURL> (push)
```

# 以下git cloneした場合でやっていってます

## git branch
いま何のブランチがあるか確認。
概念までは説明できないですが（僕も初心者ですので）ブランチはかなり大事です。
**作業は必ずブランチを切ってやりましょう**と言われるはず。言わない人がいたらむしろヤヴァイ。
普通は機能ごとにmaster/devからブランチを切って行います。

```
$ cd test2 # cloneしてできたディレクトリ

$ git branch
* master

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

$ git branch test_branch # test_branchブランチ作成

$ git branch
* master
  test_branch
```
cloneした状態ではmasterブランチしかありません。
`-a`オプションを使うとリモート先にあるブランチも確認できます（リモートにあるブランチは**赤文字**で表示）。
`git branch ブランチ名`でブランチを作成します。あんま使いませんが一応紹介（無視しておｋ）。
#### 間違えたブランチ名で作成してしまった！

```
$ git branch -D ブランチ名
```
で削除できます。


## git checkout その１
この子は使い方が多数あるのでまずはブランチに関してだけ紹介。
下の方で他の使い方も一緒に紹介していきます。

```
$ git branch
* master
  test_branch

$ git checkout test_branch
Switched to branch 'test_branch'

$ git branch
  master
* test_branch
```
プロジェクトの最初とかはよくブランチを切り替えるときに使います。
ですが、**わざわざ`git branch ブランチ名`でブランチを作成して、`git checkout ブランチ名`をやるのは面倒**です。
なのでオプションの`-b`を使えばこれら二つを同時にやってくれます。

```
$ git branch
  master
* test_branch

# 特に理由がなければ、必ずmasterからブランチを作成すること
$ git checkout master
Switched to branch 'master'

# testブランチを作成し、testブランチに切り替える
$ git checkout -b test
Switched to branch 'test'

$ git branch
  master
* test
  test_branch
```
ブランチでの使われ方はこんな感じですね。

## git status
git管理下のディレクトリ内に**変更ファイルや新規ファイルがあるかどうかの確認**、と覚えておけばおｋです。

以下、コマンドでファイル作成を作成していますが、Finder(mac)やライブラリ(win)でフォルダを開いてファイルを作成しても問題ありません。(IDEとかエディタで作成してもいいよ！)

```
$ touch text.txt

$ git status
On branch test
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	text.txt

nothing added to commit but untracked files present (use "git add" to track)
```
変更されたもの、新しく追加されたものが`untracked files`のところに**赤文字**で入ります。
何が変更されて(作成されて)るのか確認するときに使います、マジでめっちゃ使います。
変更したらすぐに確認する癖をつけましょ。

## git add
よく目にするのが`git add .`ですが、僕はこれはほとんど使いません。
業務ではcommitしないファイルが変更分で出ている場合が多いからです。
個人でgithubなどをやっている人は`add .`で全く問題ないでしょうが。

```
$ git status
On branch test
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	text.txt
	text2.txt

nothing added to commit but untracked files present (use "git add" to track)

$ git add text.txt

$ git status
On branch test
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   text.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	text2.txt
```

commitの対象になるのが、`Changes to be committed:`の欄に来ます。
この場合は`text.txt`ファイルですね。

#### addするファイルを間違えた！

```
$ git reset HEAD
```
でaddする前の状態に戻ります。
複数addしてしまって、**特定のファイルだけ戻したい場合**

```
$ git reset addしたファイル名
```
で戻ります。

## git commit -m "メッセージ"
commitは基本この形で書きます。

```
$ git commit -m "初めてのcommit"
[test 73ab5de] 初めてのcommit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 text.txt
```
これで先ほどaddしたファイルがコミットされました。
gitを怖がる人はここで触るのを恐れます（ぼくがそうだった）。
よく、コミットするファイル気をつけてね！とか言われますが、まだこの段階では大丈夫です。修正は全然効きます。

#### commitメッセージtypoしちゃった☆
```
$ git commit --amend -m "ミスったよ"
```
これで前のコミットのコミットメッセージを変更できます。
うまくいかない人は次の`git log`で説明します。

## git log
コミットしたログを確認します。よく使う。

```
$ git log
commit 73ab5de91e5d228ce44ca71d50075c25d17480d5
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:41:35 2017 +0900

    初めてのcommit
```
git configを今回設定していないですが、設定しているアカウント名などがAuthorのところに表示されます。

####　特定のコミットまで戻りたい！(git reset)
複数コミットされている状態だとします。

```
$ git log
commit 26877ad306493a485ed446bb064de84c04f3dfa6
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 18:00:07 2017 +0900

    三回目のコミット

commit e4fe604843e3d5acff04e38c6f1730a3ecf42337
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:59:41 2017 +0900

    二回目のコミット

commit 609ce036843c373f78543910522150a27f1a0a5e
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:41:35 2017 +0900

    初めてのcommit

$ git reset e4fe604843e3d5acff04e38c6f1730a3ecf42337 # 二回目のコミットまで戻る

$ git log
commit e4fe604843e3d5acff04e38c6f1730a3ecf42337
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:59:41 2017 +0900

    二回目のコミット

commit 609ce036843c373f78543910522150a27f1a0a5e
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:41:35 2017 +0900

    初めてのcommit

$ git status
On branch test
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	text3.txt  # 三回目にコミットしたファイルが変更分として出てくる

nothing added to commit but untracked files present (use "git add" to track)
```
`git reset コミット番号`で指定したコミットまで戻ります。
そのため、そこまでの変更分が`git status`で表示されます。

#### 特定のコミットを消したい！(git revert)
「二回目のコミット」を取り消してみます。

```
$ git log
commit faded1b70c9f407a733b11d1a5120009e77803ef
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 18:00:07 2017 +0900

    三回目のコミット

commit e4fe604843e3d5acff04e38c6f1730a3ecf42337
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:59:41 2017 +0900

    二回目のコミット

commit 609ce036843c373f78543910522150a27f1a0a5e
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:41:35 2017 +0900

    初めてのcommit


$ git revert e4fe604843e3d5acff04e38c6f1730a3ecf42337

Revert "二回目のコミット"

This reverts commit e4fe604843e3d5acff04e38c6f1730a3ecf42337.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch test
# Changes to be committed:
#       deleted:    text2.txt
#


$ git log
commit 9c34db8ead3a0517798caa769cff69490dbafb7b
Author: アカウント名 <アドレス>
Date:   Mon Oct 9 12:16:49 2017 +0900

    Revert "二回目のコミット"
    
    This reverts commit e4fe604843e3d5acff04e38c6f1730a3ecf42337.

commit faded1b70c9f407a733b11d1a5120009e77803ef
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 18:20:35 2017 +0900

    三回目のコミット

commit e4fe604843e3d5acff04e38c6f1730a3ecf42337
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:59:41 2017 +0900

    二回目のコミット

commit 609ce036843c373f78543910522150a27f1a0a5e
Author: アカウント名 <アドレス>
Date:   Fri Oct 6 17:41:35 2017 +0900

    初めてのcommit
```

revertすると、リバートしたログが残ります。
ここで、注意しなければいけないのは、コミットしたファイルの変更部分が消えます（新規ファイルだとファイルごと消える）。
僕はあんまり使いませんが、一応業務で使ったのでご参考に。。。
ファイルが消えるのが嫌なので、僕は特定コミットまでもどってコミットし直しますが。。

## git push

add, commit, pushの流れの最後です。
今のブランチの作業分をリモートにあげるのがpush。

```
$ git branch
  master
* test
  test_branch

$ git push origin test
Counting objects: 8, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 926 bytes | 0 bytes/s, done.
Total 8 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 1 local object.
To <リモートURL>
 * [new branch]      test -> test
```
pushするときは僕はbranchを必ず確認します（一種の癖）
`git push <リモートURL> <ブランチ名>`でリモートにpushできます。
`-f`オプションがありますが、一回pushしてしまったコミットをresetして、もう一度あげるときによく使います(**rejectされてしまうため**)。


## git stash
**変更ファイルの退避**です。そんな難しくないです。
ただ新規ファイルに関してはstashできないので要注意(語弊あり)。
`text.txt`ファイルに変更を加えた状態です。

```
$ git status
On branch test
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:   text.txt

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

$ git stash
Saved working directory and index state WIP on test: 9c34db8 Revert "二回目のコミット"
HEAD is now at 9c34db8 Revert "二回目のコミット"

$ git status
On branch test
nothing to commit, working directory clean

$ git stash list
stash@{0}: WIP on test: 9c34db8 Revert "二回目のコミット"
```
`modified`されたファイルがstashで `stash@{0}`に退避されます。
変更ファイルがある場合、ブランチの切り替えができないですよね。そのときによく使います。
退避したファイルは`git stash apply stash@{0}`で適応できます。
より使い方を知りたい方は、調べてみてくださいｂ

## git checkout その２
checkoutには変更ファイルを変更前にもどす効果もあります。

```
$ git status
On branch test
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:   text.txt

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


$ git checkout text.txt

$ git status
On branch test
nothing to commit, working directory clean
```
変更ファイルの`text.txt`が変更前に戻りました。
もう面倒臭い！全部一旦変更前に戻したい！ってときは`git checkout -f`で全てなかったことにできます。
過去の失敗も`git checkout -f`できたらいいんですけどねぇ〜。

## git reset --hard origin/ブランチ名
リモートにあるブランチの状態をそのまま取ってきます。
**完全にリモートと強制一致なので、変更ファイルは消えてしまいます！要注意！**
なぜかpullできない、fetchできない、面倒臭いってときにこの子をすぐに使います。
特に説明することはないです。


## 以上

よく業務で使うgitコマンドでした。
何かあればコメントお願いします〜。