開発の現場で実際に使われているGitコマンド集

さて今回の記事では、タイトルの通り、私が開発の現場で実際に使っているGitのコマンドの一覧を使用例とともにまとめていこうと思います！

対象としては、新しく開発の現場にアサインされてGitコマンドの概要がまだつかめてないよ！という方や、
エンジニアへの転職活動中だけど実際にどんなGitコマンドが使われているか知りたい！という方々に向けて書いています。

なお、私の所属するチームではぐるなびさんが提唱された__GitFeatureFlow__というブランチ運用の手法を採用しているため、まとめているコマンドに偏りがあるかもしれません。
ご了承ください。m(_ _)m

※GitFeatureFlowに関しては[コチラ](https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama)の記事を参考



# レポジトリをローカルに落としたい時

## git clone

使用例

```
git clone https://github.com/account-name/repo-name.git
```

新しいプロジェクトに参加して、ローカルにレポジトリを落としたい時に使います。


# 実装作業開始時

## git pull

使用例

```
git pull
git pull origin branch_name
```

最新のリモートブランチの内容をローカルブランチに反映させるために使います。

作業に取り掛かる前にローカルのマスターブランチを最新化させるためにサッと使ってしまうといいでしょう。

マスターブランチで最新化をしないでプルリクエストを上げてしまうと後々コンフリクトが発生して面倒なことになる恐れがあるので、
遅くともプルリクエストを作成する段階で（後々詳細は書きますが、）自らの作業ブランチをマスターブランチで最新化しておくのがおススメです。

上記の使用例の1行目と2行目の違いは、
簡単に言えば、リモートブランチで上書く対象を、masterブランチにするか、引数で指定したブランチにするか、という点です。

つまり、`git pull`= `git pull origin master` という風に書けば全く同じ処理が行われます。

