デスクトップクライアント

インストール

デスクトップクライアントは Windows、macOS (Apple Silicon)、Linux 向けのネイティブアプリケーションです。 Windows、macOS、Linux のインストーラーには uversion CLI も同梱され、すぐに使えるようになります。 /downloads からダウンロードしてください。

Windows

uVersion_x.y.z_x64-setup.exe (署名済み NSIS インストーラー、約25 MB) をダウンロードします。 起動すると、インストーラーは次を行います:

• クライアントを %LOCALAPPDATA%\uVersion にインストール (ユーザー単位、管理者権限は不要)
• インストールフォルダーをユーザー PATH に追加 (uversion.exe CLI が同梱されています)
• スタートメニューにショートカットを作成
• Tauri アップデーターによる自動更新を有効化

Windows の一括展開: MSI

多数の端末に管理ツール (Intune、SCCM、グループポリシーなど) で展開する場合は、NSIS インストーラーではなく MSI を使用してください: uVersion_latest_x64_en-US.msi (安定した URL、常に最新版、約10 MB)。サイレントかつマシン単位のインストール:

msiexec /i uVersion_latest_x64_en-US.msi /qn /norestart

• C:\Program Files\uVersion にインストールします (管理者権限が必要)。 uversion.exe CLI は含まれますが、フォルダーは PATH に 追加されません: ユーザーがターミナルで必要とする場合は、展開ツールで追加してください。
• MSI インストールでは 自動更新はありません: クライアントは展開されたバージョンのままとなり、 一括展開の更新は次の MSI を再展開して行います。これは意図的な仕様です: 内蔵アップデーターは、管理された版の隣にユーザー単位でもう一つのコピーをインストールしてしまうためです。
• サイレントアンインストール: msiexec /x uVersion_latest_x64_en-US.msi /qn

初回起動時、各ユーザーはサーバーアドレスを入力し、証明書のフィンガープリントを検証します。これはユーザーごと、 端末ごとに一度だけです (TLS フィンガープリント を参照)。

macOS (Apple Silicon)

uVersion_x.y.z_macos-arm64.app.zip (約32 MB、Developer ID 署名済みかつ Apple による公証済み) を ダウンロードします。ダブルクリックで解凍し、uVersion.app を /Applications にドラッグ してください。初回起動時、Gatekeeper が自動的に公証を検証し、警告は表示されません。

uversion CLI はアプリ内に同梱されています。初回起動時、クライアントは自動的に ~/.local/bin/uversion へのシンボリックリンクを作成し、~/.zprofile 経由で ~/.local/bin を PATH に追加します: 手動操作は不要です。新しいターミナルを開けば uversion が利用できます。

注意: サポートされるのは Apple Silicon (M1/M2/M3/M4) のみです。Intel バイナリはありません。

Linux

x86_64 向けの形式は AppImage 一つだけです (uVersion_x.y.z_amd64.AppImage、約85 MB)。ポータブルで、依存ライブラリ (libwebkit2gtk、libgtk、libsoup など) を同梱しており、システムへのインストールなしで最近のディストリビューション なら動作します。前提条件: Ubuntu 24.04 以上、Debian 13 以上、または同世代のディストリビューション。 バイナリは新しいシステム C ライブラリを必要とし、AppImage はこの下限を下げません: 同梱しているのはグラフィカル環境で あって、C ライブラリではないからです。

推奨される方法はインストールスクリプトです。sudo なしで:

curl -fSL https://uversion.io/downloads/client/install.sh | sh

魔法のようなことは何もせず、とりわけ権限を要求することは一切しません:

• root での実行、x86_64 以外のアーキテクチャ、バイナリを実行するには古すぎるシステムでは実行を拒否し、 三つのうちどれが問題なのかを伝えます;
• AppImage を ~/Applications/uVersion.AppImage にダウンロードし、届いたものが本当に Linux の実行ファイル であるかを確認したうえで (そうでなければキャプティブポータルやエラーページが保存され実行可能にされ、後で理解しがたい形で 失敗することになります)、一度の操作で配置します。これはすでにコピーが動作していても安全です;
• アプリケーションを起動します。この起動こそがアプリケーションメニューへのエントリを作成するので、実行させておくのが よいでしょう。グラフィカルインターフェースのないリモートセッションでは、代わりに自分のデスクトップから入力すべき正確な コマンドを表示します。

ダウンロードページ から AppImage を手動でダウンロードし、実行可能にして起動することもできます:

chmod +x uVersion_x.y.z_amd64.AppImage
./uVersion_x.y.z_amd64.AppImage

