[PhpStorm]Version Controlの使いかた

# まえがき
この記事は [いえらぶGROUP アドベントカレンダー](https://qiita.com/advent-calendar/2020/ielove-group) 2日目のために書かれた記事です。(遅刻)

今年は、社会人2年目になり、私にも後輩ができました。
私もまだまだ半人前なので(早く一人前になれ)メンターみたいなことをしているわけではないですが、それでも、「こうするといいよ」と、同じ話を何人かにしたので、ここにまとめてしまおうという算段です。

あくまでも、「私はこう使って便利に感じている」という話なので、「絶対にこうしろ」というわけではない。
というのを念頭において読んでいただけると幸いです。

また、「こういう便利な使い方もあるよ」という人はぜひコメントで教えていただけると嬉しいです。


# そもそもVersion Controlとは
ローカルで編集したファイルが一覧で見れたり、gitのログが見れたりする機能です。

PhpStormを開くと、下のほうにタブがあると思います。
見当たらない場合は、`View > Tool Windows > Version Control`から開いてみてください。

そういう私は、配属したててまだ何もわからないころ、先輩に言われるがままに設定をして、今でもあのとき何をしたのかわかっていない(思い出せない)部分もあるので、設定しなくてもできると思っていたらそうじゃなかった、みたいなのは見逃していただけると幸いです、、、

# Version Control > Local Changes
ここでは、ローカルで編集したファイルの一覧を見ることができます。

![2020-12-03_00h11_09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387223/22d448f9-4a2c-d09b-8703-bf4c8fed63a6.png)

モザイクかけてますが、ファイル名の隣にはファイルのパスが書かれています。

## 編集内容を確認する

一覧でどのファイルを編集したかはわかりましたが、さらにどこを修正したのかもわかります。

操作方法は、確認したいファイルを選択して、「Ctrl + D」を押すだけです。
修正前と修正後を並べたウインドウが開くので、そこで差分を確認することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387223/a1332aeb-716f-1849-3b40-004d8f0e982b.png)


`table`を追加したのがわかりますね。
真ん中の行数を表示しているところを左右に動かすことができるので、表示幅の調整も可能です。

また、変更点が複数ある場合は、「F7」を押すと次の変更点までスキップすることができます。

複数のファイルを選択することもできるので、一通り改修が終わったら、コミットする前に下記の手順で自分の改修内容を振り返ることができます。

* Version Control > Local Changesを開く
* Default Cangelistに表示されているファイルを全て選択して「Ctrl + D」
* 「F7」を押して順番に差分を確認

「F7」を押しても次に進まなくなったら確認完了なので、コミットします。

### やっぱここの修正必要ないな、と思ったとき
私はわりとよくやるのですが、修正している途中に「ここも改修範囲でしょ」ととりあえずリファクタリングをしたりします。
(長く提供しているサービスなので、コード規約が整う前のソースコードがたくさん残っていたりするので、、、)

しかし、改修を終えてみると、あまりにも関係ない箇所の修正で、余分な修正だったな、と思うことがあります。
リファクタリングは大事ですが、やりすぎるとレビュアーも何が本来の修正目的なのかわからなくなりますし、修正したものはなかったことにしたいです。

そういうときは、上のキャプチャにある「>>」をクリックします。
そうすると、修正前のコードが修正後のコードに挿入されて、修正をなかったことにすることができます。

### 確認中に追加で修正したいとき
Local Changesで確認中、いらないコメントを消し忘れていることに気付いた、typoを見つけてしまった、くらいの簡単な修正なら、差分を表示しているウインドウで直接修正できます。


メソッドを1つ追加するような修正ももちろんできますが、差分を表す背景が邪魔なので、個人的には軽微な修正しかしないです。

なので、たくさん修正したい場合は、ウインドウの左上にあるこのマークをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387223/0d7664a1-71a6-6ab0-7bb8-b44cc56804e7.png)

