Gitがしっかりしていれば転職成功率は上がる
僕は、とある企業でエンジニアとして働き、採用にも関わっています。
中側の人間だからこそわかることで、今回は意外と採用で見られるGit(GitHub)の運用について紹介していきます。
エンジニアになろうと行動されている方は既に学習を始めていて、就職活動の際にポートフォリオの提出が必要なことがわかっていると思います。
ポートフォリオでは、使っている技術や完成度はもちろんのこと、Gitのコミットログまで見られることがあります。
そして残念ながら、Gitの使い方がお粗末な初心者の多いこと。。。
初心者のうちは基礎的なことを大事に
1人で開発しているうちは、Git自体そんなに重要に捉えられないと思いますが、就職してチーム開発する時にはとても重要なスキルになってきます。
企業の選考では、そこまで考えているかは別として、Gitがきれいに運用されていることを見る会社も少なくないです。
そして、技術力が高くない初心者ほど、Gitがきれいじゃない場合に落とされることが多くなります。
最低限やったほうがいいこと３選
① コミットメッセージをしっかり書く
これが一番大事です！
gitコマンドでのコミットは以下のようにし、コミットメッセージはダブルクォートの間に書きますよね。
git commit -m "ここに好きなメッセージを書く"× コミットメッセージのダメな例
“テスト”とか、“update”、“コミット”などのメッセージはダメなパターンとして多いです。
なぜダメなのかと言うと、そのメッセージ内容で「どういう変更が行われたか」が全くわからないためです。
チーム開発では複数人で同じソースコードをいじるので、他の人が行った変更が一言でわかることが理想です。
ここで、”update”というコミットがあったとしましょう。何がアップデートされて、どういう影響があるのかもわかりませんし、実際の変更はREADMEのみであった、なんてことになると確認するのが手間でしかありません。
○ コミットメッセージの良い例
良いコミットメッセージは、「変更点が一言でわかること」です。
「git コミットメッセージ」とかでググると、理想的なメッセージの書き方がいくつも出てくると思いますが、チームによって細かい部分は変わります。
よく用いられる、メッセージに書くべき内容としては以下の情報を入れるチームがほとんどです。
- “[add]”や”[fix]”といった、何をしたかの動詞
- チケットやissueの番号
- 変更点の概要（詳細はチケットに書いてるため一言ぐらいに留める）
② Issues を使ってみる
GitHubのリポジトリをみると、「Issues」というタブがあります。
これは「イシュー」と読み、バグや追加・修正する予定の機能や使用をまとめておく、TODOリストのようなものです。
要はやることリストなので、他のサービスでタスクを管理するチームもあり、その名残りなのか、「チケット」と呼ばれることもあります。
Issues を使うメリット
TODOリストとしても活用できるので、やることを忘れない、どこまでやったか一目瞭然というメリットがあります。
これに加えて、Git上でコミットメッセージと関連付けたり、Pull requests（プルリク）と関連付けて、トレーサビリティが高い運用ができるメリットもあります。
また、これをやっていると企業の採用担当にも一目置かれ、選考の通過率が上がることも期待できる効果もあり、一石三鳥ぐらいになって嬉しい点ですね。
Issues の使い方
正解の無い世界なので、あくまで１例として Issues の使い方を軽く紹介します。
まずは自分のリポジトリで Issues タブを開きましょう。
「New issue」ボタンを押下し、新しいissueを作成する画面に行きます。
以下のような新規issue作成画面に遷移するので、必要な事項を入力し、「Submit new issue」ボタンを押して作成完了です。
（タイトルを入力すると「Submit new issue」が活性になります）
以下の画像に示すように、「Labels」の部分にはissueの種別を選択できるのですが、ここは入力しておくのがおすすめです。
③ Pull requests を使ってみる
Pull requests とは、プルリクエストと読み、通称「プルリク」などと呼ばれます。
プルリクは、修正内容を公開して他のメンバーに見てもらい、問題がないか確認することを目的としたステップです。
内容に問題がなければ、メインのブランチにマージされ、リリースされます。
必須でないが触っておくと◎
1人開発の場合、プルリクを作成してもそれを見るのは自分のため、「変更点のおさらい」ぐらいにしかなりません。（＝実質意味無し）
しかし、プルリクというのがどういうもので、ブランチのマージをGitHubの画面から行うとどうなるのか、などの動きを確認しておくのは良いことです。
仮にコンフリクト(conflict)が起きた場合に、それを解決した経験などは選考でも加点されるでしょう。
（※コンフリクトがわからない人はググってみてください）
プルリクの作り方
issueの時と同様に、プルリクについても作り方を軽く解説しておきます。
まず自分のリポジトリで「Pull requests」タブを開き、「New pull resuest」ボタンを押下します。
すると、以下の画面に遷移するので、赤で示している通り右側のボックスをクリックして、マージしたいブランチを選択します。
すると画面が変わって、次のようなコミットログや、ファイルの変更内容が見れる画面になります。
ここで内容に問題がないかセルフチェックし、OKなら「Create pull request」ボタンを押してプルリクの作成完了です。
まとめ
採用にも携わるエンジニア目線から、これからエンジニアになる人向けにgitの使い方について解説しました。
初心者からエンジニアになろうとしている人の内、ポートフォリオ作成して動けばいいと思っている人が多いです。
その結果、gitがおざなりになるので、そういったライバルとも差をつけるためにもgitをしっかりやっていくのがおすすめです。
gitもこだわれば奥が深いですが、初心者の段階では、ここまでにご紹介した３つのことを最低限抑えていれば十分です。
その他の時間は自分のポートフォリオのブラッシュアップに使いましょう！
コメント