目次
個別開発から共同開発へ
これまでGitHubはバックアップや更新履歴の管理に使ってきましたが、実は共同開発にも活用できます。例えば、Aさんはキャラクター作成、Bさんはステージデザイン、Cさんはゲームロジックを担当し、それぞれが同時に作業を進めることができます。作業が終わったら、各自の成果をメインプロジェクトに結合(マージ)できます。GitHubにはこうした共同開発を効率よく進めるための機能が揃っており、より大規模なプロジェクトにも対応できるようになります。
ツールの導入(変更)〜GitGraph
今まで、GitHubはGitHubの公式アプリを使用してきましたが、今後はVSCodeに統合されたGitGraphという拡張機能を使用していきます。GitGraphはそれぞれの作業をグラフィカルに表示し、フォーク(プロジェクトの分岐)や、マージ(プロジェクトの結合)を簡単に行うことができます。
インストール方法
- 「拡張機能」タブをクリック
- 検索欄に「Git」と入力して検索(Enterキー押下)
- 「Git Graph」の「インストール」ボタンをクリック

追加インストール
Gitがまだインストールされていない場合は、以下の手順を参考にインストールしてください。GitHub Desktop(Windows版)ではなく、コンソールで使用できる「Git for Windows」をインストールする必要があります。
https://qiita.com/takeru-hirai/items/4fbe6593d42f9a844b1c
共同開発を行う上で知っておきたいこと
実際の作業に移る前に、共同開発の概念やGitHubで提供される機能を確認しておきましょう。
今まで、個人開発で使用してきた機能
| 対応するGitHubの機能 | |
|---|---|
| 何を変更したかの履歴管理 | Commit履歴 |
| ファイルのバックアップ | GitHubリポジトリ(クラウドベースの管理) |
| ファイルの共有 | GitHubリポジトリ(クラウドベースの管理) |
これまでは、変更履歴やバックアップを目的としてGitHubを使用してきました。これは重要な基礎です。
これから、共同開発で活用できる機能
| 対応するGitHubの機能 | |
|---|---|
| 作業の分担と担当の明確化 | Issues、Projects(タスク管理) |
| 複数人が同時に作業する環境の整備 | ブランチ機能(各自の作業用ブランチを作成) |
| 進行状況の共有 | Pull Requests(レビューを含めた進捗確認) |
| 作業の統合(結合作業) | Merge(マージ機能) |
| 作業の競合や衝突の解消 | コンフリクト解消ツール(GitHub上の比較機能) |
| プロジェクトの全体像の把握 | GitHub Graph(ブランチのビジュアル管理) |
| バグや改善点の管理 | Issues(バグ報告や機能追加のリクエスト) |
これらの機能を使うことで、Aさんがキャラクターを作成しながら、Bさんがステージデザインを進め、Cさんがゲームロジックを実装するといった同時作業が可能になります。さらに、完成した部分を一つのプロジェクトに統合する作業がスムーズに進むようになります。
用語解説
プロジェクト(project)…計画、企画、事業計画
イシュー(issue)…問題、課題、論点、解決すべきものというニュアンスがある
タスク(task)…職務、仕事、任されたものというニュアンスがある
ブランチ(branch)…枝分かれ、部門、朝食と昼食を兼ねた食事
プル(pull)…引く
リクエスト(request)…要望すること、頼む、要請する
レビュー(review)…批評する、再調査する、観閲する
マージ(Merge)…合併する、融合する
コンフリクト(conflict)…衝突、対立、争い
作業の流れ
GitHubやGitGraphを活用した共同開発は、次の2つのステップに分かれます。
- 計画と管理:プロジェクトの目標設定や進捗管理を行う段階
- 開発作業:実際にコードを記述し、成果物を統合する段階
計画の大まかな流れ
計画と管理は主にGitHub(Web)を使って行い、ここではチーム全体で進行を管理します(以下の1の作業が該当します)。その後、具体的な開発作業はGitGraphを使って進めます(以下の2以降)。
- 作業の洗い出しと担当決め プロジェクトでタスク≒イシューを登録し、作業内容や担当を決定。
- ブランチの作成とタスクの開始 Aさんは「キャラクター作成」、Bさんは「UI作成」、Cさんは「ステージ作成」のようにブランチを分けて作業を進める。 ブランチを分けることにより、他の作業に影響を与えず、自分の作業を進められる。
- タスクの完了と確認 完成した部分はプルリクエストでチームに共有し、意見や修正点を確認。
- メインブランチに統合 プルリクエストのレビュー(先生による確認)後、許可が出たらメインブランチにマージ(統合)。
- **コンフリクト(衝突)が発生した場合、GitHubの比較機能で修正し、マージする。 同じファイルの同じ箇所を複数人が編集した場合にコンフリクト(衝突)**が発生することがある。
作業の洗い出しと担当決め
GitHub(Web)のプロジェクト機能を使って、作業の洗い出しと担当決めを行います。
プロジェクトではタスクや担当、進捗の管理を行います。管理方法はいくつかありますが、今回は「カンバン」を使用します。
カンバンはトヨタが生産管理の効率化のために開発した手法で、タスクや進捗を視覚的に管理できるのが特徴です。この方法は、プロジェクト管理のベストプラクティスとして広く使われています。GitHubのプロジェクト機能でも、このカンバン形式を利用してタスクの進行状況を簡単に把握できます。
| カラム | 内容 |
|---|---|
| Backlog | 全タスクをここに集める。未着手のタスク。 |
| Ready | 次に取り組むタスク。優先度の高いものから移動させる。 |
| In Progress | 現在進行中のタスク。担当者が対応中のもの。 |
| In Review | 完了したが、コードレビューや動作確認が必要なタスク。 |
| Done | 完了済みのタスク。 |

ブランチ〜マージ
- ブランチを作る 自分専用の「作業エリア」を作ります。 コードを変えたり追加したりするのは、ここで行います。
- 作業をする コードを直したり、機能を作ったりします。 「ここまで終わった!」というタイミングで記録(コミット)します。
- プルリクエストを作る 作業が終わったら、「この作業を確認してください!」と提出します。 プルリクエストに作業内容を書いて先生に送ります。
- 先生が確認してOKならマージ 先生が内容を確認して、問題がなければみんなのコードに合体します。 必要なら直すアドバイスをもらうこともあります。