ここをクリックしていると、該当箇所を本体(?)のPhpStormで開くことができるので、普段どおりに修正すればOKです。

## コンフリクトを解消する

コンフリクトした場合、Default Changelistの下層にMerge Conflictsというチェンジリストができ、変更したファイルの一覧がそこに移動します。
（ファイル名の部分はキャプチャに入れていませんが、、、）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387223/b018f7f6-e1bc-96c4-6f06-7d7c0c3552d6.png)

ここで「Resolve」をクリックするとコンフリクトしているファイルの一覧がポップアップで表示されます。
ファイル名をダブルクリックするとコンフリクトの内容が表示されるので、「>>」や「<<」をクリックして正しいコードに修正します。

(公開できるソースコードを用意する手間を惜しんだので、想像で補うか、実際にその場面になったときに確認してください、、、)


# Version Control > Log
ここでは、プロジェクト全体のgitの履歴をコミット単位で確認することができます。

さすがに会社のプロジェクトのキャプチャを貼るわけには行かないので、家で気が向いたらキャプチャを取ろうと思います、、、、

が、キャプチャがないとわかりにくさしかないと思うので、PhpStormが使える人は実際に操作しながら「こういうことか～」などと思ってくれたら幸いです。
(本当はこれを書いている途中でPhpStormが固まりました。この先書ききる自信がありません。)

## レビューをするとき
プロジェクト全体のlogが確認できるので、ここからレビューをすることもできます。

ブランチを選択するところがあるので、そこをクリックしてレビューしたいブランチを入力すると、ブランチで絞り込むことができます。
入力フォームがあるわけではないので戸惑うかもしれませんが、思い切って入力してみると行けます。
(というかPhpStormって、入力フォームはないけど入力したら絞り込めるよ、みたいなのが多い気がする)


コピペも使えるので、私はいつもgitlabの画面上でブランチをコピーして、コピペでブランチを絞り込んでいます。

それでもレビューしたいコミットが見つからない場合は、書いた人の名前やコミットメッセージでも絞り込みができます。

レビューしたいコミットを見つけたら、そのコミットを選択して「Ctrl + D」を押します。
そうすると、 Local Changesと同じように差分を並べたウインドウが開くので、「F7」を押して順番に差分を確認していきます。

複数のコミットを選択して、コミット数の多い案件のレビューもすることができます。

# まとめ
アドベントカレンダーのネタとして、今年を振り返られる且つ人の役にたちそうなもの、ということで複数人に説明したことのある機能について書いてみましたが、皆さんお察しの通り途中で力尽きました笑

テーマのはずのPhpStormが固まった時点で終わりです笑

この記事を書いていて一番の学びは、「アドベントカレンダーは担当日になる前に用意しておくこと」です。

まあそれはおいておいて、この記事で何が言いたかったかというと、
**コミットする前に自分の案件のレビューをしよう**ということです。

これ自体はいろんなところで言われているし、やっている人もいると思いますが、ブラウザでマージリクエストを出して、そこで差分を確認するのではなく、PhpStormで確認したほうが差分もわかりやすいし修正もすぐできるしとっても便利です。

他の人にレビューを依頼されたときも、PhpStormでやったほうがファイル全体を開くので処理の流れがわかりやすいですし、
スペースが半角か全角か、なんてところまで確認できます。(別途設定が必要ですが)

レビューの仕方、なんて教わる機会もそんなにないと思いますので、この記事を参考に、
レビューを依頼する人は、事前に自分で確認してレビュアーの負担を軽く、
レビューをする人は、より見やすい方法で効率よく指摘点を見つけられるように
なってもらえたらなと思います。

# 蛇足
私は、 Version Control > Log で差分表示ができると知る前、
レビューするブランチにチェックアウト→MRに表示されている変更ファイルを開く→アノテートを表示して上から修正箇所を探し出す
という超非効率な確認をしていました。

こんな悲劇が二度と起こらないことを祈っています。