VRC向けワールド制作におけるGitの扱いについて
概要
複数人でのVRChatのワールド制作において、unityPackage以外の互いに共有できるツールの存在は不可欠です。その際に候補として上がるのが、Gitを使ったVer管理を使ったやり方です。
この記事では、Gitを使ったワールド制作をする際に、何をおこなえば良いかを最低限を知る事が出来、その際に注意すべき事、何を共有する必要があるかなどを記述しています。
対象読者
こういう人達に向けています
VRCのコンテンツの作成に、Gitを導入したいが、どんな事をする必要があるかわからない
導入記事でツールの導入は出来るがその後がどうすればいいかわからない
ワールドを複数人で作るのに.unitypackage以外の共有方法を知りたい
この記事で目指すべきところ
ワールド作成を複数人でする際に、.unityPackage以外の選択をとれるようにする事
Gitに慣れ親しむきっかけになる事
ざっくりどういった事は行う必要があるかが把握できる事
この記事では取り扱わない事
厳密に正確な事をいうとな説明
結果的にさらに別の事を追記しなくてはいけなくなり、少しでも減らすために、わかりやすい言い方に変更しています。
特に用語説明などは意図的に、行っています
興味を持った際は、ぜひ調べてみてください
Gitのセットアップの仕方（セットアップの仕方については、他の方の記事のリンクを貼っておきます。）
GitHubDeskTopの使い方（これは他の記事等があるので、そちらで実際に試してみてください）
開発環境
この記事は開発環境を以下のVerで行われたものです。
Unity 2019.4.31f1
GitHub Desktop 3.3.5
VCC v2.1.4
Gitは、そもそも何か？
Gitは、ざっくり言うとファイルのバージョンを管理し、またその履歴を保持するためのものです。
例えば、Gitの導入記事でよく出てくる
[最新版]提出物.txt
[これが本当に最新版]提出物.txt
提出物Ver1.4.txt
というどれが本当に最新かどうかがわからない状態の管理があるとします。
これらを解消する事が出来ます。
Gitの特徴は
最新の状態を維持できる
前のVerに戻る事ができる
変更履歴・差分を見る事ができる
の管理を可能にすることです。
Gitの何が便利なのか？
先ほどのGitの特徴としてあげたものが大きなGitの便利な所です。
もう少し深ぼっていってみましょう
最新の状態を維持できる
Gitを使うと、最初に示したように、Ver○○みたいなファイル管理からとは決別できます。
例えば、○○.txtというファイルがあったとします。
これまでは、これらをVer別にファイルが別途必要でした。
これが、この○○.txtというファイルだけで済みます。
いつでも前のVerに戻る事ができる
何か作業をやっている時に、特定の手法や、やり方などを試す際に、既存のファイルに対して変更をしたいなって思ったとします。
よくあるやり方だと、何か試したいと思った際よくあるものが、それと同じコピーを作成して、それで試してだめだったら、それを消すという事をするかと思います。
Gitを使う事で、これらをせずに同一のファイルで行う事が出来、ダメだったってなればそれの変更を取り消すみたいな事が出来ます。
変更履歴・差分を見る事ができる
プログラムなどのテキストベースのファイルに関しては、非常に便利な機能です。
例えば、何かの機能を実装したとしましょう。
その機能を実装し終えた際に、何を変更したのかを覚えている人はいるでしょうか？その答えはNoです。
部分的に覚えている事はあっても、事細かに、何行目等までは把握しきれていないかと思います。
差分を把握する事で、新しい機能の実装の際に、どういった変更を自分が把握出来る事で、後で、その変更が正しいか？何か不要なものがないかなども確認する事が出来たりします。
また、「適切にコミット」していれば、履歴として残るので、これまでの自分の軌跡なども後で見る事につながります。
用語説明
いよいよ、Gitを使った開発を始めるための手順と行きたいのですが、Gitは便利な反面初めての人にはハードルが少し高いものです。
まして、Unityという環境下では、.sceneファイル、.prefabファイルといったものをはじめとする単純なテキストと比べて、さらに難易度が上がっています。
まして、VRC環境という特殊性が加わるため、さらにハードルが上がっている状態なのです。
その上、新しい用語ばかり出てくると、大変なので、一旦把握してほしいものを以下に列挙して説明を入れています。
イメージだけでも把握しておくと、理解がより進むと思いますので、ぜひ確認してから、次へお進みください。
内容としては以下の用語です。
GitHub
GithubDesktop
リモートリポジトリ
ローカルリポジトリ
コミット
プル
プッシュ
上記のものを図で表すと以下のような図になります。
GitHub
Gitを使う時に、よく利用されるサービスです。
しかし、これはGitとは別のもので、Gitに特化したインターネット上のデータアップロード先（リモートリポジトリ）のようなものです。
なので、Gitを使って、リモートリポジトリに対して、アップロード（プッシュ）や、ダウンロード（プル）を行うようなイメージです。
GitHubDesktop
Gitを扱いやすくするためのGUIのアプリケーションです。
また、Githubとの連携が簡単なのでおすすめです。
GitHubDesktopなどのGUIのアプリケーションを使わない場合、コマンドを打つ事になり、心折れてしまうので、素直に使う事をお勧めします。
いや、私はコマンドで行くぞ！って方以外は、ぜひ使ってみましょう。
リモートリポジトリ
インターネット上にあるデータを保存する場所のようなものです。
そして、共同で作業している人達もアクセスでき、変更を適用出来る場所でもあります。
プッシュを行う事で、ここに自分がコミットしてきたものが適用される事になります。
逆に言えば、プッシュをするまでは、全て自分だけの出来事なので、人に影響を与えません。
ローカルリポジトリ
リモートリポジトリと違い、自分だけのリポジトリの事です。
コミットを行う事で、変更していった内容がここに履歴として、蓄えられていきます。
プッシュを行う事によって、リモートリポジトリに変更した内容を適用する事になります。
コミット
ローカルリポジトリに対して、変更履歴として積み上げていく事です。
1コミットあたり、そのコミットで行われた内容と、それに関連するファイルが含まれます。
ゲームでいうならセーブ地点のような認識に近いかと思われます。
また、作業状態を戻す際にも、特定のコミットの地点まで戻すなどが出来るので、変更履歴を積み上げる際は、小規模の変更レベルでコミットをしておくと良いです。
例えば、ボタンの処理の追加やPrefabを作成したなどの単位です。
プル
リモートリポジトリの内容をローカルリポジトリに適用する事です。
そのため、リモートリポジトリとローカルリポジトリで、同様のファイルが変更をしていた場合、
「コンフリクト」が発生します。
その場合は、自分側の変更を取り消すなどの対処をして回避する必要があります。
また、上記をしないために、お互いの適用部分をうまく手動で行って変更する方法もありますが、難易度が高いです。
プッシュ
ローカルリポジトリの内容をリモートリポジトリにアップロードする事です。
他の人の環境にも影響を受けるので、プッシュされる内容の中に、アセットやプログラムなどの不足がないようにしましょう。
もし不足があった場合は、相手側の環境で、プルをした場合でも同様の環境になりません。
そのためコミットー＞プッシュという流れで対処する必要があります。
複数人でのチーム制作においての環境セットアップ
この章では、チーム制作でGitを使う際に、やる内容とざっくりの手順を表します。
やる手順としては、以下の通りです。
U#のVerの決定
自分の環境でのGitやGitHubDesktopの準備
リモートリポジトリの作成
最初の環境構築用のコミットとプッシュ
共同制作者を招待する
作成されたリモートリポジトリをクローンする
作業分担のしやすい単位にわける
では具体的にみていきましょう。
U#などのVerの決定
Verは絶対統一しましょう
さらにいえば、途中のVer変更はよほどの事がない限りはトラブルの元になるので、行わない方が良いです。
そのVerでは動かない機能がある等が判明した場合のみ行いましょう。
その場合は、プログラムの作業を止めるくらいの認識で進めた方が良いです。
自分達の作りたいものが、そのVerでもちゃんと動いていそうか？などの情報を踏まえてVerを決めるとよいです。
自分の環境でのGitやGitHubDesktopの準備
今回この部分は、扱わないので、この記事終盤に貼っているリンク等を参考に導入してみてください。
リモートリポジトリの作成
最初の作成に関しては、それなりに手順があるので、先に手順だけ示しておきます。
GithubDesktopで、ローカルリポジトリを作成する。
VCCで、１で作成したローカルリポジトリのフォルダを指定する
最初の環境構築用のコミットとプッシュ
上記の手順は、チーム制作を行うものです。
GithubDesktopでローカルリポジトリを作成する
リモートリポジトリの作成の前に、ローカルリポジトリを作成
1.File-＞NewRepojitoryを行う。
すると以下のものがでてくるので、入力する
この時 Gitignoreの項目はUnityにしておく事をお勧めします。
Name部分には、自分のプロジェクト名を付けましょう
すると、Localpathで指定した箇所に、
以下のファイルが出来ていれば、ローカルリポジトリの準備完了です。
VCCで１で作成したローカルリポジトリを指定する
次に、VCCでUnityProjectを作成していきます。
CreateNewProjectで
ProjectNameに、一つ前で指定したNameと同じ名前を指定し、ProjectLocationで、一つ上の階層を指定しましょう
例えば、VRCProject->testProjectの中に作成したファイルがあるなら、VRCProjectがProjectLocationの最後にきていればよいです。
うまくいっていると、同じ階層下が以下ようになっていると思います。
逆にこれ以外でよくあるのは、testProjectの中にさらにtestProjectといった感じになっている事があります。
その場合は、一つ前の状態のファイルだけを残して削除して再度VCCのプロジェクトを作成しなおしてみてください。
うまく言った状態になったら、一度作成したUnityのプロジェクトを開いてみてください。
開いたら一度閉じて構いません。
最初の環境構築用のコミットとプッシュ
さて、GitHubDesktopの画面に戻ってください。
Unityのプロジェクトを開いた時にファイルが出来たので、以下の画像のようにたくさんのファイルが並んでいるかと思います。
初期だと、全てが選択されている状態になっていますが、一旦チェックボックスの一番上の所を押すと選択が解除されますので、解除してください。
その後以下の階層に該当するファイルを追加してください。
ProjectSettings以下
Packages以下
UdonSharp.meta
UdonSharpDataLocator.asset及び、UdonSharpDataLocator.meta
また、.gignoreのファイルをメモ帳等で開いて以下の一行を追加してください。
そうすると、Assets->Serialized以下のファイルが候補から外れます。
変更をした事で、.gignoreのファイルが候補として上がっているのでチェックを入れて下さい。
次にチェックを入れた状態で左下にある以下の画像のような所を見てみてください。
この部分のSummaryに当たる部分に、環境セットアップ など、この変更履歴が何のためのものかをわかるように入力して、Commit to mainを押してください。
コミットが終ったら、右上にある以下の画像のボタンを押してください。
押すと、以下の画像の画面がでてくるので、Publish repositoryを押しましょう
これでリモートリポジトリの作成が出来ました。
Web上のGithubで確認をしましょう。
右上のアイコンをクリックして、Your repositoriesを選択すれば作成したリモートリポジトリを確認する事が出来ます。
今回でいうならば、NameにいれたtestProjectというリモートリポジトリが出来ていると思います。
共同制作者を招待する
同じ手順でやっていればリモートリポジトリは外部の人からは見る事が出来ない状態になっています。このままだと、共同制作者の方がクローン出来ません。
そこで、Collaboratorsというものを設定する必要があり、設定をすることで、ようやく共同制作をするための準備が整います。
やる事としては、
Web上のGithub上の作成したリモートリポジトリのSetteingsー＞Collavoratorsから追加を行います。
Add Peopleのボタンを押すと以下のものが現れるので、
相手のメールアドレスか、Githubのアカウント名を入力してください。
無事追加がされると、Manage accessの部分に追加した人の名前が追加されます。
作成されたリモートリポジトリをクローンする
無事共同制作者の招待すると、共同制作者側の人は、リモートリポジトリと同じ環境にするためにクローンをする必要があります。
作成されたリモートリポジトリをWeb上のGithubの画面から、Codeのボタンを押してSSHを選択し、赤で隠している内容をコピーします。
GithubDesktopに戻って、File→CloneRepojitoryを選択すると以下の画面が出てきます。
赤線部分に先ほどコピーしたものを張り付けて、自分の保存しておきたいLocalpathを指定します。
無事クローンが出来たら、成功です。
ただ、もう一つだけ作業があります。
今の状態だと、VRChatからくばられているサンプルのVRCWorldにVRCSceneDescriptorというアップロードに必要なコンポーネントが何故かmissingになる場合があります。
これは単純な話で、クローンする側の環境下では、Unityでの作業があります。
Unityを開き、上部メニューのVRChatSDKー＞ReloadSDKをすることで、解決できるので、それで対処してください。
作業分担のしやすい単位にわける
この辺は以前に出したPrefabの記事などを参考にしてもらえると大変嬉しいです。
ただ、その時所属しているチームによって、一番の最適解というものが違います。
なので、一例として、人員環境とそれに対して、行ったやり方を軽く掲載しておきます。
全員プログラマだが、Unityをほとんど触った事がない人がいる状態
前提として、Gitは全員使えるが、Unityに関しては知っている人が半分もいない状態でした。
また、使うアセットは、すでに決まっており、それぞれで購入が出来るものである事が確認が取れている状態でした。
そのため、作成方針が、エリア毎の担当に分け、全てをSceneで最初に分割を行いました。また、最後にまとめるためのSceneを別に用意した状態です。
その上、各作業用のSceneで、Hierarchy上で親がいない状態のPrefabをそれぞれで用意をし、そのPrefabに反映するようにしていきました。
こうする事で、エリア毎でコンフリクトをほぼ気にせずに作業が出来、最終的にまとめる時はPrefabをまとめるようにSceneに持ってくるだけで済む事になりました。
コミットする必要のあるファイル
Gitを使っていく上で、ローカルリポジトリから、リモートリポジトリへとプッシュをしていく事で、相手側でもプルをすると、同様のファイルの状態にする事が出来ます。
ただ、プッシュする際に、必要なファイルが抜けていると、正しく相手も同じ環境にならなかったりします。
しかし、どのファイルをコミットすればいいか？などがわからないという事がよくあります。
そうならないように、ここに記します。
Sceneファイルに関して
基本的には、最初のコミット以降は、行わないで済むなら行わない方がいいという認識でいた方がいいファイルです。
変更自体は出やすいですが、基本的にはPrefab化しておく事でほとんど影響が出ない状態になるはずなので、その運用を目指した方が良いです。
うっかり変更をしてしまう場合がありますが、可能な範囲で、それらはコミットを避けるように運用するとお互いに幸せになる事が多いでしょう。
プログラムに関して
プログラムに関しては、基本的にはプログラムのファイルを１つ作成する度に4つのファイルをコミットする事になります。
.csファイルとその.metaファイル
U＃を動かすために作成される上記に対応した.assetファイルとその.metaファイル
ただ、後半の、.assetファイルに関しては、以下の事を行った際に、それとは関係ない.assetのファイルも差分として出てしまいます。
新規のU＃を作成する
すでに作成したソースコードを変更する
GitHubDesktop上で確認した時に、差分の出方としては以下のような感じで
guidの変更が加わるだけなので、この場合は、コミットをしないで大丈夫です。
Prefabについて
基本的に、コンポーネントや、プログラムでの設定の値の変更があれば、コミットする必要があるファイルです。
そのため、以前の記事でも書いた通り、粒度はかなり重要です。
競合だけはSceneファイルと同様にきおつけましょう。
.metaファイルについて
なんかしらのファイルのインポートや作成した際にセットで追加されるファイル
普段Gitを使わなかったあの頃では意識すら必要はなかったものですが、「必ずコミット」して下さい。
それぞれのファイルに対してのUnity上で持つ必要がある要素がデータとして格納されているため、これを忘れると同じ状態にならない事が、起きる事になります。
リポジトリの運用周りのよく起きる問題とざっくりの解決策
はじめての運用の際で私がやったほうがいいかなと思う事
慣れないうちは、1-2日開発期間に相当する開発内容で、同様のブランチを開いた時に、同じ環境状態になるかどうかの確認をした方が、余計な不安を抱えなくてよいです。
また、万が一何かが起きても、片方の1－2日分の開発期間の被害で済むので、チーム的には最小に済みます。
アセットを同じの使いたいからプッシュしても良い？
駄目です。絶対やめてください。そのアセットを作っているのもどこかで作成したクリエイターです。
Gitであろうが、なんだろうが、共有せずに、お互いに購入した上で、それぞれの環境下で、導入して、プッシュしないようにしましょう。
この辺のものは、追加ファイルとして、一覧に常に表示される事になるので、.gitignoreファイルに追加する事で、候補として出ないようにする事が出来るので、それで間違ってコミットしないようにきおつけてください。
参考
Gitの導入に当たりこの辺を参考にした方が良いというリンク
GithubDeskTopの導入
Gitについて詳しく知りたい人はここを参考