ShareX Workflow and Versioning

対象範囲

このファイルは、以下に関する Git とバージョン管理のルールを定める唯一の基準です。

• コミットとプッシュのワークフロー
• コミットメッセージの形式
• バージョン更新の動作
• Directory.Build.props の更新

このファイルは、廃止された docs/development/RELEASE_PROCESS.md に優先します。

バージョンの唯一の基準

1. ルートの Directory.Build.props ファイルを、XerahS アプリの作業バージョンの唯一の基準として扱います。
2. XerahS のバージョン付きコミットを行う前に、ルートのバージョンと既存の XerahS の Git タグのうち最も大きいものを比較します。
3. ルートのバージョンが最新のタグを厳密に上回っていない場合は、ブランチに次の未リリースバージョンが反映されるよう、先にルートのバージョンを更新します。
4. 個々の .csproj ファイルでバージョン番号を設定してはいけません。
5. バージョンを更新する際は、XerahS アプリのバージョンを意図的に保持している、リポジトリ内の追跡対象 Directory.Build.props をすべて更新し、値を一致させます。
6. build/windows/chocolatey/xerahs.nuspec などの派生リリースメタデータファイルは、リリースの自動化処理中にルートのバージョンと同期する必要があります。
7. タグ付きリリースでは Chocolatey の .nupkg も生成してスモークテストを実施するため、build/windows/chocolatey/ 内のリリースメタデータは自動化に対応した状態に保つ必要があります。

バージョン更新ポリシー

1. バグ修正：パッチのみを増やします（0.0.z ルール：メジャー／マイナーは維持し、z を増やします）。
2. 新機能：マイナーを増やし、パッチをリセットします。
3. 破壊的変更：メジャーを増やし、マイナー／パッチをリセットします。

必須のコミット前チェック

コミットおよびプッシュの前に、次を実行します。

git pull --recurse-submodules
git submodule update --init --recursive
dotnet build src/desktop/XerahS.sln

ビルドがエラー 0 件で成功した場合にのみ、続行してください。

コミットとプッシュの手順

1. 変更をステージします。

git add .

2. 次の形式でコミットします。

git commit -m "[vX.Y.Z] [Type] concise description"

3. プッシュします。

git push

コミットメッセージのルール

1. XerahS アプリのコミットには、ルートの Directory.Build.props の <Version> を [vX.Y.Z] の形式で付けます。ただし、そのバージョンが既存の XerahS の Git タグのうち最も大きいものを厳密に上回っていることを確認してから付けてください。
2. 最新のタグ以下のバージョンをプレフィックスに使用してはいけません。最新のタグがルートのバージョン以上の場合は、先に Directory.Build.props を更新し、その更新後のバージョンでコミットします。
3. [Fix]、[Feature]、[Build]、[Docs]、[Refactor] などの種別トークンを含めます。
4. 説明は簡潔かつ具体的にします。
5. 共有ライブラリ（例：ShareX.ImageEditor）のみを対象とするサブモジュールのコミットでは、[vX.Y.Z] を省略し、AGENTS.md に従って [Type] description を使用します。

Git フックに関する要件

1. .githooks を有効な状態に保ちます（git config core.hooksPath .githooks）。
2. 緊急時の使用を明示的に依頼された場合を除き、--no-verify でフックを回避してはいけません。
3. フックが失敗した場合は、問題を修正して再度コミットします。

ドキュメントと Git

1. Markdown のドキュメント変更は、関連するコード／設定の変更と一緒にコミットします。
2. 依頼された作業の一部である生成済みの手順ドキュメントを、未コミットのまま残してはいけません。