クライアント向けの .deb パッケージはなく、今後も提供されません: dpkg でインストールされた パッケージは dpkg を再び経由しなければ更新できず、そのためバージョンごとに権限昇格が必要になります。これは管理者 権限のない端末では不可能です。AppImage はパスワードなしで自身を置き換えます。一方 サーバー の方は、引き続き .deb パッケージを維持します。

注意: uversion CLI は AppImage 内に同梱されています。初回起動時、クライアントはバイナリを ~/.local/bin/uversion にコピーし、~/.profile 経由で ~/.local/bin を PATH に 追加します (手動操作は不要)。アプリケーションメニューへのエントリも初回起動時に作成されます。理由は同じで、AppImage は ファイルであってインストールではないためです。

初回起動

1. サーバーアドレスと認証情報を入力する

初回起動時、クライアントは Welcome to uVersion と題された ログインページ を表示します。 Server address フィールドは完全な URL を求めているわけではありません: 変更不可の https:// プレフィックス、ホスト、そして ポート (既定は 8443) の三つのブロックに分かれています。 スキームは固定されており、クライアントは http:// を生成できません。ホスト欄に完全なアドレスや host:port を貼り付けると、自動的に二つのフィールドへ振り分けられます。続いて Username と Password を入力し、Sign in をクリックします。

2. サーバーのフィンガープリントを一度だけ検証する

uVersion サーバーは既定で自己署名されているため、ある端末への最初の接続時に Verify server identity が 表示されます: SHA-256 フィンガープリントを、管理者から渡されたものと照合し、Trust this server を クリックしてください。この確認はサーバーごとに一度だけ行われます。もし赤い見出し Server identity changed の下で再び表示された場合、フィンガープリントが変わっています: 確認せずに承認しないでください。 TLS フィンガープリント を参照。

接続後、クライアントはセッションを安全に記憶します。uversion CLI とエディタープラグイン (Unreal、Rider) は 同じ認証情報を自動的に再利用します: 他のどこでもパスワードを入力し直す必要はありません。

リポジトリを開く / クローンする

サインインしても、プロジェクトは何も開きません: リポジトリの一覧は明示的に要求します。同じウィンドウが、プロジェクトを 初めてクローンするときにも、ディスク上にすでにあるワークスペースを開き直すときにも使われます。

1. Open Repository ウィンドウを開く

タブが一つも開かれていない間、Workspace は No repository selected と Open Repository ボタンを表示します。タブが一つ以上あれば、同じ画面はタブバーの + から開けます。このウィンドウは、 アクセスできるリポジトリをプロジェクトごとに 1 枚のカードで一覧表示し、サーバーに一覧を再要求する Refresh ボタンを備えています。

2. クローンする、または既存のワークスペースを開き直す

各カードは、その状態に応じたアクションを提示します:

• Clone: 新しいワークスペースを作成します。カードの Workspace name フィールドが作成されるフォルダー名になり、空のままだとプロジェクト名が使われます。続いて表示されるフォルダー選択では 親 フォルダーを尋ねます: サブフォルダーは uVersion 自身が作成します。
• Clone New: 同じボタンで、このプロジェクトのワークスペースがすでに存在する場合に名前が 変わります。例えばプロジェクトの二つの状態を並べて保持するなど、二度目のクローンにも正当な理由があります。
• Open: この端末上ですでにクローン済みのワークスペースを開き直します。そのパスは カードの下に示されます。タブがすでに開かれている場合は、代わりに Switch to Open Tab が表示されます。
• Open Local Repository... (ウィンドウ下部): すでに .uversion/ を含む フォルダーを指定します。例えばワークスペースを移動した後などに使います。

下部の Download files after clone チェックボックスは既定でオンになっており、クローンに続けてダウンロードを 開始します。今はワークスペースだけを作成し、ファイルは後で取得したい場合はオフにしてください。

3. ダウンロードを見守る

クローンが始まると同時にウィンドウは閉じます。これは意図的な仕様です: 転送は数時間に及ぶことがあり、 あなたを待たせるべきではないからです。進捗はクライアントのヘッダーで続き、終了するとワークスペースのタブが自動的に開きます。 ネットワークが切れても転送はひとりでに再開されるため、何も失われません。

Workspace

ワークスペース とは、サーバーのリポジトリに紐づいたローカルフォルダーです。クライアントは複数のワークスペースを 同時に管理でき、上部のタブバーに表示されます。各ワークスペースは、ローカルフォルダーのルートにある .uversion/ に メタデータを保存します:

