伺か・伺的 [第2会場] Advent Calendar 2025 - Adventar の18日の記事です。前後はブランクなのであとはよろしくお願いします。
要約
ゴーストの構成
今までどうしていたのか
Dropboxを使っていろんなPCにファイルを同期させていた。
ファイルをうっかり消したり、余計なファイルを編集したとしても、履歴機能である程度は遡れる。
開発ツールは任意のテキストエディタとデバッガーの玉。
ネットワーク更新やNarファイルの作成はゴースト配布系自動化システム
そのやり方のしんどいポイント
- どのファイルに何の変更を加えたのかわかりにくい
- 複数のファイルを変更したときに戻しにくい
- システム辞書の更新が手動
解消していきましょう
- 対象: ファイルの管理、エディタの変更
- 対象外: ネットワーク更新やNarファイルの作成
用意するもの
アカウント作って、リモートリポジトリ（保存場所）を作成する。
リモートリポジトリは Public と Private が選べるから用途に応じて使い分けよう。
ゴーストマスカレードやプライベート用のゴーストは後者の Private がおすすめ。
Git でバージョン管理
初期設定
各ゴーストにつき1回やるイメージ。
リモートリポジトリをクローンする
- 自分のPC(= ローカル)の適当な場所に作業フォルダを作成する
- 例
C:\workspace
- ターミナルで
git clone リモートリポジトリのURL
- リモートリポジトリの名前でフォルダができているのを確認する
ゴースト関係のファイルを上のフォルダに移す
移した段階でコミットしておく。
- セーブデータや追加シェルなどは
.gitignore に追加すると、バージョン管理の対象外にできる
.gitignore の例
セーブデータやOSが自動生成するものを中心に除外する。
この辺は個人の環境によって変わるので参考程度に。
.DS_Store
/ghost/master/yaya_variable.cfg
/ghost/master/profile/
/shell/master/profile/
/ghost/master/messagetxt/*.bak
updates2.dau
updates.txt
git submodule でシステム辞書を引っ張ってくる（任意）
初回は submodule としてシステム辞書を追加する。
git submodule add https://github.com/YAYA-shiori/yaya-dic.git system
更新は git submodule update --remote で最新版を取得できる。取得後、変更をコミットしておこう。
あやりりすを使っていない人はゴーストとは別のフォルダに git clone して、必要なファイルだけコピーする方法をとるのもあり。
ブランチの使い分けを考える
git のブランチ戦略で調べるとかなり出てくる。
GitHub Flow を参考に簡略化したもので回している。
- main ブランチ: ちゃんと動くゴーストの辞書が格納されている
- feature ブランチ: main ブランチから生やすランダムトークや新イベント追加作業中のブランチ。ネットワーク更新まで終わったら main ブランチにマージする
- bugfix ブランチ: main ブランチから生やすバグ修正用ブランチ。ネットワーク更新まで終わったら main ブランチにマージする
こんな感じで。
- main ブランチは動作が保証できるもの
- 作業するときは main ブランチから派生して何かブランチを作る
ぐらいでいいと思う。
こうすることで何か作業中に誤字報告を受けても、作業中の内容は保持したまま、誤字脱字だけ修正した更新ができる。
開発環境と実行環境を繋ぐ
SSPのフォルダわけ機能を使う
workspace にゴーストしか入ってない場合はこれで登録するのが確実。
シンボリック機能を使う
workspace にゴースト以外も入っている場合などはこちら。
実行には管理者権限が必要、パスは適宜読み替えて。
mklink /d "C:\ssp\ghost\my_ghost" "C:\workspace\my_ghost"
my_ghost : ゴーストのフォルダ名C:\ssp\ghost\ : ゴーストのインストールされるフォルダ。初期設定だとSSP直下の ghost フォルダC:\workspace\ : workspace のパス。この記事通りに作るとCドライブ直下
作業する
日頃のゴースト更新作業 + git のブランチ操作 になる。
main と feature ブランチの差分が見やすいので、変更点がすぐにわかるのが嬉しいところ。
ネットワーク更新まで終わったら、 git commit と git push、GitHub上で Pull Request を作成して、 Merge する。
すぐに終わるものなら main ブランチに直接、 git push しても問題ないと思うけど、何か起きたときに困るのでブランチをわけるようにしよう。
作業のフローを整理
- main からブランチを作成する
- 作業する
- 一区切りついたところで
git commit
- 意図したファイルが対象になっていることを確認する
- 作業した内容がわかりやすくなるようコメントをつける
feat: ランダムトーク追加fix: トークの誤字脱字修正
- 今日はここまで、あるいは作業完了のタイミングで
git push
- GitHub上で Pull Request を作成する
- 問題がなければ Merge する
いわゆる課題管理機能。
バグや追加したい機能はもちろん、思いついたネタのメモに使える。
スマートフォンアプリからも操作できるので、出先でネタをメモするといったこともできる。
FAQ
git コマンド覚えるの大変そう
Visual Studio Code ならボタン操作できる。
GitHub Desktop などもあるので、コマンド苦手でもなんとかなる。
複数のマシンで作業したいときはどうするの？
- 初回: リモートリポジトリから
git clone する
- それ以降: ブランチ切り替えて作業前は
git pull する。作業後は git commit と git push する
conflict した
複数のマシンで作業していて、片方が git push する前にもう片方で作業したりすると発生しやすい。
Visual Studio Code のマージエディタを使って何が正しいか整理しながら、一つずつ解消する。
予防法としては、
- 作業開始前には
git pull をする
- ブランチはこまめに main へマージする
の2点があげられる。
雑感
Gitでバージョン管理するようになって、不具合修正やトークの追加といった小さな作業と辞書の大規模変更のような大きな作業が並行してできるようになった。
作業が終わったらブランチを切り替えれば済む。
ブランチ操作やコミット単位を整理しようとすると、自然に今はランダムトークを追加する、今は不具合修正をする、と思考が切り替わるのも利点だと思う。
この記事を読んで試したいと思った人は、その日はGitHubのアカウントを作る、次の日はリモートリポジトリを作ってみる、と1ステップごと進めてみるとよいのではないかな、と。
