【エンジニア必読】GitHub運用のメリット・方法について解説！

エンジニアがアプリケーションを開発する際は、ソースコードなどを適切に管理しなければなりません。ソースコードの管理が適切でないと、修正するファイルを間違えてしまうなど、バグを生み出したりデグレーションを起こしたりする原因となります。

このような状況を防ぐためには、バージョン管理ツールなどでソースコードを適切に管理しなければなりません。ツールにはいくつかの選択肢がありますが、世界的に利用されているものがgithubです。今回は、エンジニアならば必ず理解しておきたい、Githubによるソースコード管理や具体的な運用方法について解説します。

GitHubとは

GitHubとは、エンジニアがソースコードをホストしたり協力して開発したりするためのプラットフォームです。2008年に公開され2018年にはMicrosoft社に買収されたものの、エンジニアがソースコードを管理するためのツールとして世界中で利用されています。

GitHubでの作業は「リポジトリ」という単位で行われることが特徴です。これは、特定のプロジェクトコードやドキュメント、関連するリソースなどを格納するための場所だと理解しましょう。また、リポジトリは変更を「コミット」という情報で記録できるようになっていて、過去の変更内容やその時のコメントを簡単に参照できるようになっています。

また、GitHubには「ブランチ」と呼ばれる機能もあり、エンジニアは同じリポジトリ内で複数バージョンのソースコードを変更して開発できます。これにより、新しい機能の追加やバグ修正など、複数の作業を同時に進められるのです。ツールを使わずにこのような作業を実施すると、トラブルの原因となりかねませんが、GitHubならば安心して管理できます。

GitHubで開発作業を運用する5つのメリット

GitHubで開発作業を運用するメリットは数多くあります。具体的にどのようなメリットがあるか、5つをピックアップすると以下の通りです。

確実なバージョン管理

Gitにはバージョン管理機能があるため、GitHubにも同様にコードの変更履歴を細かく管理する機能があります。純粋な差分を記録するだけではなく、コメントやメモを残せるようになっているため、変更した理由も一目で把握できるのです。どのような理由で変更したかの記録は、チームで開発する際に非常に大きな役割を果たしてくれます。

また、確実なバージョン管理によって、問題が発生した場合の対処を実現しやすくなります。例えば、新しいアプリケーションをリリースしてバグが生じた際に、リリース前のバージョンにすぐ戻せるのです。バージョン管理していなければ、このような切り戻し作業は難しく、バグなどが発生した際の影響が大きくなってしまいます。

複数人での効率的な開発

アプリケーション開発は、個人ではなく複数のエンジニアで実施されるケースが多くあります。このような状況下では、ソースコードの管理が非常に重要となるため、GitHubを運用する大きなメリットを感じられるでしょう。

例えば、説明したようにGitHubには「ブランチ」やエンジニアが開発した内容を管理する「プルリクエスト」という機能があります。ブランチを利用すれば、メインのソースコードに影響を与えずに、新規の開発やバグ修正を進めることが可能です。また、プルリクエストを適切に管理すれば、開発リーダーなどが内容を承認してからメインのソースコードへ反映できます。

複数人で効率的な開発を実現するためには、ソースコードの一貫性を保つことが重要です。一貫性を保ちつつ、お互いが協力しながら開発できるGitHubは、多くのメリットを提供してくれます。

ドキュメンテーション

開発においては「ソースコードさえあれば良い」と考えられがちです。しかし、実際には設計書など、関連するドキュメントも管理しなければなりません。GitHubならば、ソースコードのみならず、ドキュメントもバージョンを含めて管理できることがメリットです。

例えば、ソースコードと同様にテキスト形式のファイルを用意することで、バージョンを含めて内容を管理できます。開発に必要な情報をテキストファイルに記録して、GitHubへとアップロードしておくと、その内容を他のエンジニアにも周知できるのです。

また、GitHubには「Wiki」の機能が用意されています。こちらにプロジェクトの概要や学習ツールの設定値、開発に向けた設計書などを保存しておくと、参照しながらスムーズに開発が可能です。テキストファイルなどファイル形式はもちろん、ツールの機能でもドキュメンテーションできるようになっています。

イシュー管理

バグの報告や新機能の提案、タスクの割り当てなど、開発作業に関わる様々なタスクを管理できます。一般的にイシューといえば「問題」をイメージするかもしれませんが、GitHubでは「タスク」のような意味合いで利用される点に注意しましょう。

イシュー管理できるようになっているため、エンジニアや関係者は、管理されている内容を踏まえてコミュニケーションを取れます。例えば、エンジニアからエンドユーザーへ質問したり、開発エンジニアからリーダーへバグを報告したりできるのです。別のツールを利用しなくても、バージョン管理しながら、これらも一限管理できることはメリットと言えます。

なお、イシューを管理するだけではなく、ラベルやマイルストーンを付与する機能も用意されています。チケット管理ツールに近い機能が用意されていて、効率良いアプリケーションの開発が可能です。

アクセス制御

GitHubには、どのエンジニアがどのリポジトリやリソースにアクセスできるのか管理する機能があります。権限の異なるアクセスレベルを設定でき、プロジェクトの役割に応じた権限に合わせられるのです。例えば、開発するだけのエンジニアと開発内容を承認するエンジニアに分類できます。

