【Unity 6】2人チーム開発の実務フロー｜担当別テストシーン・Prefab・PR・シーン統合

広告

Gitチーム開発シリーズ・Unity 6 実務フロー編：2人で作る6ステップの実習記事を終えた人向けです。画像とサンプルのPlayer・Coin・CoinCounterを引き継ぎ、日々のチーム開発で続けやすい作業の分け方に進みます。

今回も2人でコイン収集ゲームを作ります。AさんがPlayer、BさんがCoinとスコアを担当します。動作確認には担当別のテストシーンを使い、共有するMainScene.unityは統合担当がレビュー付きのPRで更新します。完成条件は、全員が最新のmainを取得し、3個のCoinを集めるとCLEAR!が表示されることです。

2人の開発者がプレイヤー移動とコイン収集を別々に開発し、Pull Requestで統合して完成させるUnityチーム開発の流れ
2人で別々の機能を開発し、Pull Requestで統合するまでを体験します。

この進め方で残す成果物

担当作るもの動作確認に使うものPRで確認すること
AさんPlayerMovement.cs、Player.prefabAssets/DevScenes/PlayerCheck.unityPlayerの移動、対応する.meta、共有シーンを変更していないこと
BさんCoin.cs、CoinCounter.cs、2つのPrefabAssets/DevScenes/CoinCheck.unity接触・カウント、対応する.meta、共有シーンを変更していないこと
統合担当（この例ではAさん）MainScene.unity統合後のMainScene.unityPlayer・Coin・スコアを組み合わせた結果と、ほかのメンバーによるレビュー

担当別テストシーンは、作り直す手間を減らし、PRのレビュー担当も同じ状態を再現できるようにするため、各担当の成果物としてCommitします。PlayerCheck.unityとCoinCheck.unityは別ファイルにし、同じテストシーンを2人で同時編集しません。これらのシーンはこの例の命名です。

STEP 1：共通の土台をそろえる

  1. 2人とも同じUnity 6のEditorバージョンでプロジェクトを開きます。Input Systemを使用するため、Package Managerの導入状況とActive Input Handlingを確認します。
  2. AさんはMainScene.unityを保存し、GitHub Desktopでプロジェクトのルートをリポジトリにします。Git IgnoreはUnityを選び、Assets、Packages、ProjectSettingsと必要な.metaを共有します。LibraryやTempはCommitしません。
  3. BさんはClone先をUnity Hubに既存プロジェクトとして追加し、同じEditorで開きます。別の新規プロジェクトをClone先の中に作りません。
  4. 2人でmainのMainScene.unityが開くこと、Consoleに作業を妨げるエラーがないことを確認します。

フォルダーやアセットの.metaは対応するファイルと一緒にCommitします。空フォルダーをGitで維持したい場合の.gitkeepは、実習記事で説明したとおり任意です。

STEP 2：担当ブランチとテストシーンを分ける

Aさんは最新のmainからfeature/player-movement、Bさんはfeature/coin-collectionを作ります。それぞれのブランチでAssets/DevScenesに担当専用のテストシーンを作ります。共有シーンを一時的な実験場所にせず、Prefabとスクリプトの動作を自分のテストシーンで確認します。

AさんはPlayerMovement.csとPlayer.prefab、BさんはCoin.cs・CoinCounter.csとCoin.prefab・CoinCounter.prefabを作る。MainScene.unityは担当ブランチのPRに含めず、Prefab統合後にAさんがシーンを編集して2人で動作確認する
Prefabは担当別に作り、PRで統合します。シーンは統合後にAさんが編集します。クリックすると拡大できます。

図のMainScene.unityは統合段階でAさんが編集する共有シーンです。担当ブランチのPRには各担当のテストシーンを含めても、MainScene.unityの変更は含めません。テストシーンを共有しない運用も可能ですが、この例では再現性を優先してPRに含めます。

STEP 3：AさんがPlayerを作り、専用シーンで確認する

PlayerMovement.csを作り、Rigidbody 2DとCollider 2Dを付けたPlayerをAssets/Prefabs/Player.prefabに保存します。Prefabの設定を変えるときはPrefab Modeでアセットを開き、シーン上のインスタンスだけに残ったOverrideと混同しないようにします。