• .uversion/config.toml: 唯一本当に重要なファイルです。[workspace] セクションには、 ワークスペースの所有者 (owner)、その識別子、名前、そして last_synced_revision、あなたが同期しているリビジョン が記録されます (.last_sync というファイルはありません)。Unreal エンジンのパスもここに記憶されます。
• .uversion/checkouts_<workspace_id>.json: このワークスペースであなたが保持しているロック
• .uversion/changelists_<workspace_id>.json: あなたの changelist、つまり別々に送信するために まとめたチェックアウト済みファイルの束です。完全にローカルで、サーバーには一切送信されません。
• .uversion/pending_deletes_<workspace_id>.json: 送信待ちの削除
• .uversion/snapshots.json: 既知のファイルの状態。ローカルで変更した内容を検出するために使われます

Files タブ

ワークスペースのファイルをその状態とともにツリー表示します。一覧を絞り込む方法は二つあります:

• 検索フィールド (Search files... と表示): パスの一部で絞り込みます。大文字小文字は区別しません。
• ステータスチップ (すぐ下)。これらはクリック可能なカウンターで、 カウンターが 0 を超えるときだけチップが表示されます: 同期したばかりのワークスペースでは {n} synced しか見えず、他が表示されないのは正常です。表示され得る六つのチップは {n} synced、{n} modified、{n} local only、{n} server only、 {n} locked、{n} deleted です。

検索とチップは組み合わさります: まず検索が範囲を狭め、次にチップが絞り込みます。 数万ファイル規模のプロジェクトでも表示は滑らかなままです。

複数選択 + アクション

アクションバーは何かが選択されているときにだけ現れます。 選択が空の間はボタンが一つもありません: これは正常であり、読み込み中というわけではありません。ファイルを選択すると (クリック + shift、またはチェックボックス)、 保持した数を前置きしたバーが現れます ({n} file(s) selected)。ボタンは選択内容が許すものだけが表示されます:

ボタン	動作
History	対象のファイルまたはフォルダーの履歴を開きます。
Add	local only のファイルを追跡下に置きます。ごく最初の送信における二つのボタンのうち一つ目です: 作成したばかりのファイルはサーバー側には存在せず、ロックすべきものがないためです。
Checkout	ロックを取得します。冪等です: あなたがすでにロックしているファイルを再度ロックしても何も起きません。
Checkin	メッセージのダイアログを開き、送信します。最初の送信における二つ目のボタンであり、以降すべての送信のボタンでもあります。
Revert	ロックを返却し、サーバーのバージョンを復元します。ローカルの変更は失われます。
Delete	ファイルを削除としてマークします。削除は次の checkin で送信されます。
Download	選択したファイルをサーバーから再ダウンロードします。ローカルで壊れたファイルを取り戻すのに便利です。

Pending タブ

現在チェックアウトされ、あなた または 別のユーザーによってロックされているファイル。二つのセクションがあります:

• Your locks: checkin、revert、または個別に release できます
• Other users' locks: 誰がロックを保持しているかが分かり、Production ボードに依頼カード (request バッジ) を作成する Request release ボタンがあります

管理者には、他人のロックに対する Force unlock ボタンも表示されます。これは保持者の同意なしにロックを release します。すべての force unlock は監査されます。

History タブ

リポジトリのコミットをページ分割で一覧表示します。作成者、日付、メッセージ、変更されたファイルが含まれます。 コミットをクリックすると詳細が開きます: そのコミットのファイル全体とそのリビジョンの一覧です。

各コミットの Get all ボタンで、そのリビジョンにおける全ファイルのローカルコピーをダウンロードできます (安定した状態を取り戻すのに便利)。

Production

Production ゾーン (サイドバーの専用エントリ) は、リポジトリごとのプロジェクト管理をまとめます。 Workspace の方は、ファイル (Files、Pending、History) に専念します。

My tasks

あなたに割り当てられたカードの一覧を、アクセスできるすべてのリポジトリにわたって集約したものです。

Board

リポジトリごとのかんばんボードで、列は設定可能です (既定は To Do、In Progress、Review、Done)。各カードは 優先度 (low / normal / high / urgent)、ラベル、担当者、 期限、コメント、アセットやコミットへのリンク、そしてカバー画像を持ちます。

Dashboard

プロデューサーのコックピット: プロジェクトの健全性バナー (未解決のブロッカー、保留中のプレイテストレポート)、 問題が集中するゾーン、今週のコミット、プロジェクトの容量、そして最後に公開されたビルドが並び、各ブロックはボードまたは Games へのリンクになっています。

その下には カレンダータイムライン: マイルストーン、プレイテスト (単発または繰り返し)、 リリース、カードの期限。繰り返しのプレイテストは、その都度ボードのカードを自動的に生成します。

