はじめに
弊社ではソースコントロールツールにPerforceを使用していました。
Perforceでソースを管理しながら、1つのプロジェクトのversion1.0.0をリリースするまでやってきましたが、リリースしたタイミングでGitへの移行を開始しました。
Perforceをやめた理由としては、
- ドキュメントが少ない
- 無料枠の範囲で使用していたが、規模が拡大した時のコストが許容できない
- Depotがただのプロジェクトバックアップのような使い方になっていた
- ワークフローを最適にすることができなかった（これは完全に自分のせいですが、ドキュメントの少なさ、コミュニティの規模も関係しているかと思います）
以上が移行するきっかけになった大きな理由です。
弊社にはインターンシップのメンバーもいるのですが、教育の一環として「キャリア形成的にもGitの使い方を知っておいた方がいいのでは」という思いが頭の片隅にあったことも要因です。
チームでGitを使い始めて3ヶ月ほど経ちましたが、Gitのコミュニティの大きさ、ロジカルなワークフローに基づいた堅牢な開発環境に触れることで、改めてGitの強力さを実感しました。
ワークフローについて
様々な文献を読み漁り、自分なりにワークフローを最適にしていった結果、しばらくは今の運用で問題なく開発を進められています。
しかし、実際UEでどのようなGitの運用をしているかの記事は中々見つからず、Git移行直後の初心者の私にはハードルが高かったです。
今後、UE × Gitを使う人が増えることを願って、より具体的な運用例を示せたらいいなと思っています。
とは言っても、今回紹介する弊社のGit運用法はGitを触って3ヶ月の初心者が考えた一例ですので、参考程度に温かい目で見てください。
環境概要
各ツールについて順番に説明していきます。
Notion
主にタスクの1次受けとして使用しています。
弊社の都合上、どうしてもNotionを介入させる必要があるため、issueに書くほどでもない簡単な自分メモ的な役割と、そこからissueを作成するための1次受けとして使っています。
特に理由がなければGithubのProjects機能で十分だと思います。
Github
issueとプルリクの作成、レビューのやり取りを行っています。
Githubに関してはまだ使いこなせていない感があるので、もう少し機能を調べたいと思っています。
もしかしたらプロバイダーもGithubより相性のいいものがあるかもしれません。
とりあえずで使っていますね。
Git LFS
この機能がなかったらGitを採用していなかったと断言できるほど重要です。
また、UEでの共同開発で絶対に必要だと思っていたのがファイルロック機能です。
Gitにはロック機能はありませんが、UEを使う上で必須なGit LFSについてくる機能だったので、一石二鳥的な感じでラッキーでした。
UEGitPlugin
このプラグインについては、Alcheの川さんの記事がとても参考になるのでそちらを見てください。
このプラグインがなくてもGitでの開発はできるっちゃできますが・・・。
例えるなら今の生活から家電を抜いた生活ができますか？って感じです。
もはや公式にしてほしい程重要なプラグインです。
てゆーか公式のGitプラグインはいつまでベータバージョンなんだ？
Git Bash & Sourcetree
Gitクライアントはメンバーの好きなものを使ってもらっています。
言ってしまえばただの開発手段なので、本人が一番効率良く開発できるものを選択してもらうのが最善だと思います。
と、メンバーには説明しましたが、CUIならGit Bash、GUIならSourcetreeに二極化しました。
私は最初Sourcetreeを使っていましたが、CUIの方が速そう & GUIだとどんなコマンドを実行しているか意識しない & コマンドカタカタ？ええやん( •´ω•`)ということで途中からBashにしました。
社内ドキュメントもCUIで整備したので、Gitを全く触ったことがない人にはBashから始めることを勧めています。
開発の流れ
弊社の開発の流れです。
Notionのタスクは基本私が登録していますが、気づいたらメンバーにも登録するよう日頃から促しています。
Notionに登録する時点でおおまかな仕様、開発方針と担当者の決定をします。
プルリクのレビュアーもマージ承認もそのときいるメンバーが誰でもやっていい方針にしています。
- Notionからタスクを選択し、Githubでissue化する
- developブランチからfeatureブランチを作成する
- 開発を進め、適度にコミットする
- 完成したらプッシュし、プルリクを作成する
- レビュアーに確認してもらい、修正があればそのプルリク内でやり取りを行う
- 問題なければdevelopブランチにマージする
- issueを閉じ、1に戻る
UE内でのGit操作
UEで行っているGitの操作はほとんどないです。
ファイルのロックとアンロック、差分表示くらいですね。
コミットやプル、プッシュなど、ほとんどの操作をGit BashかSourcetreeで行っています。
ブランチの運用ルール
Git-flowをベースに、少し簡略化したものを採用しています。
Git-flowのようにあまり複雑にしすぎるとスピード感が落ちると判断したため、Git-flowを壊しすぎず、できるだけシンプルにしたつもりです。
main
リリースバージョン管理用のブランチです。
このブランチでは開発を行いません。
実際にストアにリリースする用のブランチで、リリースしたらバージョンのタグを付けます。
分岐元はなく、マージ先はありません。
release
リリース準備用のブランチです。
Shipping用の設定にするだけで、基本的に開発は行いません。
release準備中に修正したい点が出てきた場合はfeatureで行い、終わった後developからマージします。
mainにマージした後は削除します。
分岐元はdevelopで、マージ先はmainです。
develop
開発用のブランチです。
このブランチで開発は行いません。
リリース前の最新バージョンとして存在し、できるだけバグがない状態を保ちます。
分岐元はなく、マージ先はありません。
feature
機能開発用のブランチです。
新しい機能、バグ修正など、実際にアセットを編集する場合は全てこのブランチを作成してから行います。
developにマージした後は削除します。
分岐元はdevelopで、マージ先はdevelopです。
issueとPull Request
両方ともテンプレートを作成し、メンバーで内容を共有しやすくしています。
記入する項目が多くても良くないし、書かなすぎもレビュー時の手間になるので、難しいところです。
今はレビュー時に「もう少し細かく書いて」と本人の意識を全員に合わせる方向でやっていますが、もしかしたらテンプレートをいじって仕組みで解決しなければならないかもしれません。
issueテンプレート
Pull Requestテンプレート
まとめ
自分的には具体的にGitの運用例を書いたつもりですが、「まだまだ実用的じゃねーなぁ！？おいらの神ワークフローを教えてやんよぉ！！！」と、自分たちのワークフローをさらけ出してくれる愉快な猛者を待っています。
私たちのような小規模のチームで、ルールをカチコチに固めることはスピード感を損ねる原因になりかねないので、あまり明確にルールを定めないのがメジャーな気がします。
結局目指すところはチームの総生産力を高めることに尽きるので、PDCAで最適化していくしかありません。
色んな人たちのワークフローを見て、試して、取り入れて、自分たちに一番合うワークフローが見つかればいいですね。