Unityで無限ランナーを作る：第2回 GitHub連携

はじめに

本記事では、一般的なベストプラクティスを提示するというよりも、今回の個人開発において自分がどう考え、どう割り切って運用したかを中心にまとめています。

方針編：個人開発におけるGitHub運用の考え方

1. なぜ個人開発でもGitHubが必須なのか

個人開発であっても、今回は最初から GitHub を使う前提で進めることにしました。

個人でゲームを作っていると、どうしても作業は断続的になります。
本業や私生活の都合で、数週間、場合によっては数か月触らない期間が発生することも珍しくありません。
そうした前提の中で開発を続けるために、GitHub は欠かせない存在だと考えました。

1.1. 断続する個人開発プロジェクトの再開コストを下げるため

個人開発では、作業を中断したあとに再開する際のコストが意外と高くなりがちです。
コード自体は残っていても、

• 何をやっていたのか
• なぜこの実装になっているのか
• どこで方針を変えたのか

といった経緯が分からず、思い出すだけで時間がかかることがあります。

GitHub にコミット履歴として変更の流れを残しておくことで、コードだけでなく「考えた過程」も含めて振り返ることができます。
これはコード内のコメントとはまた別の「経緯」に関する情報で再開時の負担を大きく下げてくれます。
例えば、コミットメッセージに『なぜそうしたか』を一行書くだけで、数ヶ月後の自分が救われます。

1.2. 気軽に Try & Error できる状態を作るため

個人開発では、思いついたアイデアを気軽に試せることが重要だと思っています。
しかし、履歴管理がない状態だと「正常に動作していたあの時の状態に戻せなくなりそう」といった不安から、試行錯誤そのものを避けてしまいがちです。

GitHub を使っていれば、変更をコミットという単位で区切って残せます。
「とりあえず書いてみる」「ダメなら戻す」という行動が取りやすくなり結果として失敗を恐れずに Try & Error できる状態を作れます。

1.3. コードの変更内容を可視化するため

GitHub では、コードの差分を視覚的に確認できます。
これは単に「変更点が分かる」というだけでなく、「ある機能を追加するために、どのファイルを、どう変更したのか」を後から追いやすい、という点で非常に便利です。
個人開発では「未来の自分に対する説明」が必要になる場面が多く、差分が見えることで振り返りや理解が格段に楽になります。

1.4. 物理的なトラブルに対する保険として

もう一つの理由として、物理的なトラブルへの備えがあります。
ローカルPC上にしか存在しないプロジェクトの場合、ストレージの喪失は同時にプロジェクトの喪失を意味します。

GitHub に push しておくことで、作業端末が壊れてもプロジェクト自体は生き残りますし、新しい作業端末への移行も比較的スムーズに行えます。

1.5. まとめ

今回 GitHub を使う理由は次のような点にあります。

• 作業が長期間にわたり中断された際、再開に必要な作業コストを下げる
  （止まってしまった車輪を再び回し始めるコストは、決して安くありません。）
• 気軽なTry & Errorを実践できる環境の構築
• 変更内容を可視化し、振り返りを楽にするため
• 物理的なトラブルへの保険

ベストプラクティスかどうかは分かりませんが、個人開発を「続けられる状態」に保つためのインフラとして、今回は GitHub を使うことにしました。

2. 個人開発前提のブランチ思想

― 二つの時代 ―

個人開発における Git のブランチ構成は、最初から完成形を目指す必要はありません。
むしろ重要なのは

いまのプロジェクトが、どのフェーズにいるのかを正しく認識すること

だと考えています。
ここでは、個人開発を 二つの時代 に分けて整理します。

2.1 原始フェーズ ― 単ブランチの時代

最初のフェーズでは、躊躇なく削ります。
ブランチ構成も、運用ルールも、極限までシンプルにします。
「正しさ」よりも「前に進めること」を優先します。

このフェーズでは、main ブランチ一本構成で十分に回ります。

なぜ main 一本でよいのか

この段階の個人開発には、次のような特徴があります。

• 仕様が頻繁に変わる
• 実験が短命で、すぐに捨てられる
• 「安定版」という概念がまだ存在しない
• 開発者が自分ひとりで、全体を把握している

この状態で develop や feature/* を導入しても、運用コストの方が先に重くなってしまいます。
ブランチを増やすこと自体が目的になり、「正しい Git 運用をしている感」だけが残ってしまいがちです。

壊してよい実験は、commit 前で完結させます

このフェーズでは、

• 実験は commit 前に行います
• うまくいかなければリセットして戻します
• commit は「作業ログ」として使います

といった割り切りで、ちょうどよいと考えています。
ここで重要なのは

main が汚れること自体は問題ではない

という点です。

問題になるのは、

• どこで壊れたのか分からなくなること
• 何を考えていたのか思い出せなくなること

です。

main 一本構成でも、これらを防げているのであれば、無理にブランチを増やす必要はありません。

2.2 安定運用フェーズ ― 多ブランチの時代

やがて、プロジェクトは次の段階へ進みます。

• ある程度「動く」状態ができてきます
• 数週間触らなくても、まずここから再開したい状態になります
• 人に見せる、動作確認するといった機会が増えてきます

この瞬間、 「壊したくない状態」 が初めて生まれます。
ここで初めて、ブランチを分ける意味が出てきます。

developブランチを作るトリガー

このフェーズでは、次のような構成を取ります。

• main：現在の完成形（安定した状態）
• develop：次の完成形に向けた作業用ブランチ

main は「触っても安心な状態」を保ち、日々の作業は develop で進めていきます。

重要なのは

feature ブランチを恒常的に使い始めるのであれば、同時に develop を作る

という点です。

feature は必ず develop から切る

規模の大きい実験や、数日から数週間かかる変更が増えてきた場合には、feature/* ブランチを作る価値が生まれます。

ただし、ここでルールを一つだけ固定します。

feature ブランチは、必ず develop から派生させます

feature ブランチの派生元が曖昧になると merge 先を誤りやすくなり、結果として main を壊しやすくなります。

2.3 フェーズを見誤らないために

ここまで読んで

• main 一本構成が楽に回っている
• 壊れても特に困っていない
• 実験が短命で済んでいる

という状態であれば、まだ 原始フェーズ にいると考えてよいでしょう。

一方で、

• main を壊したくないと感じ始めた
• 実験をあとで見返したいと思うようになった
• 構造変更が一日で終わらなくなった

これらが当てはまる場合は、安定運用フェーズへ進むサインです。
個人開発において重要なのは、最初から「正しい構成」を選ぶことではありません。
いまのフェーズに合った構成を選び、必要になった瞬間に進化させていくことだと考えています。
次回は、この思想を前提に実際にUnityプロジェクトでどのように運用しているのかを具体例（例えば、Unity用の .gitignore 設定等）とともに書いていく予定です。