これでチーム開発も怖くない？何度でも使うgitコマンド集

# はじめに
現場で初めてGitHubでのチーム開発を行った時、個人開発と勝手が違うため苦労しました。社内の新人プログラマーたちもgitやGitHubに四苦八苦している様子だったので、`これさえ知っていれば最低限のGitHubでのチーム開発ができる`という内容をまとめました。
少しでも皆様のお約に立てれば幸いです。

# 自分が今いるブランチを確認したい
```terminal
$ git branch

  develop
* feature/create-about-page
  main
```
ターミナルにローカルブランチの一覧が表示されます。自分が今いるのブランチの横には * が付いています。

# ブランチを切りたい
```terminal
$ git checkout -b {BRANCH_NAME}
```

`BRANCH_NAME` というローカルブランチを作成して、その`BRANCH_NAME`に移動することができます。注意点は実行前に自分が今いるブランチは必ず確認しておくこと。上記のコマンドだと現在のブランチから新たなブランチが枝分かれする形になります。
プロジェクトによりますが、`developブランチ`を育てていくことが多いです。必ず`developブランチ`に移動した上でブランチを切りましょう。

# 変更したソースコードをコミットしたい
```terminal
$ git add .
$ git commit -m "{COMMIT_MESSAGE}"
```
{COMMIT_MESSAGE}には変更した内容が後からわかるように`英語で`コメントしておきましょう。日本語でコメントすると微妙な顔をされてしまいます。

# 直前のコミットを打ち消したい
```terminal
$ git reset --hard HEAD^  # commitした変更内容もろとも打ち消す
$ git reset --soft HEAD^  # commitした変更内容はコード上に残したままcommit操作のみを打ち消す
```
一度commitしたあとに「モジュールの順番を変えたい・・・」であるとか「リファクタリングできる箇所を見つけて、さっきのcommitに含めたかった」といったことが時々あります。そんなときは`reset`コマンドを使ってみましょう。
言うまでもなく、オススメなのは`--soft`オプションの方です。

# ブランチをリモートリポジトリにプッシュしたい
```terminal
$ git push origin {BRANCH_NAME}
```
origin(リモートリポジトリのこと)に対して{BRANCH_NAME}というブランチをプッシュする、という意味です。プッシュしたらプルリクエストを作成してチームメンバーにレビューしてもらいましょう。
プルリクエストの作成は記事のテーマからそれるので省きます。

# プルリクがマージされたのでローカルにその変更を取り込みたい
```terminal
$ git checkout develop
$ git pull
```
`develop`ブランチを育てている場合はこのようにします。たまに`main`ブランチを育てていくというトリッキーなプロジェクトもあります。その際は`develop`を`main`に読み替えてください。
pullコマンドは、変更内容の取得とマージを一息に実行してくれるコマンドです。pullコマンド巻き戻すのは非常に骨が折れるため、実行前にはよく「本当にマージさまでされて大丈夫なのか」と自問自答しまくりましょう。

# チームメンバーのプルリクを自分のローカルリポジトリに取り込んで動作確認したい
```terminal
$ git checkout develop
$ git pull --prune
$ git checkout {BRANCH_NAME}
```
developブランチを育てている場合です。上記を実行するとプルリクが作成されたマージ前のブランチをローカルに取り込むことができます。
ここでもdevelopブランチは適宜読み替えてください。

# 自分がローカルブランチで作業中に他メンバーのプルリクがdevelopにマージされたので変更内容を取り込みたい
```terminal
$ git checkout develop
$ git pull
$ git checkout {BRANCH_NAME}
$ git rebase develop {BRANCH_NAME}
```
ここで行われていることは複雑だと捉えられる気がします。私は最初、`rebase`コマンドによって実行される内容が理解できませんでした。

まず、リモートリポジトリの変更内容とコミット履歴をローカルに取り込みます。そして{BRANCH_NAME}内で自分が行った変更内容を連結させるのです・・・つまりどういうこっちゃ・・・。

私の経験談ではありますが、`rebase`の概念はGitHubを使ったチームを続けていけば意外と掴めてくるものです。

# 不要なローカルブランチを削除したい
```terminal
$ git branch -d {BRANCH_NAME}  # ブランチがマージ済みならば削除できる
$ git branch -d {BRANCH_NAME_A} {BRANCH_NAME_B}  # 一度に複数のブランチを削除できる

$ git branch -D {BRANCH_NAME}  # ブランチがマージ済みかどうかを問わずに削除
$ git branch -D {BRANCH_NAME_A} {BRANCH_NAME_B}  # 一度に複数のブランチを削除できる
```
開発が進んでいくとローカルブランチの数がえらいことになります。ノイズになるため不要なブランチはどんどん削除していきましょう。`-D`オプションをつければ対象ブランチがマージ済みかどうかを気にせず削除していくことができます。

# ブランチでの変更を「一時的に」退避させたい
```terminal
$ git stash

$ git stash apply  # 退避させていた変更内容を呼び出す(退避させた変更はstashのインデックスに残る)
$ git stash pop    # 退避させていた変更内容を呼び戻し、stashのインデックスからは削除
```
ブランチでコードを書いているとき、commitするまでそのブランチから動くことはできません。しかしそんなときに限ってチームメンバーからプルリクのレビュー依頼が入ったりするものです。そんな時は`stash`コマンドを使いましょう。

ブランチでの変更内容を`一時的に`退避させることがブランチを切り替えることが出来るようになります。
(私は複数タスクをこなしていてブランチ切り替える際、 `git stash` → `git stash pop` をよく使います)


# まとめ
以上、難解かつ詳しい説明は極力省き、`何をすればどうなるのか`を中心にまとめました。

gitというものは不思議なもので、勉強するだけでは頭の中に入ってきてくれません。コマンドとそれによって得られる結果を把握し、何度も開発サイクルを回していけば自ずと理解できてくるものです。まずは手を動かしてやってみることが一番ですね。

・・・とはいえ、お客さんのソースコードをいじるわけですから、不用意にコマンドを打ち込むのは恐怖でしかないと思います。チームの先輩に「こういうことをしたいのですが、このコマンドで問題ないですか？」と一言きいてみると安全かもしれません。