こんにちはカレイドです
本当に早いもので、実務へ突入してもうそろそろ1ヶ月が経とうとしています。
簡単なカレイドの自己紹介をしておくと
たったの1ヶ月でも独学と実務で大きく変わることを改めて学びました！
そんな中で今回はチームで開発する場合において欠かせない存在Gitについて、学んだことをまとめておきます。
git branch, git checkout
まずはブランチ関係ですね。git 使うメリットはここにあると行っても過言ではないですね。
新しいブランチを作成することをよく、ブランチを切るという風にいうので覚えておくといいです。
まずは新しいブランチを切るところから旅が始まります。
git checkout <branch名>
すでにできているbranch間での移動に使います。
私の場合はもうそのブランチでの仕事が終わりmasterへ移動するとき。もしくは新しい機能を開発している最中に出していたプルリクが帰ってきた時に修正へ行くために使います。
git checkout -b <branch名>
こちらは新しいブランチを作成して移動するコマンドですね。個人開発でも使うレベルなのでどんどん使って覚えちゃいましょう！
git branch
現在ローカルに存在しているブランチが表示されます。時々移動するためのブランチ名を忘れたりするのでこれで確認してコピペしたりなんてしたりしています。
git branch -d <branch名>
こちらは存在するブランチのデリートですね。もうmasterにmergeされたブランチを基本的に使うことはないのでデリートしてしまいましょう。
ちなみに、間違えてブランチ作ったなんて場合にはおそらく消せないので-d ではなくて強制削除の-Dを使いましょう。
git add, git commit,
まずはみなさんご存知
git add
git commit
は当然のこととして、
この中でもなかなか学びが深かったです。
正直私はVSCODEを使ってプログラミングをしているのであまりgit add
を使わなかったんですよね。 VSCODEならgit addをすっ飛ばして直接コミットできる上、実際そこまでgit addを意識的に使ったことがなかったのです。
ところが実務に入ると多少なりともcommitをかっこよく綺麗にまとめたい。
先輩にレビューをしてもらう（コミット履歴は汚くてもそこまで気にされないチームでした）わけなので、あまりに一度にコミットしすぎてしまうとレビューがややこしくなります。
ところがこまめにCommitすると結局あとでこれってあのコミットに追加じゃんとなるわけでして...
そこでgit add
こいつは処理したファイルの中で特定のものだけcommit準備しますよというコマンドなので一区切りついたところで、順番にまとまりそうな部分をつまみながら部分ごとにcommitをするようにしました。
ちなみに、そのファイルの中でコミットを分けたい！なーんてときもVSCODEは簡単に実行できてしまうので本当にVSCODEは便利だなーって思います。
git push, git pull, git fetch, git merge
続いては
git push
git pull
git fetch git merge
この辺は主にローカルとリモートのブランチ間でのやりとりですねー
git push
git pushについてはcommitしたものをそのままリモート側に転送するのでどちらかといえばcommitと一緒によく併用させることが多いですね。
ちなみにインターンで行ったどちらの会社もこのpushをした段階でCircleCIというビルド周りの仕事を勝手にやってデプロイの準備を整えてくれるツールが自動的に発火されて、ここで色々Build系周りの不具合がおきていないかチェックされます。
ローカルと本番の環境は異なるため、更新をかけるたびにその都度ビルドして問題無いかチェックしてくれるツールは改めて便利だなと思います。
git pull
まぁこれは個人の好みでしかないのですが、基本的にmasterから前歴のcommit分を取ってくるためによくgit pullを使ってます。
理由は開発進めているとだいたいmasterに戻ってくる時にはgit pullしてリモートから差分を取ってくるというイメージがついているからですね笑
特にmasterは勝手に更新されるのでgit pull すればひとまとめに引っ張ってこれて楽ということです。
git fetch & git merge
こちらはgit pullの二段階コマンドのようなものですね。
違いとしては fetch はまだ作業しているブランチに対して更新をかけません。ただ、リモートから変更されているブランチなどの情報をローカルに落とし込むだけです。
この変更分は origin/<branch名>
というローカルのレポジトリに保存されています。 なのでfetchをしてその差分を今のブランチに取り込みたい場合には
merge origin/<branch名>
で今いるブランチに対してそのローカルリポジトリの更新分を反映させることができます。
どういう時に使うかというと、自分がプルリクをだしてmergeしてもらおうと思った時にconflictを起こしている場合です。
解決してからでないとmergeすることができません。こういう時は fetch mergeしてconflictを解決することになります。
conflictを解消せよ！
さて、問題なくマージ（変更分を自分のブランチへと取り込む）することができればいいのですが、そうもいかない時があります。
一つのファイルを複数人でいじっていたりした場合に同じ箇所を修正しているとこのconflictが発生することになります。
ただ、このconflict 僕も最初はうわーみすったらどうしよーとか思ってたのですが、ポイントだけ押さえておけば特に問題ないです。
まず、そもそも一つのファイルを複数人でいじるってことがそもそも状況としてあまり起こりえないのかなと。
現場だと例えば一つの機能につき１ファイル。それをどこか一箇所にまとめて改めて使うという形になっている可能性が非常に高いです。
例えば、私のManehabiでいう 習慣に関するロジック プロフィールに関するロジック お気に入りに関数するロジックは別で取り扱っている
とイメージしてください。
なので機能開発ごとにいじるファイルも通常は異なるのであまり心配することはないかなと思います。少なくとも２社インターン行った限りではそうでした。
私がconflictを起こした時はどういう時か、
私は主に小さな部品ごとに開発を行なっています。そしてそれができたらプルリクと行った感じです。ところが、部品だけだと正常に機能しているかまで確認できないので、現状、仮置きしているだけのファイルに対して実際に自分が作ったファイル（コンポーネント）に置き換えることがあります。
例えば習慣を表示するコンポーネント、お気に入りを表示するコンポーネントがあった時にこれらは本来一つ一つのコンポ自体は別ファイルに存在します。
しかし、それらを実際に配置して表示する場合には同一ファイル上にコードを書くことになります。
これらを最初に習慣のコンポに置き換えてプルリク、その間にもう一つ、お気に入りのコンポを作成して置き換えてプルリクする状況の想定です。
この場合にはまだ、ファイルの更新がmaster上でかかる前に新しいブランチを切って作業を行なっているので見かけ上はお気に入りのコンポを配置する際には習慣のコンポはまだ配置されていないことになります。
つまり、同一ファイル上で操作を行なっているのでconflictを起こします。
でも結局自分が二回ともそのファイルをいじっているのでどのような形がベストなのかっていうのは基本的には理解しているので問題にはなりません。
もう一つは全員が共通で使うファイル。例えば上の例に出したようにa,b,c,d,eというファイルがあったとして、これらを別々にインポートするのではなく、
indexというファイルに全てまとめておき、そこから改めてファイルを引っ張り出すというような形の時ですね。でもこの時は、単純に自分の更新分も相手の更新分も取り入れたいっていう形しかないと思うので両方の変更を取り込んであげればおっけーのことが多いです。
それ以外の場合となるとおそらく社員さんとどのような変更が望ましいか話し合うことになる気がしますが、少なくとも自分は一度もこういう場面に遭遇したことはないです。
最悪失敗した場合は変更分全部取り消してもう一度mergeしなおせば問題なしです！
初めてのconflictは緊張しましたがその１回目だけです！頑張って！
プルリクエスト （通称PR)
これも一人で開発していたらあまり（滅多に）（まったく）使わないですが、実務でなら毎日のようにこれを使いますね。
最初先輩にPRだしといてってきた時はなんのピーアールをするんだ？と思いましたがPRはプルリクエストということでしたw
まぁ特に気をつけることもないですが、基本的には開発途中で方針の確認などは[WIP] work in progress まだ作業中
開発が終わりmergeしてもらうためのレビューは [FIN]をつけて明示的に終わったことを示すぐらいはしています。
まぁ中に色々かけるのでそこできっちり何をしたか、開発途中で気になったことに分けてきちんと書いておけば問題はないです。
こちらは最大に考えることが多かったPR終了時にもらったLGTM（Looks Good To Me)です。
こんな画像が用意されているのが先輩が用意しているのかわかりませんが、毎回画像が変わるのが楽しみの一つですw
プルリクエストのレビュー
私は練習のために一人でプルリクをだしてやったりしていましたが、プルリクのレビューまでしたことはなかったので、新しい挑戦でした。
結論からいうとかなり難しい！
他人のコードを読んでロジック理解して、それが正しいか、そのほか気になることとか、見つけることってめちゃくちゃ難しいですね。
今までたくさんレビューしてきた先輩ってすごいんだなって改めて思いました。
最初は見て気になったところはどんどん書いていくといいんじゃないかなと思います。私もこれってこうじゃないかなーと思っていたら、最初は確かにそうだなってなってよくよく考えてみたらやっぱりあってるってなって、結構複雑だからコメント残しておこうとか、
他人が読んでわかりやすいかどうかなども後の拡張性を考えた時に役に立つことがあります。
あまりに大きな問題とかはそこに書き込むより直接相談の方がいいかもしれませんね！
まとめ
今回は一番学びの大きかったGit編です。
個人開発でもどのぐらい開発をしたか、期間などなど。
また、開発途中で戻りたい時なんかも気軽に戻れるGithubを早いうちから使いこなしておけると便利ですね！
ここで開発したものをとりあえず使えれば困ることはないと思うのでぜひ参考にしてみてくださいね！