【Unity実践】初めてのUnityチーム開発フロー(GitHub Desktop) #3

はじめに

この記事では、初めて Unity と GitHub と GitHub Desktop を使って共同開発する人向けに、
「理解はあとでもいいので、まずは手を動かせる状態」を作ることを目標に説明します。

難しい用語は最初に短く説明します。
分からないところがあっても、まずは手順どおりに進めてみてください。

この記事は、チームでの実運用に近い流れとして、作業用ブランチ を作ってから作業する手順で説明します。

この記事の目標

• チーム開発での、メンバーごとの初期セットアップの違いがわかる
• 1回分の作業フロー（更新取り込み -> 作業 -> コミット -> プッシュ -> PR作成）を実行できる
• レビューで修正が来たときに、どこから再開すればよいかわかる

最初に出てくる用語

• リポジトリ: プロジェクトのファイルと変更履歴を保存する場所です。
• ブランチ: 作業を分けるための枝です。共同開発では通常、main とは別の枝で作業します。
• コミット: 「ここまで変更した」という保存ポイントです。
• プッシュ（push）: ローカルPCの変更をGitHubに送る操作です。
• プル（pull）: GitHub側の最新変更をPCに取り込む操作です。
• Pull Request（PR）: 自分の変更を main に取り込んでもらうための申請です。
• マージ（merge）: PRで確認された変更を、最終的に main へ取り込む操作です。

メンバーごとのセットアップ方法

チーム開発では、次の2パターンでセットアップが少し変わります。

• 自分がUnityのプロジェクトを作った場合
• 他のメンバーがUnityのプロジェクトを作った場合

自分がUnityのプロジェクトを作った場合

まずは、前回の記事（UnityプロジェクトをGitHub管理する初期セットアップ）を参考に、
リポジトリ作成 と 最初のコミット まで完了させてください。

• リポジトリがpublicの場合：特にやることはない
• リポジトリがprivateの場合
  1. リポジトリのオーナーが自分の場合: 共有したいメンバーをリポジトリの Collaborator に追加する
  2. リポジトリのオーナーが Organization の場合: 共有したいメンバーを Collaborator に追加するか、Organizationの Member として追加する

public は全員に公開、private は招待した人だけが見られる設定です。
勉強会用リポジトリは基本的に private で運用します。

他のメンバーがUnityのプロジェクトを作った場合

まずは、リポジトリへのアクセス権限があるかどうかを確認します。メンバーからリポジトリURLを受け取ってブラウザで開いてみましょう。

成功例	失敗例

失敗した場合はリポジトリへのアクセス権がない可能性が高いです。リポジトリ作成者に報告し、権限を付与してもらいましょう。

成功したら、作成済みリポジトリを クローン（clone） して使います。

クローン とは、GitHub上のリポジトリを自分のPCに丸ごとコピーする操作です。

1. メンバーからリポジトリURLを受け取る
2. GitHub Desktop の File -> Clone repository を開く
3. URL タブに受け取ったURLを貼り、Clone を押す
4. Unity Hub の Add project from disk で、クローン先フォルダを選ぶ

OneDrive など自動同期フォルダの中にクローンすると、競合や破損の原因になることがあります。
クローン先は同期されないフォルダを使ってください。

典型的な作業フロー

ここからは、実際に毎回行う流れです。
チーム開発では「main で直接作業しない」が基本です。

2 -> 3 -> 4 -> 5 は、1回で終わるとは限りません。
機能追加やレビュー修正のたびに、同じ流れを繰り返します。

1. 作業を始める前に最新状態を取り込む

1. Current branch を main に切り替える
2. Fetch origin を押す
3. 取り込む更新があれば Pull origin を押す

Fetch origin は「更新があるか確認」、Pull origin は「更新を取り込む」です。

Fetch origin	Pull origin

2. 作業用ブランチを作る

1. Current branch -> New branch を押す
2. ブランチ名を入力する（例: feature/player-move）
3. ベースが main になっていることを確認して作成する

ブランチ名は「何をする枝か」が分かる名前にすると、レビューがしやすくなります。

