【初心者卒業】チーム開発初心者がGitHub運用で気を付けるべきチェックリスト

この記事でわかること

・Github開発におけるNG操作
・Github開発の上級者になる方法

みなさんGithubは活用されていますか？

Githubはエンジニアにとって切っても切れない存在で、チーム開発を行うシステムでは、もはや必須ツールといっても過言ではないですよね。

今やどこのプロジェクトでも使用されているGithubですが、

大まかな運用ルールはあったとしても、厳密に使い方を定めているプロジェクトは少ない印象で、個々人の使い方にある程度任せていることが多い印象です。

そのため、初心者にとっては何を気を付けて開発すればよいか分からず、不安になってしまうことも少なくないですよね。

そこで今回は、Githubで開発を行う上で、これさえ気を付けておけば脱初心者！ という内容をチェックリスト形式で紹介していこうと思います。

今回紹介するチェックリストを抑えておけば、チーム開発をスムーズに、ゆくゆくは チームのルール作りを任されるようなエンジニアになれますので、是非参考にしてください。

Gitと何が違うの？Githubについて簡単におさらい

Gitとは・・・ソースコードのバージョン管理ツール

システム開発は複数のプログラマーで同時開発することがほとんどなので、都度ソースコードが書き換わります。そのため、
・最新のバージョンはどれ？
・いつ変更が加わったのか？
・誰が変更したのか？
・どこが変更されたのか？
など、ソースコードのバージョンを把握する必要があります。

『Git』は、このバージョン管理機能を提供をするになっています。

『Git』が ソースコードのバージョン管理 という機能を提供しているのに対して

『Github』はGitの機能をオンラインで利用できるようにしたサービスです。

全世界で1億人以上に使用されていることから、Githubを使いこなすことはチーム開発には必須 といっても過言ではありません。

GitHub運用チェックリストを紹介

ここからは、実際にGithubを使用してチーム開発を行っていくうえで、

・絶対にやってはいけないNGリスト

・チーム開発上級者になるために意識すべきことリスト

をそれぞれ紹介していきます。

絶対にやってはいけないNGリスト

パブリックリポジトリにチームのソースコードをプッシュしない

Githubのリポジトリの公開設定には、『パブリックリポジトリ』と『プライベートリポジトリ』の2種類があります。

公開範囲は、その名の通りで『パブリックリポジトリ』は インターネット上の誰でもアクセスできる リポジトリになります。

誤ってチームで開発しているソースコードをパブリックリポジトリに公開してしまうと、情報漏洩に繋がってしまうリスクがあります。

絶対にやってしまわないように注意しましょう。

機密情報をソースコードに記載しない

システム開発をしていると、暗号処理や認証処理に使用する鍵情報や顧客データなどを扱うことがあると思います。

そういった機密情報は絶対にソースコードに記載したり、Gitコミットしないように注意しましょう。

これは、開発に使用しているリポジトリが『プライベートリポジトリ』であっても同様です。

プライベートリポジトリの情報が外部流出することは基本的にありませんが、Githubのアカウント管理状況や開発者のPCから盗み見られるなど、リスクが0というわけではありません。

情報漏洩に繋がってしまうリスクを生まないためにも、機密情報には十分注意しましょう。Gitコミットしてよいか迷ったときは、勝手に判断せずチームメンバに相談しましょう。

※仮にGithubリポジトリに機密情報をアップロードしてしまった場合は、Githubの公式ドキュメントを参考に対応しましょう。

リポジトリからの機微なデータの削除 – GitHub Docs

チーム開発上級者になるために意識すべきことリスト

プロジェクトのGithub運用ルールを確認する

チーム開発を本格的に開始する前に、必ず プロジェクトのGithub運用ルールを確認 しましょう。

プロジェクトごとに様々なGitHub運用ルールが存在すると思います。

確認すべき代表的なポイントは、以下などです。それ以外にもルールを定めていることも多いと思いますので、必ず確認しましょう。

①ブランチ運用ルールは何を使用しているか

開発するときに、どのブランチをベースに開発して、どのブランチにマージしていくのか。など。

代表的なのは 「GitFlow」、「GitHubFlow」など。プロジェクト独自運用になっていることも多い。

②ブランチ名のルールはあるか

機能開発用のブランチ：feature/xxx

障害対応ブランチ：hotfix/xxx

など

③ブランチのマージルールはあるか

『必ずプルリクエストを使用する』

『プルリクエストはチームメンバの承認が〇人必要』

など

プルリクエストを活用する

機能を開発する場合は、「feature/xxx」のような作業ブランチを切って開発を行うことがほとんどです。

このブランチを、開発・公開用ブランチにマージすることになるのですが、マージする際は必ず プルリクエストを活用 しましょう。

チームメンバにレビューしてもらうことで、バグをチェックしたりなどコードミスを修正できるため、品質が保証されたソースコードをリリースすることが可能になります。

プルリクエストは誰のために書くのかを意識する

プルリクエストを作成する前に、そもそもプルリクエストの内容は誰に向けて書くのかを意識しましょう。

レビュアーのため

もちろんプルリクエストは他チームメンバにレビューしてもらうことが目的なので、レビュアーがレビュー内容を正しく理解できるために、必要な情報を漏れなく記載しましょう。