Watchlist

パス (glob パターン) を監視し、それらに触れる check-in の通知を受け取ります。各エントリは、監視するパスと 追跡するイベントを示します。

Games

Games ゾーンは、プロジェクト向けに公開された 内部プレイテストビルド を一覧表示します。 各ビルドは、バージョン、構成 (DebugGame / Development / Shipping)、プラットフォーム (Win64 / Mac / Linux)、サイズ、 リリースノートを示し、プラットフォームに合わせたダウンロードボタンを備えます。

ここは プレイテスター のアクセスポイントです: playtester ロールのアカウントは このページしか見えず (Workspace も Production も見えません)、自分に開かれたプロジェクトのビルドにのみアクセスできます。

ローカル Changelist

📷 Screenshot · client-changelists

二つのローカル changelist (例えば「default」と「review」) に振り分けられたチェックアウト済みファイル。

チェックアウト済みファイルを、複数の独立したコミットにまとめます。changelist はあなたのワークスペースにローカルで (サーバーには一切送信されません)。次のような用途に便利です:

• 重要な修正を作業中のものから切り離す
• すべてを混ぜずに、複数の送信を並行して準備する
• WIP 用の「default」changelist と、checkin に出す「review」を保持する

Settings

クライアントのグローバル設定 (%APPDATA%/uversion/uVersion/config/config.toml に保存):

設定	説明
Default Server address	ログインページを事前入力します。接続時と同じ分割: 固定の https:// プレフィックス、ホスト、ポート。空のままでも構いません。
Default Username	ログインページを事前入力します。
Default Repository Path	クローン時に既定で提案されるフォルダー。
Theme	System / Light / Dark。
Show hidden files	Files タブで . で始まるファイルを表示します。
Auto-sync Interval (seconds)	選択リストではなく数値フィールドで、分ではなく 秒 で指定します。最小は 0 で、0 で無効化 されます (自動同期)。
Parallel Uploads	同時アップロード数、1 から 32 まで。
Parallel Downloads	同時ダウンロード数、1 から 32 まで。
Avatar colour	インターフェース上でのあなたの色 (ボードのカード、ロック、アクティビティ上のイニシャル)。他とは異なり、この設定はサーバー側に保存されます: 端末から端末へあなたに付いて回り、チームメイトからも見えます。

Unreal パネル

クライアントがワークスペース内に Unreal プロジェクトを検出すると、Workspace の右上に専用のアクションバーが現れます。 エディターを開く、コンパイルする、パッケージ化するといった操作を、IDE を介さずにクライアントから直接エンジンに指示します。 ほとんどのアクションは C++ プロジェクトにのみ関係します (純粋な Blueprint プロジェクトはコンパイル不要です)。

プラグインの状態ピル

バーの左端にあるピルは、このプロジェクトにおける Unreal プラグインの状態を示します。クリック可能です:

ピル	意味
Plugin <version> (緑)	プラグインはインストール済みで、あなたの Unreal のバージョンに対して最新です。
Plugin installed (緑)	プラグインがプロジェクトに配置されたばかりです。
Update ready (オレンジ)	より新しいバージョンがあります。クライアントは自動ではインストールしません: Unreal を閉じてから、ピルをクリックしてください。
Restart UE (オレンジ)	Unreal エディターが開いています。読み込まれたプラグインは置き換えられません: エディターを閉じて、もう一度クリックしてください。
Set engine path (オレンジ)	エンジンのパスがありません。クリックするとパス選択が直接開きます。
Plugin n/a (オレンジ)	この Unreal のバージョンとシステムの組み合わせに対して、公開されたバイナリがありません。

エンジンのパス

Unreal のインストールパスは、.uproject の EngineAssociation から自動的に解決されます (Windows レジストリ、LauncherInstalled.dat、またはソースビルド)。このパスは以下のすべてのアクションに 必要で、自動解決はとりわけソースからコンパイルしたエンジンで失敗します。手動で設定する場所は次のとおりです。

1. 二次アクションのメニューを開く

バーには 入力フィールドも、Browse ボタンも、Auto-detect ボタンも 見当たりません。 唯一の入口は、Unreal バーの右端にある 歯車の形のボタン です。小さなシェブロンを伴い、ツールチップには More actions と表示されます。その見た目にはエンジンを思わせるものが何もなく、だからこそ見つからないのです。

2. Set Engine Path... を選ぶ

