2019年8月14日こんにちはカレイドです本当に早いもので、実務へ突入してもうそろそろ1ヶ月が経とうとしています。就職までに会社に依存せずに自分で稼げる力を身に付けたいと思っている。2019/2月からプログラミング,ブログの勉強を開始2019/6月オリジナルアプリManehabiのリリース。MongoDBたったの1ヶ月でも独学と実務で大きく変わることを改めて学びました!そんな中で今回はチームで開発する場合において欠かせない存在Gitについて、学んだことをまとめておきます。checkoutまずはブランチ関係ですね。使うメリットはここにあると行っても過言ではないですね。新しいブランチを作成することをよく、ブランチを切るという風にいうので覚えておくといいです。新しいブランチを切るところから旅が始まります。<branch名>すでにできているbranch間での移動に使います。私の場合はもうそのブランチでの仕事が終わりmasterへ移動するとき。新しい機能を開発している最中に出していたプルリクが帰ってきた時に修正へ行くために使います。<branch名>こちらは新しいブランチを作成して移動するコマンドですね。branch現在ローカルに存在しているブランチが表示されます。時々移動するためのブランチ名を忘れたりするのでこれで確認してコピペしたりなんてしたりしています。<branch名>こちらは存在するブランチのデリートですね。masterにmergeされたブランチを基本的に使うことはないのでデリートしてしまいましょう。なくて強制削除の-Dを使いましょう。commitは当然のこととして、この中でもなかなか学びが深かったです。addを使わなかったんですよね。addを意識的に使ったことがなかったのです。ところが実務に入ると多少なりともcommitをかっこよく綺麗にまとめたい。先輩にレビューをしてもらう(コミット履歴は汚くてもそこまで気にされないチームでした)わけなので、あまりに一度にコミットしすぎてしまうとレビューがややこしくなります。addこいつは処理したファイルの中で特定のものだけcommit準備しますよというコマンドなので一区切りついたところで、順番にまとまりそうな部分をつまみながら部分ごとにcommitをするようにしました。ちなみに、そのファイルの中でコミットを分けたい!なーんてときもVSCODEは簡単に実行できてしまうので本当にVSCODEは便利だなーって思います。pushについてはcommitしたものをそのままリモート側に転送するのでどちらかといえばcommitと一緒によく併用させることが多いですね。ちなみにインターンで行ったどちらの会社もこのpushをした段階でCircleCIというビルド周りの仕事を勝手にやってデプロイの準備を整えてくれるツールが自動的に発火されて、ここで色々Build系周りの不具合がおきていないかチェックされます。ローカルと本番の環境は異なるため、更新をかけるたびにその都度ビルドして問題無いかチェックしてくれるツールは改めて便利だなと思います。pullを使ってます。すればひとまとめに引っ張ってこれて楽ということです。pullの二段階コマンドのようなものですね。はまだ作業しているブランチに対して更新をかけません。リモートから変更されているブランチなどの情報をローカルに落とし込むだけです。origin/<branch名>というローカルのレポジトリに保存されています。origin/<branch名>で今いるブランチに対してそのローカルリポジトリの更新分を反映させることができます。いう時に使うかというと、自分がプルリクをだしてmergeしてもらおうと思った時にconflictを起こしている場合です。解決してからでないとmergeすることができません。mergeしてconflictを解決することになります。conflictを解消せよ!さて、問題なくマージ(変更分を自分のブランチへと取り込む)することができればいいのですが、そうもいかない時があります。一つのファイルを複数人でいじっていたりした場合に同じ箇所を修正しているとこのconflictが発生することになります。僕も最初はうわーみすったらどうしよーとか思ってたのですが、ポイントだけ押さえておけば特に問題ないです。そもそも一つのファイルを複数人でいじるってことがそもそも状況としてあまり起こりえないのかなと。現場だと例えば一つの機能につき1ファイル。それをどこか一箇所にまとめて改めて使うという形になっている可能性が非常に高いです。お気に入りに関数するロジックは別で取り扱っているとイメージしてください。機能開発ごとにいじるファイルも通常は異なるのであまり心配することはないかなと思います。少なくとも2社インターン行った限りではそうでした。私は主に小さな部品ごとに開発を行なっています。それができたらプルリクと行った感じです。ところが、部品だけだと正常に機能しているかまで確認できないので、現状、仮置きしているだけのファイルに対して実際に自分が作ったファイル(コンポーネント)に置き換えることがあります。習慣を表示するコンポーネント、お気に入りを表示するコンポーネントがあった時にこれらは本来一つ一つのコンポ自体は別ファイルに存在します。それらを実際に配置して表示する場合には同一ファイル上にコードを書くことになります。これらを最初に習慣のコンポに置き換えてプルリク、その間にもう一つ、お気に入りのコンポを作成して置き換えてプルリクする状況の想定です。この場合にはまだ、ファイルの更新がmaster上でかかる前に新しいブランチを切って作業を行なっているので見かけ上はお気に入りのコンポを配置する際には習慣のコンポはまだ配置されていないことになります。同一ファイル上で操作を行なっているのでconflictを起こします。結局自分が二回ともそのファイルをいじっているのでどのような形がベストなのかっていうのは基本的には理解しているので問題にはなりません。一つは全員が共通で使うファイル。上の例に出したようにa,b,c,d,eというファイルがあったとして、これらを別々にインポートするのではなく、indexというファイルに全てまとめておき、そこから改めてファイルを引っ張り出すというような形の時ですね。この時は、単純に自分の更新分も相手の更新分も取り入れたいっていう形しかないと思うので両方の変更を取り込んであげればおっけーのことが多いです。それ以外の場合となるとおそらく社員さんとどのような変更が望ましいか話し合うことになる気がしますが、少なくとも自分は一度もこういう場面に遭遇したことはないです。(通称PR)これも一人で開発していたらあまり(滅多に)(まったく)使わないですが、実務でなら毎日のようにこれを使いますね。[FIN]をつけて明示的に終わったことを示すぐらいはしています。中に色々かけるのでそこできっちり何をしたか、開発途中で気になったことに分けてきちんと書いておけば問題はないです。私は練習のために一人でプルリクをだしてやったりしていましたが、プルリクのレビューまでしたことはなかったので、新しい挑戦でした。結論からいうとかなり難しい!他人のコードを読んでロジック理解して、それが正しいか、そのほか気になることとか、見つけることってめちゃくちゃ難しいですね。今までたくさんレビューしてきた先輩ってすごいんだなって改めて思いました。最初は見て気になったところはどんどん書いていくといいんじゃないかなと思います。他人が読んでわかりやすいかどうかなども後の拡張性を考えた時に役に立つことがあります。あまりに大きな問題とかはそこに書き込むより直接相談の方がいいかもしれませんね!まとめ今回は一番学びの大きかったGit編です。個人開発でもどのぐらい開発をしたか、期間などなど。最新記事カレイド1994年生まれ。埼玉出身→20卒で最短で外資ITへ内定し来年4月入社予定です。4ヶ月本気でプログラミングを独学し、オリジナルアプリManehabiをリリース。独学プログラミングの進めや、自分の就活時代の攻略法や学びについてまとめています。コメントをキャンセルメールアドレスが公開されることはありません。*サイト関連記事プログラミングプログラミングでエラーが起きた時の解決法を解説するよ!こんにちはカレイドです。今さっきまでエラーと格闘してようやく解決しました。自作アプリManehabi関連manehabi公開から約1週間たったので現在までに実装した部分をまとめてみたこんにちはカレイドです。徐々に使ってみてくれている方が増えてきています。【Udemy】50講座以上取った筆者がおすすめ英語字幕講座と勉強法を解説してみる.評判のいいPyQに登録して実際に体験してみたのでレビューしてみる。2020年1月6日カレイド1994年生まれ。埼玉出身→20卒で最短で外資ITへ内定し来年4月入社予定です。4ヶ月本気でプログラミングを独学し、オリジナルアプリManehabiをリリース。独学プログラミングの進めや、自分の就活時代の攻略法や学びについてまとめています。