大規模なプロジェクトでは、このような権限管理が非常に重要です。例えば、社員のエンジニアと外部のエンジニアで、閲覧できる範囲を制限しなければならないことがあります。また、同時に複数のアプリケーションを開発していると、それぞれのプロジェクトに関連する部分だけを修正できるようにしなければなりません。

GitHubで開発を運用する方法

GitHubで開発する際の方法はいくつかあるため、代表的な2種類をピックアップして紹介します。

GitFlow

GitFlowは、ソフトウェア開発の流れを標準化して、大規模なプロジェクト開発でも複数のエンジニアで効率よく開発する手法です。GitHubを運用する際に、GitFlowを適用する方法は以下のとおりです。

初期設定

GitFlowを開始する前に、リポジトリを作成したりクローンしたりしておくことが求められます。その後に、GitFlowツールをインストールして、初期設定を行わなければなりません。多くのGitクライアントには、GitFlowをサポートする機能が組み込まれているため、それらを活用しましょう。

なお、GitFlowには特有のブランチ構造があり、以下のような構造にすることが求められます。

• masterブランチ: 安定したバージョンのコードが格納され、リリースのたびに更新される
• developブランチ: 次のリリースに向けた開発をおこなう
• featureブランチ: 新しい機能を開発する
• releaseブランチ: 新しいリリースの準備をする
• hotfixブランチ: masterブランチで発見されたバグの修正を行う

状況に応じて、適切なブランチを選択することで、全体の統率を図りながらアプリケーション開発できるのです。

機能の開発

新しい機能を開発する際は「feature」ブランチを作成します。例えば、以下のようなコマンドでブランチを作成しましょう。

git checkout -b feature/my-new-feature develop

こちらで開発を進め、開発が完了すれば「feature」ブランチを「develop」ブランチへとマージするルールです。

リリースの準備

開発したソースコードをリリースするためには「release」ブランチが必要です。例えば、以下のコマンドでブランチを作成します。

git checkout -b release/v1.0.0 develop

また、リリースの準備が整ったならば「release」ブランチを「master」と「develop」の両方にマージしなければなりません。また、マスターブランチにはタグをつけておきます。

git tag -a v1.0.0

GitHubへの連携

開発してリリースする準備が完了すれば、GitHubへとプルリクエストを出さなければなりません。ソースコード全体は、特定の管理者が管理する運用が一般的であるため、リクエストを承認してもらいましょう。

ただ、リクエストの承認にあたっては、関係者によるレビューが求められていることがあります。複数人でソースコードを評価して、問題ないと判断された際にマージを認めるのです。評価の過程がなければ、運用が崩壊する可能性があるため、レビュー者や承認者は可能な限り設けるようにしましょう。

GitHubFlow

GitHubFlowは、GitHubでのプロジェクト運用を簡略化してCI/CDを前提としたワークフローです。例えば、以下のようなフローで運用されます。

常にデプロイできる「master」ブランチの用意

GitHubFlowで運用するにあたっては「master」ブランチが、常にデプロイ可能な状態でなければなりません。こちらは大前提であるため、手動でデプロイするような運用になっているならば、GitHubFlowの考え方には適していません。

なお、新しい機能の開発やバグの修正は「master」ブランチから派生したブランチで実施します。必要に応じて、以下のようにその都度作成しなければなりません。

git checkout master
git pull
git checkout -b descriptive-branch-name

変更のコミット

各種変更は、全てローカルブランチで実施されています。そのため、これらの変更は定期的にコミットしなければなりません。例えば、毎日の開発が終了したタイミングで、変更内容をコミットします。

コミットにあたっては、変更内容が分かるように心がけましょう。例えば「バグ1：変数名修正」などと記載しておくと、どのような変更理由からコミットしたのかわかりやすくなります。このようなコメントやメッセージの付与は、運用ルールとして定めておくことが重要です。エンジニアが自由に記述してしまうと、逆に内容が分かりづらくなってしまいます。

リモートリポジトリへのプッシュ

必要な変更が完了したならば、リモートリポジトリにプッシュしておきます。例えば、以下のコマンドでプッシュが可能です。

git push origin descriptive-branch-name

また、プッシュするだけではなく、そこから「master」ブランチに対してプルリクエストも作成しましょう。ローカルブランチで作成しても、全体には影響しないため、最終的にはマージしてもらうことが求められます。

リクエスト内容のレビューと承認

エンジニアが開発した内容は、プルリクエストとして一旦は保留されます。最終的に、他のエンジニアがレビューやテストして、問題ないと判断されてから確定される運用です。

もし、リクエスト内容に問題があったならば、差し戻してエンジニアに修正してもらわなければなりません。そのまま、リクエストを承認してしまうと、バグを含んだプログラムがリリースされてしまいます。

まとめ

GitHubは、世界中のエンジニアが開発に利用しているバージョン管理ツールです。ソースコードやドキュメントを効率的に管理できるため、この機会に概要は理解するようにしておきましょう。

管理を効率化するために様々な機能が用意されていて、運用方法は複数あります。今回紹介した2種類を中心に、運用方法も把握することが大切です。

なお、細かな運用ルールは、開発プロジェクトによって異なります。独自のルールが設けられていることも多く、不明点があるならば、リーダーなどに確認しましょう。