using UnityEngine;
using UnityEngine.InputSystem;

[RequireComponent(typeof(Rigidbody2D))]
public class PlayerMovement : MonoBehaviour
{
    [SerializeField] private float moveSpeed = 4f;

    private Rigidbody2D rb;
    private Vector2 moveInput;

    private void Awake()
    {
        rb = GetComponent<Rigidbody2D>();
    }

    private void Update()
    {
        Keyboard keyboard = Keyboard.current;
        if (keyboard == null)
        {
            moveInput = Vector2.zero;
            return;
        }

        float x = 0f;
        float y = 0f;

        if (keyboard.aKey.isPressed || keyboard.leftArrowKey.isPressed) x -= 1f;
        if (keyboard.dKey.isPressed || keyboard.rightArrowKey.isPressed) x += 1f;
        if (keyboard.sKey.isPressed || keyboard.downArrowKey.isPressed) y -= 1f;
        if (keyboard.wKey.isPressed || keyboard.upArrowKey.isPressed) y += 1f;

        moveInput = new Vector2(x, y).normalized;
    }

    private void FixedUpdate()
    {
        rb.linearVelocity = moveInput * moveSpeed;
    }
}
  1. PlayerCheck.unityにPlayerのPrefabを配置し、必要なCameraなどを用意して保存します。
  2. Playし、WASDと矢印キーで上下左右に動くことを確認します。動かない場合はGameビューのフォーカス、Console、Input System設定を順に確認します。
  3. Playを止め、PlayerのPrefabとスクリプト、PlayerCheck.unity、各.metaを差分で確認します。テストシーンは次回も使うため残します。
  4. MainScene.unityがChangesに出ていないことを確認してCommit・Pushします。

この段階で確認するのはPlayer単体の移動です。Coinとの接触や最終配置は統合PRで確認します。

STEP 4：BさんがCoinとスコアを作り、専用シーンで確認する

BさんはCoin.cs、CoinCounter.csを作り、それぞれCoin.prefabとCoinCounter.prefabに保存します。CoinのCircle Collider 2DではIs TriggerをONにします。

Coin.cs

using UnityEngine;

public class Coin : MonoBehaviour
{
    private bool collected;

    private void OnTriggerEnter2D(Collider2D other)
    {
        if (collected || !other.CompareTag("Player")) return;

        collected = true;
        CoinCounter.AddCoin();
        Destroy(gameObject);
    }
}

CoinCounter.cs

using UnityEngine;

public class CoinCounter : MonoBehaviour
{
    private const int Goal = 3;
    private static int count;

    private void Awake()
    {
        count = 0;
    }

    public static void AddCoin()
    {
        count++;
    }

    private void OnGUI()
    {
        GUI.Label(new Rect(20, 20, 260, 40), $"Coins: {count} / {Goal}");
        if (count >= Goal)
        {
            GUI.Label(new Rect(20, 60, 260, 40), "CLEAR!");
        }
    }
}

このコードは元記事の小さな教材用サンプルです。OnGUIやstaticのカウントを採用したまま、ここではチームの分担と検証の流れに焦点を当てます。UIや状態管理を拡張する際は、別の設計課題として扱います。

  1. CoinCheck.unityを作り、CoinとCoinCounterのPrefab、Playerタグ・Rigidbody 2D・Box Collider 2Dを持つテスト用オブジェクトを置いて保存します。
  2. Playし、Coinへの接触でCoinが消え、カウントが増えることを確認します。3個でCLEAR!が出ることも確かめます。
  3. スクリプト、Prefab、CoinCheck.unity、各.metaの差分を確認します。共有のMainScene.unityは担当PRに含めません。
  4. 確認した結果をPRに書ける形で残し、Commit・Pushします。

STEP 5：PRで成果物と再現手順をレビューする

AさんとBさんがそれぞれのブランチで作業し、Pull Requestとレビューを経てmainに統合し、各自がPullで最新を取得するまでのGitの流れ
ブランチ・PR・マージの全体像です。Bさんが最新のmainを取り込む操作は、下の「Bさんが最新のmainを取り込む順序」の図で確認します。

