初心者がUnreal Engine 5でPCゲームを作る Day2 ～ Gitの準備

2024年5月15日 13:34

Day2まとめ

Git LFSやっぱやめた！

クソデカPushをGitに咎められる

UnrealのプロジェクトをGitに置いたところ、Pushでエラーが出た。

this is larger than GitHub's recommended maximum file size of 50.00 MB 
his exceeds GitHub's file size limit of 100.00 MB

ファイルサイズ100MB以上の場合、Pushできない仕様らしい。
具体的には以下2ファイルが引っかかった。

Solution.VC.db(175MB)
Browse.VC.db(1GB)

Gitで大きなファイルを扱うには、エラーメッセージが推奨していた「Git Large File Storage」を導入するのが良いらしい。

remote: error: GH001: Large files detected. You may want to try Git Large Fi

ってエラーメッセージが言ってた。

Git for Windowsを導入

公式サイトからGit Large File Storageをダウンロードしてきてインストーラーを実行する。

Could not find Git; can not register Git LFS.

エラーメッセージで検索。

まずはGitを導入する必要があるらしい。

Git導入を試みると、インストールオプションにそもそもGit LFSも入っていた。

Git Bashから作業ディレクトリにLFSを設定

普段のGit管理にはForkを使っているが、LFS設定にはGit Windowsでの操作が必要そうで、やり方はだいたいコマンドラインで書かれている

カレントワーキングディレクトリを、Git LFSで利用したい既存のリポジトリに変更します

とのことだが、そもそも操作ディレクトリの移動方法がわからないため、調べる。

cdと入力してフォルダをドラッグアンドドロップすればいいらしい。

無事repositoryに移動できた。
(main)と出ている。ブランチ名だ。カレントワーキングディレクトリを変更できたものと思われる。

設定に移る。

Git LFS に自動的にアップロードしたいファイル拡張子の名前を入力します。

と言われている。今回の拡張子は「.db」だが、LFS管理必須の2ファイル以外にも.dbファイルがあるかもしれないので、一旦確認しておく。

検索したところ他のファイルは存在しなかったので、.dbファイルを管理対象にしておく。

$ git lfs track "*.db"

を実行すると、Fork側に.gitattributesファイルが生成されたのが確認できた。
また、dbファイルがgitLFSにより管理され、100MB以上あった容量が数百kbに削減されていることが確認できた。
このままPushしてみる。

クソデカpushが残っていてLFSのpushが反映されない

そんな気はしていた。

LFSのcommitが先に来ればいいのか？
絶対違うだろと思いつつ、rebaseなる操作でコミット順を入れ替えてみたらconflictしたんだけど！？　と怒られた。ですよね。

rebaseをabortする。これではだめそうだ。

過去を改変し、LFSを遡及適用……できない

一度pushしてしまった過去のファイルもLFS化して扱ってくれるように設定できるらしい。やってみる。

$ git lfs migrate import

error running C:\Program Files\Git\mingw64\libexec\git-core\git.exe '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'fetch' 'origin': 'git@github.com: Permission denied (publickey).fatal: Could not read from remote repository.

Please make sure you have the correct access rightsand the repository exists.' 'exit status 128'

コマンドを叩いたら権限がないと怒られた。
sshキーの設定をしていないことが原因と推測する。
Fork初期設定で一度やっているが、gitに紐づくものではなくクライアントに紐づく設定なのでgit bashでも改めてやりなさいということか。

Git Bashでのrepository操作準備

sshの設定をする。

鍵はforkで作ったはずだが一応生成からやっていく。
生成されたキーのディレクトリにforkで使った鍵があった。これをそのまま使えば公開鍵登録の手順はスキップできるはず。

configファイルを生成して編集。指示通り vi configと入れると空行がすべて~で表された、Rogue然としたプリミティブなエディタがコマンドライン上に現れた。これがvimというやつなのか。

入力すべきものをコピペしようとしたらなんかうまくいかない。
ググったところショートカットが違う模様。
コピペのコマンドはShift + Insertらしい。

無事コピペ完了。
が、保存方法がわからない。

Esc→:wq
で保存して終了できた模様。確認のためにvs codeで開いてみると確かに内容が変わっている。せっかくコマンドラインでチャカっと完了させた意味がなくなったかも、と思いつつ閉じる。

ssh-agentを立ち上げ、forkと共用のもので大丈夫かなと思いつつもkeyを追加し、接続を試みると無事Githubのユーザー名が出てきた。
successfully authenticatedとのことだ。よかったよかった。
これでGit Bashを使う準備は完了したはず。

ちょっと脇道　vimについて

信仰心を持って扱われている印象だったのでvimを軽く調べる。