`git pull`の詳しい仕組み[コチラ](https://rennnosukesann.hatenablog.com/entry/2018/02/27/233233)の記事で説明されていますので、是非ともご覧ください。


## git switch 

使用例

```
git switch master
git switch -c new_branch_name
```

大抵の場合、マスターブランチを基に新しいブランチを作成し、
それを自らのワークスペースとして手を加えていくことになります。

上記の使用例では、1行目でマスターブランチに移動しており、
2行目のコマンドでは、`-c`のオプションを付け加えることで、マスターブランチをベースに新しいブランチ（ブランチ名：new_branch_name）を作成しています。

なお、`git switch`と似た働きを持つコマンドとして`git checkout`というのもありますが、
タイプするのがやや大変だったり、Tab補完が効くまでに打たなければいけない文字数が若干多いため、`git switch`の方が基本的に便利かと思います。

# 作業完了（確認編）

## git merge 

使用例

```
git merge branch_name
```

「よし！実装終わったぞ！」と思ったのも束の間。
プルリクエストを出すまでにやらなければいけないことがいくつかありますので、一旦落ち着きましょう。

あなたがローカルで作業している間に、リモートのマスターブランチに誰かの修正が統合されている可能性があります。

もしもあなたと"誰か"の修正範囲がバッティングしていた場合、Gitが「どっちの修正を適用してあげればいいかわかんないよ！」と混乱してしまいます（コンフリクト）

プルリクエストを作成して、そのプルリクエストのレビューが終わってからコンフリクトしていたことが分かると、
再度修正した上でもう一回レビューをしてもらわなければいけなくなるので非効率的です。

それを避けるために、プルリクエストを出す前にローカルの作業ブランチをリモートのマスターブランチで最新化しましょう。

`git merge branch_name`は現在の作業ブランチに`branch_name`の内容を反映させる働きがあります。

実際には下記の様な流れで使われます。

```
git switch master
# ローカルのマスターブランチに移動

git pull origin master
# リモートのマスターブランチでローカルのマスターブランチを最新化する

git switch branch_name
# これからプルリクエストを作成するブランチに移動

git merge master
# 最新化されたローカルのマスターブランチの内容と`branch_name`(という名前の)ブランチの内容を統合させる
```

※`git merge master`した後にnanoが開いて「本当にmergeしていいの？」と尋ねられることがありますが、
なにもなければ`ctrl+X`でnanoから抜けてしまって問題ないです。

上記の流れで自らの作業ブランチをマスターで最新化することで、
コンフリクトがあればプルリクエストを作成する前の段階で気づいて対応できるようになります。

## git status

使用例

```
git status
```

このコマンドを使うことで、リモートのブランチとローカルのブランチの間で差分があるファイルをターミナルで表示してくれます。

自分が意図して変更を行ったファイルだけが表示されているか確認するのに使ったり、
後述する`git add`でファイルを選択する時のコピペ用に使ったりしています。

## git diff

使用例

```
git diff
```

上記の`git status`では__ファイル単位__でリモートとローカルの差分を見ることができましたが、
`git diff`では__行単位__で差分を見ることができます。

意図しない変更がないか十分に確認するために使うと良いと思います。

## git restore 

使用例

```
git restore file_name
```

前述の`git status`や、`git diff`で意図しない変更が行われていたファイルを見つけた場合、
`git restore`を使うことで変更が行われた箇所を元の状態に戻すことができます。

もちろん`git diff`を使いながら手で変更を戻していくのも出来ますので、ちょっとした時短テクぐらいに思っていただければ結構かと。


# 作業完了（リモートにプッシュ編）

## git add

使用例

```
git add .
git add file_name
```

ここからは比較的良く知られているコマンドが出てくるかと思います。

まずは`git add`ですが、基本的には上記の2行目の方を使うのがベターという印象です。

`git add .`を使うと、差分があるファイル（`git status`を打ったら表示されるファイル）を全てステージング環境に持って行ってくれるのですが、
`git status`で差分のあるファイルを確かめずに`git add .`を打ってしまうと、意図しない変更が含まれるファイルがリモートに上がってしまう恐れがあります。

そのため、`git status`で差分のあるファイルを確かめたうえで、その際にターミナルに表示されるファイルを一つずつ`git add`の後ろにコピペするように自分はしています。

## git commit

使用例

```
git commit -m "message"
git commit -m --amend "fixed_message"
```

`git commit`を使うと、`git add`でステージングに上がったファイルをまとめて、
リモートに送る用にパッキングしてくれます。

なお、`-m`オプションの後には、チームのメンバーに変更内容が分かるようにメッセージを書きます。

もしも、1行目のコマンドで「間違ったメッセージでcommitしちゃった！」という場合には、
2行目に書いている`--amend`を加えて修正したメッセージを書けばメッセージの修正ができます。

## git push

使用例

```
git push
git push -u origin branch_name
git push --set-upstream origin branch_name
```

`git commit`の後に`git push`をすることで、ようやく、ローカルでの作業内容をリモートに反映することができます。

もしも既にリモートにブランチがある場合（作業開始前にあらかじめリモートに作っていた場合や、既に`git push`していた場合など）は、
`git push`だけで変更を反映できます。

また、今回の例のように、`git switch -c branch_name`等でローカルにだけブランチが存在する場合は、
2行目のコマンド（`git push -u origin branch_name`）の方を使ってリモートへのプッシュ＋対応するリモートブランチの作成を一緒に行う必要があります。

ただ実際には、リモートに対応するブランチが無かった場合でも、
`git push`を打った後に3行目のようなコマンドが表示され、
「リモートにブランチがないからこのコマンドを入力してください！」と教えてくれるので、それをコピペして実行するのでも大丈夫です。

# 自分が今いるブランチを確認する

使用例

```
git branch
```

特に説明も必要ないかもしれないですね笑

現在自分がどのブランチで作業中なのかを表示してくれます。

# 強制的に`git pull`を行いたい

使用例

```
git fetch
git reset --hard origin/master
```

ローカルのマスターブランチを強制的にリモートのマスターブランチの内容で上書きしたい時に使います。

稀に最新のリモートブランチをローカルに`git pull`したときにコンフリクトを起こすことがあるのですが、
ほとんどの場合、作業は最新の状態のマスターブランチから始めるかと思うので、`git pull`で簡単に最新化出来なかったときには上記のコマンドを行うと良いでしょう。

# リモートのブランチを以前の状態に戻したい

使用例

```
git log
git reset --hard {`git log`で確認したcommit_id}
git push -f
```

リモートのブランチの内容を以前の状態に戻したいときに使います。
正確には、コミット単位で状態を元に戻していくことが出来ます。

まずは、`git log`でこれまでの変更の履歴がターミナルに表示されるので、
そこに表示されるコミットメッセージを手がかりに戻したいコミットを見つけてください。

戻したいコミットの場所まで行ったら、当該コミットのID（数字と英字の羅列）をコピーして、
2行目のコマンドを実行してください。

2行目のコマンドを実行することで、ローカルブランチにおいて指定したコミットの状態までファイルの中身が巻き戻るので、
3行目の`git push -f`（`-f`は強制的にプッシュするオプションです）を実行すれば、特定のコミットまで戻すことが出来ます。


# まとめ

今回の記事では開発の現場で実際に使っているGitコマンドをまとめました！

revertやcherry-pickなど、記事内で紹介していないコマンドも他にありますので、興味のある方はそちらもぜひ調べてみていただくと良いと思います！