Unityを使ったことのあるみなさんは、Unityで「GitHub」を使えるという話を聞いたことはあっても、使い道がよくわからないという方もいるのではないでしょうか?
そのGitHubの機能を簡単に紹介しつつ、みなさんがUnityを用いてチームで開発する際にGitHubを導入できるようになる方法を本記事ではご紹介します。
Unityをうまく使っていくにあたり、早めから慣れておくことで制作の効率を高められる領域だと思います。
慣れれば慣れるほど効果が高まると思いますのでぜひ早めに着手してみてください!
※こちらの記事は前回の記事の続きにあたります。まずはPart1をご覧ください。
GitHubとUnityを連携するメリット
GitHubとUnityを連携するメリットは、以下のようなものになります。
- Unityのプロジェクトを随時、バージョンで保存しながら編集することができるようになる。それにより編集状況を戻したい場合、任意のバージョンに戻せる
- 複数人で編集状況を共有して、同時に開発ができる
しかし、GitHubが用意している「GitHub for Unity」は、複数人で編集状況を共有する機能がありません(2021年8月現在)。
この記事では、Unityの共同開発をサポートする「SourceTree」というサービスを使い、複数人で同じプロジェクトを使用する方法も紹介します。
この記事の対象は、こんな方です
- GitHubの名前を聞いたことはあるが使い方があまりよくわかっていない方
- Unityでの作品制作や、開発を少しできるようになってきて制作状況に応じてバージョン管理してUnityを扱えるようになりたい方
- チームでUnityを使って制作したいが、Unity上でチームの制作作業を連携させられていない方
- Git管理の最も簡単な方法の一つである、ソースツリーでビジュアライズしたGit管理を導入してみたい方
この記事では、GitHubをUnityに導入した上でのチーム開発の方法や、GitHubで共同制作したプロジェクトをWebにアップロードする方法などは扱いません。
まずは「1.バージョンごとに制作状況を管理できるようになること」「2.複数人で、制作を行えるようになること」の2つに関して扱います。
また、2のチーム開発ができることを目標に含むため、バージョン管理の機能しか含まないGitHub for Unityも、この記事では扱いません。
では早速、説明に入っていきます。
Step6. UnityとSourceTreeの連携
前回は、GitHubとSourceTreeを連携できたところまで作業しました。
Step6以降では、共同編集者と制作具合を可視化する方法や、バージョンを戻す方法を説明します。
SourceTreeでは、Unityでプロジェクトを作ったのちそのプロジェクトのファイルをGitHubに登録することができません。
そのため、手動でファイルを差し込んであげる必要があります。
そのために、まず一つの空のUnityのプロジェクトを作ります。
(必ず空のプロジェクトである必要はありませんが、今回はわかりやすいように、まず空のプロジェクトでやってみます)
今回は説明上分かりやすくするために「unity git renkei」という名前でプロジェクトを作ってみました。
作成したプロジェクトのリスト右の、3点リーダーのようなメニューボタンを開いて「Reveal in Finder」を押すと、そのプロジェクトが保存されているファイルを開くことができます。
(UnityはUnity上での編集を、随時ファイルで保存する形式を取っています。その保存されているファイルがこのフォルダの箇所に保存されています)
また、ソースツリー内からは、左上のワークスペース内のファイルステータスの欄から「Finderで表示(Show in Finder)」を選択すると、フォルダの場所を表示することができます。
Unityのプロジェクトのフォルダを、SourceTreeの保存場所のフォルダに保存します。
ここでは、少し紛らわしいですが「unity git renkei」というUnityのプロジェクトのフォルダから「Unity-Git-renkei」というソースツリーのフォルダに「Assets, Library, Logs, Packages, ProjectSettings, UserSettings」をコピー&ペーストしました。
そうすると、SourceTreeの左下にUnityのプロジェクトのファイルの情報が表示されます。
この「保留中のファイル」の左にあるチェックを選択すると今回登録したデータが全選択できます。
全選択したのち画面上の「コミット」を選択します(コミットの詳しい説明は後述しているので、この時点では作業ができれば大丈夫です)。
そうすると、コミット時のメモを記入できる欄が出るので、任意でメモを記入しコミットを選択します。今回は、first commitとしてみました。
これで、ローカルのファイルにコミットできたことになります。
次に、登録できたコミット(ここでは、先ほどメモした、first commitがあるのがわかります)を選択したまま、ソースツリー上部の「プッシュ(Push)」を選択すると以下のように確認が出るので、OKを押します。
このプッシュという作業によって、現在のデータがサーバーにアップロードされ、他の編集者にも編集状況が保存され見えるようになります(プッシュの詳しい説明は後述しているので、この時点では作業ができれば大丈夫です)。
この後、クローンに移動したプロジェクトをUnityで開きます。
フォルダを移したファイルは、UnityHubのAddから開けます。
先ほどデフォルトのプロジェクトのデータをコピーし、クローンしたファイルを選択しプロジェクトを開くことで、GitHubに同期できるUnityプロジェクトを作成できます。
これで、Unityの更新をした際にフォルダに保存されるファイルを、SourceTreeでGitHub上に更新する設定ができました!!!
ここからは、UnityとGitHubを使って共同編集や、バージョン管理をする方法の説明をしていきます。
以下の順番で説明していきます。
- 共同編集者の招待のやり方
- 自分の編集状況をチームに反映する/他人の編集を自分に反映する
- 共同編集における注意
- 編集の状況を戻すときのやり方
共同編集者の招待の仕方
共同編集者はGitHubから招待します。
GitHubで該当のリポジトリを開き、
「Code/Issues/Pull requests/Actions/Projects/Security/Insights/Settings」とあるメニューの一番右の「Settings」を選択します。
そうすると、以下のような画面になるので左の列のOptionsの一番上「Manage access」を選択します。
Manage accessを選択すると、緑のボタンで「Invite a collaborator」から、以下のようなタブが開き共同編集者を招待できます。
自分の編集状況をチームに反映する/他人の編集を自分に反映する
基本操作「コミット」の説明
GitHubにおけるコミットとは「追加・変更したファイルをGitに登録するためのコマンド」のことです。
コミットでは、Git上に編集状況を保存できますが、この時点ではプロジェクトで作業している場合他の人にコミットした編集状況は保存されません。ローカルで自分の編集状況を保存することのみになります。
GitHubでは、ローカルリポジトリ、リモートリポジトリという概念があります。
チームで共同編集する場合、まず各々がローカルリポジトリにデータを保存し、それをリモートリポジトリに集めるような形になります。
その、ローカルリポジトリに編集状況を保存するのがコミットです。
実際にUnityの編集状況をGitHubにコミットしてみます。
まず、これまでの作ったばかりのUnityプロジェクト(左)に、編集を加えてみます。
今回は、Hierarchyにキューブをいくつか並べ、AssetsにそのPrefabも作ってみました(右)。
Prefabの名前は「Cubeいっぱい」としました。
このプロジェクトを「Save」し、先程のようにUnityHubのReveal in Finderからこのプロジェクトのファイルを開くと、上記の編集がファイル上に保存されていることがわかります。
Assetsに「Cubeいっぱい.Prefab」と、そのメタデータのファイルが反映されています(メタデータの説明は話が逸れてしまうので今回は省略します)。
このデータをコミットします。保留中のファイルで、保存するものを選択しコミットを選択します。
下の欄にコメントを入れられるので任意で入れます(今回は「add CUbes」と入れました)。
追加の確認が出る場合はOKを押します。これで、ローカルリポジトリに現在の編集状況を反映させられました!
基本操作「プッシュ」の説明
GitHubにおけるプッシュとは、ローカルに保存しているリモート上のリポジトリ(編集を保存する場所)に保存することです。
先程コミットしたものを選択し、ソースツリー上部のプッシュを選択すると、上記のように確認が出るのでOKを押します。
これによって、リモートリポジトリに編集状況のデータを保存できました。
変化したところは「origin/master」ラベルが追加された点です。
このラベルは「ブランチ」といいます。
「origin/master」はリモートリポジトリ、「master」はローカルリポジトリを指します。
基本操作「プル」の説明
GitHubにおいて、プルはプッシュと逆の操作のイメージです。
リモートリポジトリという共同編集のデータが蓄積されている場所から、自身のローカルリポジトリにデータを引き出し、Unityに編集状況を反映させることをプルといいます。
共同編集における注意
GitHubを用いて共同で作業する場合には、注意が必要になります。
複数人が同時に同じ作業をしてしまうと「競合(conflict)」と呼ばれる状況になり、誰かの作業状況が反映されなくなったり、編集状況が重なってしまうためにデータが意図しない形になったりして、エラーやバグの理由になることがあります。
この場合、Unity上では「error CS 8300 : Marge conflict marker encounterd」といったエラーがでます。
この競合を回避するための方法はいくつかありますが、簡単な考え方としては作業場所をできるだけ分離することが望ましいです。
以下の考え方によって対処することができます。
- 共通のシーンは一緒にいじらないようにする
- 共通のプレハブは一緒にいじらないようにする
- (プログラムを扱う場合は)プログラムの編集する範囲やプログラムによって変更を適用する範囲をあらかじめ確認して、作業箇所や編集対象を被せないようにする
簡単な例としてはUnityのAssets内に、作業者ごとのフォルダを作りそれぞれで作業を進めつつ、編集状況を合体させる場合や、最終的に統合する際には、作業が重ならないように統合するその担当者のみが作業を行うことによって回避できます。作業者ごとに、フォルダを作りそれぞれその中でシーンや、プレハブ、アセットなどを使うことで競合を回避できます。
(フォルダは、UnityのProjectウィンドウを右クリック>Create>Folderで作成できます)
以下のようなイメージです。
また、シーンやプレハブ、アセットなど、簡単な整理のルールや命名規則を作っておくと、のちの統合で作業がスムーズになります。
例えば以下のような感じです。
- フォルダの階層構造の作り方は全てデータの種類ごとにして、プレハブはプレハブ、マテリアルはマテリアルのフォルダに整理するといったことを、チームの中で決める
- オープニングシーンを「OP」とし、そのOPシーン用のメインキャラを「MainCharacter」として、作業者名を「Sato(例)」とすると「OP_MainCharacter_Sato」のようなファイル名で、名前を見ただけで何用のデータかわかるようにする
こちらの競合に困った場合はいくつかのサイトで解決の仕方が紹介されているので、適宜ご参照ください。
編集の状況を戻すときのやり方
編集の状況はSourceTreeで戻すことができます。
誤ってコミット/プル/プッシュなどをしてしまった場合は以下のような手順で編集できます。
誤ってコミットした場所よりも前の編集箇所の、戻したい場所のコミットを右クリック(macは2本指クリック)します。そこで出たタブの「mainをこのコミットまで戻す(Reset main to this commit)」を選択します。
すると、下の画像のようなタブが出るのでモードを任意の形で選択して、移動を完了させることができます。
Softを選択すると、コミットだけ無かったことにできるので再度同じファイルの中から選択し直してコミットをすることができます。
これにより、任意のコミットを前のコミットまで戻すことができます。
ここまでの長文を読んでくださりありがとうございました!!
ここまでの作業ができると、UnityとGitHubの連携が基本的にはできるようになります!
上記の記事の内容をUnityで扱えると以下ができるようになります。
- ある編集時点の状態に戻したいときに、編集をリセットできる
- 複数人で特定のプロジェクトを進行するのがスムーズできる(編集ごとに毎回Unity packageを出力したり、取り込み直さなくて済むようになる)
Unityをうまく使っていくにあたり、早めに慣れておくことで、制作の効率を高められると思います。慣れれば慣れるほど効果が高まるので、ぜひ早めに着手してみてください!
また、どうしても作業において詰まってしまうことはあるかもしれません。その場合はSTYLYが設けているUnityやSTYLYを使うためのナレッジや疑問解消が蓄積されている「STYLY FORUM」で質問をしてくださったり、GitHubについての記事などをご参照ください。