Set Engine Path... の項目はメニューの最後にあります。そのサブタイトルは現在のパス、 あるいはパスがなければ Not configured を表示します: 問題がそこに起因するかどうかを知る最速の方法です。 フォルダー選択が開き、選んだパスはワークスペースの .uversion/config.toml に保存されます。

Open Editor

ワークスペースのプロジェクトで Unreal エディター (UnrealEditor) を起動します。このボタンは 冪等 です: エディターはウィンドウを表示するまでに数十秒かかることがあり (特に macOS / Linux)、 その間の二度目のクリックで二つ目のインスタンスが開くことはありません。エディターの起動中、ボタンは「Opening…」を 表示します。ローカルで一度もコンパイルされていない C++ プロジェクトでは、エディターを開くとまずプロジェクトファイルの 生成、続いてコンパイルが実行されます (自動アクション を参照)。

Compile

プロジェクトをコンパイルします (Unreal Build Tool)。出力は統合コンソールにリアルタイムで表示されます。C++ プロジェクトは、 エディターで開けるようにするため、またコードの変更を反映するために、コンパイルされる必要があります。

Sync と Status

この二つのボタンは同じバーにあり、Files タブにはありません:

• Sync: ワークスペース全体をサーバーから更新します。保留中のファイルがある場合、その数を ツールチップに表示します。これがクライアントの本当の「sync」であり、選択分しか取得しない Files タブの Download ボタンと混同しないでください。
• Status: 他ユーザーのロックを含めサーバー側の状態を更新し、Sync ボタンの カウンターを更新し直します。

More actions メニュー

より稀なアクションは、バーの右にある歯車の形のボタンの背後にまとめられています (上のスクリーンショット):

• Generate Project Files: IDE のプロジェクトファイル (Visual Studio、Rider) を再生成します。 ソースファイルを追加または削除した後、あるいはクローンの後に便利です。
• Publish Editor Binaries: コンパイルしてから、最新のコードコミットに対応するエディターの バイナリを公開します。チームメイトはそれぞれで再コンパイルする代わりに、sync で取得します。Linux では利用できません。
• Force Sync: ローカルファイルを上書きしながら 再ダウンロードします。 メニューでは赤で示され、overwrites local の注記が付き、確認を伴います。失っても構わないワークスペースに 限定してください。
• Set Engine Path...: 上で説明したエンジンのパス設定。

Package

ボタンの名前は Package です。「Package Game」はそのツールチップに過ぎず、エンジンのパスが 不足しているときは Set Engine Path first に置き換わり、ボタンは無効になります。RunUAT BuildCookRun 経由でゲームをパッケージ化し、結果をワークスペースのルートの Packages/{config}/ にアーカイブします。 三つの構成から選べます:

構成	用途
DebugGame	デバッグビルド (完全なシンボル、最適化なし)。
Development	開発ビルド (既定): 最適化されているが開発ツール付き。
Shipping	配布ビルド: 最適化済み、開発ツールなし。

Packages/ フォルダーは既定で無視されます (.uversionignore): パッケージ化されたものはバージョン管理されず、Publish Build 経由で配布されます。

Publish Build

パッケージ化したビルドを 内部プレイテスト版 として公開します。それはクライアントの Games ページから チームがダウンロードできるようになります (playtester ロール、またはビルドアクセスが付与されている場合)。 クライアントは Packages/{config}/ をスキャンし、ファイルを送信し (サーバー側で重複排除)、続いてマニフェストを 記録します。

Open project folder

ワークスペースのフォルダーをシステムのファイルエクスプローラーで開きます (Windows のエクスプローラー、Finder、または Linux では xdg-open)。

Stop

進行中の すべての ビルドをきれいに中断します: コンパイル と パッケージ化。ボタンは停止した ビルドの数を示します (バックグラウンドで起動された自動コンパイルが含まれることがあります)。

自動アクション

ボタンに加えて、C++ プロジェクトが常に最新でコンパイル可能な状態を保てるよう、クライアントは特定の Unreal アクションを 自動的に実行します:

• check-in の前: コードファイルが変更されていれば、まずプロジェクトがコンパイルされます。コンパイルが 失敗すると、check-in はブロックされます (コンパイルできないコードは送信しません)。
• sync の後: sync がコードをダウンロードした場合、クライアントはプロジェクトファイルを再生成してから 再コンパイルします。
• クローン後の初回起動 (C++ プロジェクト): エディターを開けるようになる前に、プロジェクトファイルの 生成、続いてコンパイルが行われます。

これらの自動ビルドはエンジンのロック (Unreal Build Tool -WaitMutex) の上で直列化されます: 互いに拒否し合う のではなく、順に連なります。Stop ボタンはこれらも中断します。