コマンドラインでやってる cd とかそういう奴を使ってゴリゴリとプログラムが作れるぜみたいな感じなのか。
Markdownもそうだが文字を入力して指示を出すことに慣れた人なら親しみやすいのかもしれない。
また触れることがあるかもな。

Vimよりもパンチカードの話の方が興味深かった。かつてのプログラムはカードにあいた穴で管理されていたのか。全然知らんかった。
Timberbornというビーバーの植民地を作るゲームで、ビーバーアンドロイドにパンチカードをぶち込むと性能が向上するという要素があったのを思い出した。
遊んだ当時は意味がわかっておらず、そんなもんかとスルーしていたが、元ネタがわかって嬉しい。ビーバーのローテクさ、アナログ感を示す表現だったんだな。
こういうちょっと深堀りした史実を拾えるとゲームに滋味が増すのでよいなと思った。

過去を改変し、LFSを遡及適用……できない（再）

cd でrepositoryに戻って、再びLFS遡及用のコマンドを叩いてみる。

$ git lfs migrate import

今度はちゃんとコミットが改変されたと出てきた。
このままpushしてみる。せっかくなのでforkに戻らずgit bash上からpush。

$ git push -u origin main:main

とコマンドを叩く。合ってるのかこれで。リポジトリ名のところをoriginと書いたのが不安だ。
Uploading LFS objectsといって1.8GB分のファイル操作が始まったので大丈夫と思って見守る。

Authorization error: (略)/verify
Check that you have proper access to the repository
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
error: failed to push some refs to 'github.com:78redstar/lwf.git'
fatal: unable to write flush packet: Broken pipe

めちゃくちゃエラー出た。
権限がないのは一旦置いておいて、容量制限に引っかかっているように見える。

1GBが上限だった。
南無三。

そもそもなんだこのデブファイル共は

脳死で取り扱っていたが、中身を知っていないと適切な対処ができないのでは。

Solution.VC.db(175MB)
- よくわかんない
Browse.VC.db(1GB)
- Visual Studioに搭載されているIntelliSense(自動補完システム)に関係するファイル

とりあえずVisual Studio関連のファイルであることは判明した。
であるならば、そもそもプロジェクトファイルではないのでGit管理の必要がないのでは。

Pushをresetし、Gitignoreの設定を行う

dbファイルをpushから取り外す作業を行う。
まずはクソデカpushをローカルのみの変更に一旦戻す。

やってみたらリモートブランチとローカルブランチの状態が違いますとconflictするようになった。
どうせ大した操作をしていないので、差分をHard resetしてプロジェクトファイルを作り直した方が手間がなさそうだ。

ブランチを手元の変更ごと消し飛ばした。
LFSの設定ファイルは削除し、新たにgitignoreを設定する。

設定はここから拾ってきた。
そもそもテンプレに入ってるぐらいgitignoreで扱うのが一般的なファイルだった模様。

続いてSpine Runtimeだけ導入してUEのプロジェクトを一旦Pushする。
spine-ue格納。publicフォルダ作ってspine-cpp格納。Build.cs書き換え。
無事Pushが通ったので.dbファイルはちゃんと無視されたようだ。

続いてUEを起動してSpineの再導入。

The following modules are missing or built with a different engine version:

    SpinePlugin
    SpineEditorPlugin

Would you like to rebuild them now?

おいなんでだよテメー。
と思ってビルドしたら昨日と同じくファイルが見つからないと言われていた。
確認してみるとspine-cppを入れる場所を間違えていた。publicフォルダ作ってた時点で気づいてほしい。フォルダを作る必要などなく、すでにあるpublicフォルダに入れるだけなんだよ。

でもちゃんとビルドしてエラーを探れるようになったのでスムーズだった。いいね。

気を取り直してプロジェクト起動。

The following modules are missing or built with a different engine version:

    SpinePlugin
    SpineEditorPlugin

Would you like to rebuild them now?

おいなんでだよテメー。
と思ったがちゃんとrebuildができて起動された。よしよし。

やっと戻ってきた

昨日の地点まで到達した。pushも問題なく完了。

これでようやくUEのプロジェクトファイルをGit管理できるようになった。

さよならGit LFS

メールでLFSの使用通知が来ており、1.7GBで容量超過したのでもう使えませんからねとのこと。Pushに失敗したと思ったらストレージ自体はしっかり食いつぶされていたようだ。
しかも容量を削除するにはrepositoryを一度切りなおす必要があるらしい。

今なら容量も少ないし出来ないことはないが、アセットの都合上ファイルがそれなりに大きくなり、修正も多々あるはずのゲーム開発をするには使い勝手が悪すぎるだろうということで今回のプロジェクトで使うことはないと決め込んだ。
アセットが大きくなってきそうな時は別途やり方を考えよう。

この記事が気に入ったらサポートをしてみませんか？