A successful Minecraft Git branching model

Minecraft のセーブデータをバックアップすることの重要性は既に語り尽くされている。しかしその方法についてはあまり議論されていない。恐らく最もメジャーな方法は、Dドライブに年月日のフォルダを作り、その中に定期的に、あるいは手動で、あるいは自動バックアップソフトでコピーをとっているのではないだろうか。最もメジャーな手動モデルには、多くの問題がある。

• バックアップが面倒 バックアップのために、Dドライブのフォルダと.minecraft/savesを開いてコピーしなければいけない。ステップ数が多すぎるのだ。 なおこの問題に限っては、自動バックアップソフトを使えば解決できる可能性がある。
• 時間がかかる minecraftのセーブデータは決して小さいとはいえず、バックアップに時間がかかる。これはどれくらいチャンクが生成されているかに依存するため、長くプレイしているマップほど（＝バックアップが重要なマップほど）、時間がかかる。
• 続かない 面倒で時間がかかることはやりたくないものだ。
• レストアが自動化されていない データの破損ならコピーするだけだが、minecraftやMODのバージョンアップの不具合だった場合、その時のminecraft.jarのバージョンやMODの構成を忠実に再現しなければならない。特に、多くのMODを入れていると、レストアに失敗した時どれが原因かの判断が困難になる。 各バージョンとMODをバックアップするのもまた常識になっているだろうが、それにしたって、
  1. セーブデータをレストアする
  2. modsディレクトリをレストアする
  3. minecraft.jar をレストア（し、前提MODをインストール）する

  という3ステップかかる。まさか、毎回modsとminecraft.jarをフルコピーするわけにはいかないよね。

• バックアップ頻度 バックアップする頻度についての指針がない。数週間、数ヶ月巻き戻ったという話しをきくこともあるが、これはバックアップをそれだけサボっていたか、ここ最近間違った方法でバックアップしていて、バックアップデータが壊れていたのだ。
• Dドライブなんてない

  とにかくバックアップは苦痛に満ち満ちている。その割に、私達になんのメリットも与えない（障害が発生した場合の復旧はメリットではなく、事故の回避である）。そのため、実際には多くの人がバックアップを行わず、目先の匠にばかり気を取られ、自分のミスでワールドを破壊してしまうのである。

多くのMODを使用するのはとても大変なことだ。特に、minecraftのバージョンアップがあれば、それらの競合を気にしながら、全てをインストールし直さなければならない、最もポピュラーなMODの管理方法は、恐らくmodsディレクトリに単に入っているというものではないだろうか。もちろんバージョンアップ前には書き戻すために一時的にバックアップはするし、懸命な人なら各MODもバックアップしているだろう。それがどれほど苦痛に満ちた作業で、また不確実かというのは前節で確認した。簡単にまとめると

• すべてのMODの過去又は一つ前のバージョンを所持しておく必要がある MODは直ちに問題がおこらなくても、潜在的にプレイに致命的な競合や不具合を起こすことがある。そのため、長い期間にわたって過去のバージョンを所持しておく必要がある
• バックアップがより重要になる MODはmojangによって検証されておらず、無償で作成されているため品質の保証もなく、ワールドを破壊する可能性がある。 現に、殆どのMODの注意書きには導入前にバックアップを取ることと明記されている
• レストアするときに、そのデータで導入していた全てのMODを再現しないといけない バックアップの説で触れた。これはMODが多ければ多いほど時間がかかる。

マルチサーバに遊びに行くと、クライアントMODとサーバMODが競合して入れないことがありうる。また、クライアントかサーバのバージョンが低いこともある。したがって最悪のケースだと、(普段遊びに行くサーバ+シングルのワールド)個環境が必要となる。これらを手動でミスなく管理するのはある種の才能と時間が必要になってくる。 また、シングルでも別々のワールドで別々のMODを使って遊びたい場合にも同じように環境が増えることになる（SkyblockのようなワールドデータやTerraFirmaCraftのような一部MOD等）。 これらを容易にするために環境を切り替えるランチャを使うのが主流になっているが、これは分離された複数の環境から任意のminecraft.jarを起動するためのものであって、その管理自体を助けるものではない。

Minecraft のバージョンが上がったときは今まで通りには行かない。

