10分で分かる実務のGithub

実務で使うGithubの使い方わかりますか？

エンジニアとして仕事をしていくならGithubの

• Issue
• Pull request
• コードレビュー
• マージ

という業務フローを確実に理解しておく必要があります。

本記事ではそれぞれについてわかりやすく説明しますので、ぜひ最後までみていってください！

※簡単は動画も最後に添付していますので、そちらもご覧ください。

issueについて

issueとはタスクのことで、主に

• 新規機能を作ってください
• バグが発生したので直してください
• 文言を修正してください

などの特定の目的達成のために作成されます。

一覧

issueは各リポジトリに存在しており、特定のリポジトリにアクセスすると下記の画像の赤枠部分をクリックすることでissueの一覧画面にいくことが可能となります。

通常Issueには複数のissueが入っており、プロジェクトや会社によって

• バグから優先的に対応
• 上から順に対応
• 特定機能の実装から対応

などのルールが存在していますが、今回はルールが一切ありませんので、「e2eテストの追加」というissueをクリックして、issue詳細画面に行きます。

詳細画面

詳細画面では具体的な仕様を確認することができ、指示書に従って要件を満たしていくことになります。

内容を確認したら、次は「このissue、私が担当します。他の方は手をつけないでください！」ということを明確に示すために自分をアサインします。

※アサインはエンジニア業務では一般用語で、割り当てることを意味します。「このタスク大久保さんにアサインしておきますねー。」などMTGでは頻出します。

自分をアサインすると(誰かに自分がアサインされていたら)、他のメンバーは「これ大久保さんがやってるから他のissueやろっと」という状態になりますので、アサインしたら自分でissueを完了させましょう。

ちなみにアサインすると下記の画像のように明確に割り当てられています

アサインした後は実際にこのissueの内容を満たすために作業していくわけですが、作業するにあたって新規でブランチを作る必要があります。

なぜ新規でブランチを作成するのか？と思われるかもしれませんが、Gitはセーブデータを元に前後関係を把握する仕組みであるため、仮に複数人が同じブランチで作業をしてしまうと、ぐちゃぐちゃになってしまい、Gitが「どれが正しい修正かわかりません！」というエラーを発生させてしまいます。

このような理由があるので、issueを担当する場合は必ず新規でブランチを作成しましょう

ブランチ作成ですが、暗黙的ルールがあり、通常

issue-{issueの番号}

で命名する慣習があります。

また、ブランチは

• master
• develop

などがありますが、多くのプロジェクトでissueのLabelsのブランチから新規にブランチを作成することが多いです。

この条件で行きますとこのようなissue-84をdevelopのブランチから作成することになります。

また、実際にターミナルからブランチを作成する際はこちらのコマンドで実行が可能です

git checkout develop  # developに移動
git fetch # git情報を最新に更新
git pull # localのdevelopを最新に更新

git checkout -b issue-84 # 今回は84ですが、適宜番号変えてください

Pull requestについて

Pull requestとはissueの内容を満たすコード書いたので

• 動作確認して
• コードチェックして
• 最後はマージしてください！

の流れのフェーズのことです。

※issueの指示書を満たすコードをremoteにpushしたので、OKなら取り込んでください、という意味。

余談

Pull requestは

• PR
• プルリク

などを呼び方変えることが多いですので、毎回「Pull request」を連発すると「あ、こいつ初心者だ！」となるので、「プルリク出しときましたー」とスムーズに言えると、初心者で使えなさそうというレッテルは貼られません！（多分）

Pull request作成

Pull requestはlocal環境で修正を行い、

• コミット
• remoteにpush

することでGithub上で作成することが可能になります。

実際の作業はこちらです

まずはターミナルでコミットとpushします

git commit -m "文言修正" # 無理矢理コミットするために文言を変えただけです。。
git push origin issue-84

pushすると、GIthubのPull requestからPRを作成することができます

下記画像の「Compare & pull request」をクリックすると

このような画面が出てくるので、

• baseをissueのLabelsのブランチに変更(新しくブランチを作る際にbaseとなった箇所を指定します)
• タイトルにWIPをつけます( work in progressの略で、まだ作業中で完了してません。まだ確認とかしないでね！という意味 )

こちらを対応して「Create pull request」をクリックしてPRを作成します。

作成が完了すると、このような画面になります。

ここまできたらコードレビューを依頼しましょう！

※テストやLintについて

テストやLintを導入しているプロジェクトではPRの下の画面にこのようなセクションがあります。

このプロジェクトではCircleCIというpushすると自動で

• テスト
• Lint

などを実行する仕組みを導入しているので、コードレビューする前に全て問題ないことを確認しましょう。

コードレビューについて

上記の作業を全て終えたら、書いたコードをみてもらいましょう！

まずはタイトルの「WIP」を削除して画面右側の「Reviewers」で先輩や上司を選択してコードチェックをしてもらいます。

選択が完了するとこのような画面になりますので、チェックが終わるのを待ちましょう。

ちなみに待ち時間ですが、確認が終わるまで何もしないのではなく、確認してもらっている最中は別のissueを担当することになりますので、継続してひたすらissueをこなしていきましょう！

そしてチェックが終わったら

• 指摘されたらその箇所を修正する
• 問題なければマージする(自分ではなく先輩や上司がやってくれます)

ので、これで一通りのエンジニア業務が完了することになります！

まとめ

issueからマージまでの流れをわかりやすくご説明しましたが、いかがでしたでしょうか？

インターネットや書籍にはこのような実務的な内容が公開されていることはかなり少ないので、この記事はかなり役立つ内容だったかと思います。

このGItの使い方は一般論的な話をしており、使い方として大きく外れることはありませんので、ぜひ復習して体得してください！

最後にですが、ギミジョブは未経験エンジニアが実案件をベースに学習することができる実務経験型プログラミングスクールです。

今回のGithubの使い方はもちろんのこと、

• テストコード記述
• Lintツールでコードチェック
• 自動テスト化

などの実務をそのままサービスにしています。

大変勉強になりますので、ぜひご検討ください！

＊毎月新規は5名までと絞っておりますので、検討される際はお早めに！

＊動画での解説はこちらのYoutubeからご覧ください