各自がbaseをmain、compareを担当ブランチとしてPRを作ります。説明には目的、変更ファイル、テストシーンの開き方、実際に確認した操作と結果、未確認の範囲を記載します。「動いた」だけで終えず、レビュー担当が再現できる情報を残します。

  • 担当外のファイルやMainScene.unityが混ざっていないか。
  • Prefabとスクリプトに対応する.metaが含まれるか。
  • テストシーンを開いてPlayし、説明どおりの結果になるか。
  • Consoleのエラー、PrefabのMissing Script、意図しないOverrideがないか。

この例ではAさんのPRを先にレビュー・マージします。BさんはGitHub DesktopでmainをFetch・Pullし、作業ブランチへ戻ってUpdate from mainを行い、再確認してPushします。その後BさんのPRをレビュー・マージします。

AさんのPRをマージした後、Bさんがmainへ切り替え、Fetch origin、Pull origin、作業ブランチへ戻る、Update from main、Push originを行い、BさんのPRをマージする順序
BさんはmainをPullした後、作業ブランチへ戻ってUpdate from mainを行います。

チェックを外しただけのローカル変更はPCに残ります。Pullやブランチ切り替えの前にChangesを確認し、必要な変更はCommitまたは一時退避します。不要なテスト変更だけを破棄するときも、対象ファイルと差分を確認します。

STEP 6：共有シーンを統合担当が更新する

両担当のPrefabがmainに入ったら、Aさんは最新のmainからfeature/integrate-sceneを作ります。このブランチで初めてMainScene.unityの正式な配置を行います。Bさんは同時にこのシーンを編集しません。

  1. PlayerのPrefabを配置し、シーン上のインスタンスにTag = Playerを指定します。Prefab本体へApplyするかどうかは変更の意図を確認して決めます。
  2. CoinのPrefabを3個、CoinCounterのPrefabを1個配置し、Cameraから全て見えるようにします。
  3. Playで移動、接触、Coins: 1 / 3から3 / 3までの表示、最後のCLEAR!を確認します。
  4. シーンを保存し、MainScene.unityの差分に意図した配置と設定だけが含まれることを確認します。
  5. 統合PRを作り、Bさんがレビューしてからマージします。2人とも最新のmainをPullし、各自のPCで完成条件を確認します。

シーンの競合を減らすために担当を決めていますが、担当者を固定すること自体が目的ではありません。引き継ぐときは、作業ブランチ、未Commitの変更、テスト結果を伝え、同じシーンを同時に編集しない状態にします。

継続して開発するときの確認

  • テストシーンは「誰がどの機能を試すか」で分け、使わなくなったものはPRで整理します。チームで再現する価値があるものを残します。
  • Prefabの単体確認、担当別シーンでの動作確認、統合シーンでの全体確認を混同せず、PRごとに何を確認したか書きます。
  • 繰り返し失敗を検出したい移動や接触の動作は、必要に応じてUnity Test FrameworkのPlay Modeテストに移します。
  • 共有シーンに変更が必要な場合は担当者と対象ブランチを決め、レビュー付きのPRで反映します。複雑なシーンの競合が起きたら、差分を読み、必要に応じてUnityYAMLMergeも検討します。

実習記事との違い

項目6ステップの実習記事この実務フロー
動作確認MainScene.unityで一時的に試し、テスト用変更を破棄担当別テストシーンを保存し、必要ならPRで共有
Prefab担当別に作成Prefab ModeとOverrideを意識して編集
共有シーン最後にAさんが統合統合担当を決め、シーンの差分と動作をレビュー
確認の記録手動でPlayPRに再現手順と結果を残し、必要なものをPlay Modeテストに移行

どちらも同じ小さなゲームを題材にしています。実習記事で分担とPRの順序をつかんだら、この手順で「確認を残し、次の変更でも使える」開発へ進んでください。

公式資料

訪問数 3 回, 今日の訪問数 3回

広告

Git,Unity,Unity6,チーム開発,バージョン管理,開発ツール

Posted by hidepon