当ブログではPRや広告を掲載しています

エンジニアへの転職に使える! 1人開発でのGit運用術

プログラミング
この記事はこんな人向け
  • 未経験からエンジニアへ転職しようとしている
  • ポートフォリオ作成中 or これから作る
  • git のコミットメッセージに何を書けばいいかわからない
スポンサーリンク

Gitがしっかりしていれば転職成功率は上がる

僕は、とある企業でエンジニアとして働き、採用にも関わっています。
中側の人間だからこそわかることで、今回は意外と採用で見られるGit(GitHub)の運用について紹介していきます。

エンジニアになろうと行動されている方は既に学習を始めていて、就職活動の際にポートフォリオの提出が必要なことがわかっていると思います。

ポートフォリオでは、使っている技術や完成度はもちろんのこと、Gitのコミットログまで見られることがあります。

そして残念ながら、Gitの使い方がお粗末な初心者の多いこと。。。

初心者のうちは基礎的なことを大事に

1人で開発しているうちは、Git自体そんなに重要に捉えられないと思いますが、就職してチーム開発する時にはとても重要なスキルになってきます。

企業の選考では、そこまで考えているかは別として、Gitがきれいに運用されていることを見る会社も少なくないです。

そして、技術力が高くない初心者ほど、Gitがきれいじゃない場合に落とされることが多くなります

最低限やったほうがいいこと3選

① コミットメッセージをしっかり書く

これが一番大事です!

gitコマンドでのコミットは以下のようにし、コミットメッセージはダブルクォートの間に書きますよね。

git commit -m "ここに好きなメッセージを書く"

× コミットメッセージのダメな例

“テスト”とか、“update”“コミット”などのメッセージはダメなパターンとして多いです。

なぜダメなのかと言うと、そのメッセージ内容で「どういう変更が行われたか」が全くわからないためです。

チーム開発では複数人で同じソースコードをいじるので、他の人が行った変更が一言でわかることが理想です。
ここで、”update”というコミットがあったとしましょう。何がアップデートされて、どういう影響があるのかもわかりませんし、実際の変更はREADMEのみであった、なんてことになると確認するのが手間でしかありません。

○ コミットメッセージの良い例

良いコミットメッセージは、「変更点が一言でわかること」です。

「git コミットメッセージ」とかでググると、理想的なメッセージの書き方がいくつも出てくると思いますが、チームによって細かい部分は変わります。

よく用いられる、メッセージに書くべき内容としては以下の情報を入れるチームがほとんどです。

  • “[add]”や”[fix]”といった、何をしたかの動詞
  • チケットやissueの番号
  • 変更点の概要(詳細はチケットに書いてるため一言ぐらいに留める)

② Issues を使ってみる

GitHubのリポジトリをみると、「Issues」というタブがあります。
これは「イシュー」と読み、バグや追加・修正する予定の機能や使用をまとめておく、TODOリストのようなものです。

要はやることリストなので、他のサービスでタスクを管理するチームもあり、その名残りなのか、「チケット」と呼ばれることもあります。

Issues を使うメリット

TODOリストとしても活用できるので、やることを忘れない、どこまでやったか一目瞭然というメリットがあります。

これに加えて、Git上でコミットメッセージと関連付けたり、Pull requests(プルリク)と関連付けて、トレーサビリティが高い運用ができるメリットもあります。

また、これをやっていると企業の採用担当にも一目置かれ、選考の通過率が上がることも期待できる効果もあり、一石三鳥ぐらいになって嬉しい点ですね。

Issues の使い方

正解の無い世界なので、あくまで1例として 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もこだわれば奥が深いですが、初心者の段階では、ここまでにご紹介した3つのことを最低限抑えていれば十分です。
その他の時間は自分のポートフォリオのブラッシュアップに使いましょう!

コメント