1. masterブランチに入り、マインクラフトを起動し、バージョンを上げる。
2. 最新版になったところでコミット。バージョン番号のタグをつけておくことをおすすめする。
3. ワールドブランチに移動して、masterとマージする。そのさいminecraft.jar等がコンフリクトするが、全てmasterのほうを採用すること（でないとバージョンが上がらない）。
4. 起動してバージョンが上がっていることを確認。ワールドに入れることを確認したらマージ内容をコミット。

というステップを踏むことになる。 minecraft のバージョンアップ作業自体は、ブランチの数にかかわらず一度だけ、masterブランチで行うという点に注意。

こうすることの利点は、タグ「mc1.2.5」とワールドブランチ my-world の merge base を探せば、バージョンアップした時の最初のリビジョンがわかることだ。さらに、minecraft.jarをバージョン管理下に置いているので、古いバージョンでプレイしていた頃のリビジョンをチェックアウトしたら、その時のminecraft.jarが復元される。

minecraftを終了した時をおすすめする。

複数の作業を同時にしてしまうこともあるだろうが、これもよしとする。普Gitではこれは行儀の悪いことだが、それはあとから問題点を把握しやすいようにするためだ。Minecraftでは、トラップタワーいつの間にか動かなくなっていたことにあとから気づいた時、git bisectでどのリビジョンに問題があったかを確認したいことは恐らく無い（メリットがない）。また、大規模建築を別のブランチでやって、うまくいったら本筋にマージということも事実上不可能だ。ワールドブランチが二本以上に分かれることは、基本的にありえない。

したがって、コミットの粒度が高くてもそんなに意味もないので、せいぜい１日に１度かおおくて数度、バックアップのためにやっておくくらいで良い。特筆すべきことは、コミットは数秒で終わるということだ。Minecraftではいくつかのチャンクが入ったファイルが複数個生成され、更新のあったチャンクの含まれるファイルだけが変更される。Gitは変更のあったものだけをコミットするので、バックアップという意味でも無駄が少ない。

もちろん核爆弾を使う時など、データを巻き戻したくなりそうなときは一度事前にコミットしておくと良いだろう。とにかく、建築を一旦置いてエンチャントするために経験値トラップに行く前に一度シャットダウンしてコミットする必要は無い。コミットメッセージには日記を書いてもいいし、今日の晩御飯を書いても良いだろう。

ここで言う前提MODとは、minecraft.jarを書き換えるすべてのMODのことだ。前提MODでなくてもそのようなMODはあるが、ここではそういうものも前提MODとして話を進める。 前提MODは管理が難しく、気をつけていないとどのバージョンのminecraft forgeをインストールしたか忘れてしまうことがある。forgeはバージョンをタイトル画面に表示してくれるけどね。

前提MODブランチは、masterから派生させて作る。ここでは、Minecraft forgeをインストールしよう。

$ git checkout -b mcforge master

そして、いつもどおり Minecraft を起動して、Minecraft forgeが正常にインストールされたことを確認してコミットする。

Minecraft forgeについては、二つだけ追加の注意事項がある。

1. forgeがダウンロードしてくるjarファイルがいくつか入るが、それもコミットすること。同じファイルを何度もダウンロードしてしまうからだ。
2. modsディレクトリを作成しておくこと。また、空のディレクトリはコミットできないので、空ファイルemptyを作成しておく。これは、他のMODのために必要なことだ。

   $ mkdir ~/.minecraft/mods
   $ touch ~/.minecraft/mods/empty
   

いわゆるMOD LoaderやForge MOD Loader(FML)が必要なMOD。殆どのMODはこれにあたる。 この種類のMODは時に数十個を超えるが、全てのMODについてブランチを作成する。そして、各ワールドブランチに必要なMODをマージする。MODが別のMODに依存している場合は、そのMODブランチから分岐したブランチを作成する。複数のMODに依存している場合は、どちらかから分岐させた後、もう一つのブランチをマージしよう。そうやってリビジョンの親子関係でMODの依存関係を表現することで、コンフリクトを最小限に抑え、ストレージ容量の節約にもなる。 ワールドブランチではコミット粒度はどうでもいいと書いたが、他のブランチでは重要になってくる。ソースコードの管理のように、バージョンアップや設定変更のたびに細かくコミットすること。