自分のため

プルリクエストを作成しながら、改めて内容に不備がないか、確認すべきポイントに漏れはないか。など自分のために、改めて内容を整理しましょう。

将来のチームのため

プルリクエストは、設計等のドキュメントと同様にずっと残り続けます。

数か月後、数年後に振り返って、どのような経緯で修正を行ったか分かるように記載してあるべきです。

プルリクエストの質があがることはチーム開発の質に直結する

これらを意識することでプルリクエストの質があがり、結果としてレビュースピードが上がることはもちろんのこと、ひいてはチームとしての開発速度向上に繋がります。

プルリクエストには記載すべき情報を過不足なく記載する

プルリクエスト本文には、必要な情報を過不足なく記載するようにしましょう。

書くべき内容の例を以下にまとめてみました。ぜひ参考にしてください。これ以外にもチームやシステムの特徴を踏まえて、追記すべき内容は整理して記載しましょう。

## 概要

<!-- 変更の概要 -->
<!-- 変更が発生した経緯であるissueやタスクチケットのリンク -->
<!-- 前提知識がない人が見ても理解できる内容にする -->

## 仕様

<!-- 変更の設計資料 -->
<!-- 変更内容の妥当性を裏付ける公式ドキュメントなどのリンク -->

## 変更内容

<!-- 変更した内容のサマリ -->

## 動作確認結果

<!-- 画面変更ならスクリーンショット -->
<!-- API変更なら実行結果 -->

## セルフチェックリスト

* [x] 完了したチェック（例：プルリクエスト内容を見返した、コードチェックツールを実行した。など）
* [ ] 完了していないチェック

## 備考

<!-- その他伝えたいこと -->

プルリクエストテンプレートを活用する

プルリクエストを作成する際は、記載内容を整理して過不足なく記載しましょう。とお伝えしましたが、毎回同じ内容を記載していくのは少々面倒ですよね。

そんなときは、Githubが提供している『プルリクエストテンプレート』機能を活用しましょう。

この機能を有効化することで、プルリクエストを作成時に本文にテンプレートの内容を自動で設定されるので、時間短縮にもなりますし、必要事項を漏れなく記入することに繋がります。

プルリクエストテンプレートの作成は、「pull_request_template.md」というファイルを作成して、gitリポジトリに含めてあげるだけでOKです。

詳細は、GitHubの公式ドキュメント をご確認ください。

プルリクエストは極力小さくする

基本的に、プルリクエストは意味のある単位に、極力小さくするように意識しましょう。

なぜ小さいほうがよいのか。ですが逆に大きい場合の弊害を考えてみると、『膨大な量の変更や、1つの機能追加単位』でのプルリクエストをレビューしようとなると

・変更内容全量を理解するのに膨大な時間がかかる
・それによりレビュアーの拘束時間が長い
・フィードバックを受け取れるのが遅くなる
・機能単位でのレビューになると、動けばOKになりがちで品質が下がる

などのデメリットが考えられます。

ついつい開発を進めていくうちに、関連するソースコードの修正まで行ってしまいがちですが、ぐっと我慢して、細かくプルリクエストを作成するように心がけましょう

結果的にレビュー速度もあがって、チームの開発速度向上に貢献できますよ。

コミットは意味のある区切りの良い単位にする

Gitのコミット粒度は色々な意見があるかと思いますが、プルリクエスト前提でGitバージョン管理を行っていくのであれば、

ある程度区切りのついた単位 でコミットしていくのがよいでしょう。

そうしておくことで、レビュアー目線ではプルリクエストをコミット単位で確認でき、レビューがしやすくなります。

まとめ

以上、今回は全世界のエンジニアが活用しているGithubについて、

初心者がチーム開発で利用する際に 気を付けるべきチェックリスト を紹介しました。

チーム開発をより効率的に行うためには、Githubを使いこなすことが必要不可欠といえます。

今後Githubを利用する際は、今回紹介した内容を意識し、より開発が効率的に回るように心がけていただければと思います。

慣れるまでは少し大変かもしれませんが、実践すれば必ずメンバからの評価も上がりますし、チームが円滑に回るように変化していくはずです。

是非参考にしていただき、チームにとって欠かせない人材になりましょう！

さらにGithubを使いこなすために

今回はチーム開発にフォーカスして、意識すべきチェックリストを紹介しましたが、Githubはまだまだ多くの機能を有しています。

更にGit/Githubを使いこなすためには、一度専門書を手にし、体系的に学ぶことが大切です。

おすすめの本をいくつか紹介しますので、是非ご一読ください。

『Gitが、おもしろいほどわかる基本の使い方33』

ここがオススメ

・Gitの基礎を学べるため Gitを使い始めるひと の入門書として最適
・SourceTreeというGitをGUI操作するツールの使い方が学べる
・Gitへの苦手意識を払拭するのに最適な一冊

『GitHub実践入門 ~Pull Requestによる開発の変革』

ここがオススメ

・GitHubを実践しながら 体系的に理解できる ので入門書として最適
・公開リポジトリを利用してGithub操作を実践できるので深く理解できる
・Gitの基本知識を有していてGithubを深く理解したい人に最適な一冊