New branch を押す	ブランチ名を入力して作成

3. Unityで作業してコミットする（必要な回数だけ繰り返す）

1. Unityで作業して保存する
2. GitHub Desktop に戻って変更ファイルを確認する
3. Summary を書く（必要なら Description も）
4. Commit to ブランチ名 を押す

Summary は「何をしたか」を短く書きます。
例: プレイヤー移動処理を追加

1. Unityで作業して保存する

Hierarchyで右クリックして 3D Object/Cube を選択	Ctrl+S で保存( SampleScene の隣の*が消えれば保存成功)

2-4. GitHub Desktopの操作

Summary を書いてコミット

4. プッシュしてPRを作成する

1. Push origin を押してGitHubへ送る(1回目は Publish branchを押す)
2. 表示される Create Pull Request（またはGitHub上のPR作成導線）を開く
3. PRタイトルと説明を書いて作成する
4. レビュワー（確認してもらう人）を設定する

そのブランチで初めてプッシュする場合は、 Publish branchと書いてある場所を押してください。内部的にはプッシュも行われています。
2回目以降はこの場所が Push origin になっています。

1回目	2回目以降

次に、PR作成ページに移動します。

Create Pull Request を押す場合	GitHub上のPR作成導線を開く場合

次に、PRタイトルと説明を書いて、 Create pull request を押します。

レビュー は、他のメンバーに変更内容を確認してもらう工程です。

レビューを依頼する方法は様々ですが、チームのルールに従いましょう。

(例)

• PRのURLを共有する
• Reviewerにメンバーを設定する
• PRの説明文内でメンバーをメンションする
  など

5. レビュー対応してマージする

1. 修正指摘があれば、同じ作業ブランチで修正する
2. 再度コミットして Push origin する
3. 指摘が解消したら、PRを Merge して main に取り込む

指摘が来たときに新しいブランチを作り直す必要はありません。
同じPR・同じブランチに修正コミットを追加すればOKです。

実際の開発では、3（作業・コミット）-> 4（プッシュ）-> 5（レビュー対応） を何度か繰り返し、
最終的にレビューOKになったらマージ、という流れになります。

マージするには下の方の Merge pull request を押します。

6. マージ後に手元を更新する

1. 自分のブランチ作業を終えたら main に戻る
2. Pull origin して、マージ済みの最新状態を取り込む
3. 必要なら使い終わったブランチを削除する

補足: なぜmainで直接作業しないの？

• main は「いつでも動く状態」を保つための本線です。
• 作業ブランチで変更を分離すると、失敗しても影響を小さくできます。
• PRで確認してから取り込むことで、チーム全体の事故を減らせます。

main に戻る	Pull origin する

ブランチを削除するときは、リモートとローカルそれぞれ削除する必要があります。
リモートはマージした段階で削除することをお勧めします。

リモート	ローカル

この状態でUnityを開くと、設置したCubeが置かれているはずです。

つまずきやすいポイント

1. Changed files が異常に多い
   原因: .gitignore の設定漏れの可能性があります。Unity向け .gitignore を確認してください。参考: GitHub公式の Unity.gitignore

2. main でそのままコミットしてしまった
   対応: そのコミットをPRに載せる前に、可能なら作業ブランチへ移してから運用し直します。

3. Pullで競合（conflict）が出た
   対応: 同じファイルを別メンバーが編集した可能性があります。慌てずに相談して解決しましょう。

競合（conflict） は、同じ場所を別々に変更したときに起きる「どちらを採用するか決める必要がある状態」です。

まとめ

1. まず main の最新状態を取り込みます。
2. 作業用ブランチを作ってUnity作業を進めます。
3. 作業 -> コミット -> Push -> レビュー対応 を必要な回数だけ繰り返します。
4. レビューOKになったらマージし、最後に main を更新します。

「意味は完全に分からないけど、手順どおりなら進められる」状態になっていれば十分です。
慣れてきたら、次はブランチ運用や競合解決を少しずつ深掘りしていきましょう。