開発中

このページでは、リポジトリの構成、コードの編集を開始して最初のプルリクエストを作成する方法、Jellyfinでのプルリクエストに関する一般的な手順について詳しく説明します。

何に取り組むべきですか？

Githubには、レビューして貢献できるJellyfin組織プロジェクトがたくさんあります。まとめると、ここに2つの最大のものがあります。1つはバックグラウンド開発用で、もう1つはフロント開発用です。

• Jellyfinサーバー-Jellyfinアプリケーションのバックエンドサーバー。 .NET Core 3.1とC#を使用して構築されています。
• Jellyfin Web-メインのJellyfinクライアントアプリケーション。 Web用に構築されていますが、このWebクライアントの単なるラッパーである他のクライアントの一部でも使用されています。

各リポジトリには、そのプロジェクトの開始方法に関する独自のドキュメントもあることに注意してください。これは通常、READMEリポジトリにあります。また、組織のソースツリーを表示して、いくつかの大きなプロジェクトの構造を確認することもできます。

実際の開発を開始する最良の方法は、関連するリポジトリ内の問題のリストを調べ、作業したい問題を見つけて、ハッキングを開始することです！問題は管理チームによって定期的にレビューされ、スキルセット内の問題を見つけるのに役立つラベルが割り当てられます。問題の作業を開始したら、不要な作業の重複を避けるために、問題に取り組む意向を示すコメントにコメントしてください。

主な質問の種類

質問の種類のリストは、質問のガイドラインのセクションにあります。

問題がない場合はどうなりますか？

加えたい変更に関連する問題がまだない場合は、まず問題を作成して追跡し、PRが問題を参照していることを確認してください。これは、作成者が見つけて修正したエラーの場合に特に役立ち、元の問題と修正の両方を詳細に文書化して追跡できます。

変更するにはどうすればよいですか？

作業または改善したいものが見つかったら、次のステップは、コードを変更してテストし、GitHubでプルリクエスト（PR）を送信することです。

簡単にするために、すべての例では、開発者がLinuxでGitHubへのSSHアクセスを使用して動作していると想定していますが、一般的な考え方はHTTPベースのGitHubインターフェースに適用でき、WindowsまたはMacOSに変換できます。

Gitに慣れていない場合は、公式ドキュメントを参照して、このバージョン管理システムの仕組みと使用方法を理解することをお勧めします。

リポジトリのコピーを準備する

最初のステップは、貢献したいプロジェクトのGitリポジトリのコピーを作成することです。 Jellyfinは、コントリビューションの「フォーク、機能、広報」モデルに従います。

1. GitHubで、投稿先のJellyfinリポジトリを、対応するリポジトリの「フォーク」ボタンを使用して自分のユーザーアカウントに「フォーク」します。
2. ローカルマシンでフォークを複製し、ディレクトリを入力します。git clone git@github.com：yourusername / projectname.gitcd projectname /
3. メインプロジェクトから変更を簡単にダウンロードできる「アップストリーム」リモートを追加します。git remote addアップストリームgit@github.com：jellyfin / projectname.git
4. Gitサブモジュールを初期化します。ほとんどのプロジェクトには、少なくとも1つのGitサブモジュールの更新があります–initNoteAサブモジュール内のファイルの編集は避けてください。これを行うと、作業の上書きなど、望ましくない副作用が発生する可能性があります。常に、別の場所にある独自の複製されたリポジトリーでサブモジュールを変更します。
5. Jellyfin.Serverプロジェクトを正常に実行するには、サーバープロジェクトとWebクライアントプロジェクトの両方をチェックします。
6. YarnまたはNPMを使用してJellyfin Webプロジェクトをビルドし、結果のdistフォルダーの場所をコピーします。 Jellyfin.Serverプロジェクトに、JELLYFIN_WEB_DIRと呼ばれる環境変数を追加し、値をdistフォルダーの絶対パスに設定します。

これで、プロジェクトの構築または変更を開始する準備ができました。

リポジトリに変更を加える

デポジットを取得したら、仕事に取り掛かれます。

1. アップストリームマスターに対してローカルブランチを中継して、最新の変更を処理します。git fetch –allgit rebaseアップストリーム/マスター
2. マスターのローカル機能ブランチを作成して変更を加えます。git checkout -b my-feature master
3. このローカル機能ブランチで変更とコミットを行います。
4. 作業が終了したら、ローカルブランチオフィスで手順1を繰り返し、宣言してから他の作業と競合しないようにします。
5. ローカル機能ブランチをGitHubフォークにアップロードします。git push –set-upstream origin my-feature
6. GitHubで、以下のアドバイスに従って、アップドラフトマスターブランチに対して新しいRPを作成します。
7. RPがマージされたら、ローカルブランチを最新の状態に保つようにしてください：git fetch –allgit checkout mastergit rebaseアップストリーム/ mastergit push -u origin master
8. ローカル機能のブランチが不要になったら削除します：git branch -d my-feature

CONTRIBUTORS.md

これが特定のリポジトリにコードを初めて提供する場合は、Jellyfinの貢献者セクションの最後にあるファイルCONTRIBUTORS.mdに追加してください。 GitHubはこれをフォローアップしますが、コードがGitHubを離れると、ドキュメントを作成することですべてが明確になり、誰もが著作権や賞賛のためにプロジェクトに取り組んだ人をすばやく確認できます。

公式支部

機能ブランチ

時折、複数の広報と複数の人々からの貢献を必要とする主要なプロジェクトが出現する場合があります。これらのタスクでは、マスターに基づいて機能固有の機能ブランチを作成する必要があります。これにより、マスターを長期間中断することなく作業を進めることができ、その特定のプロジェクトに関心のある人は、次のリリースまでに壊れた機能を急いで修正するのではなく、自分のペースで作業することができます。機能ブランチを作成するには、Coreチームメンバーに連絡してください。修正できます。

機能ブランチが作成された機能の準備が整ったら、マスターと削除された機能ブランチの1つのテイクにマージできます。あるいは、非常に長い寿命特性の場合、特定の「安定した」スナップショットを必要に応じてマスターにマージできます。

マスターブランチ

masterブランチは、プロジェクトのメインの顔であり、メインの開発ブランチです。緊急リリースのホットフィックスを除いて、すべての広報は教師を対象にする必要があります。原則として、RPはマスターを壊さず、すべてのRPをマージする前にテストして、これが発生しないことを確認する必要があります。私たちは人間であり、これは起こりそうですが、Jellyfinの最新かつ最高のバージョンが必要な場合は、通常、マスターからビルドしても安全です。

撮影リクエストのテスト

他の誰かの引き出し要求をテストするには、ローカルリポジトリに変更をインポートする必要があります。

1. プルリクエストで変更を取得し、新しいローカルブランチにバインドします。git fetchアップストリームプル/ /ヘッド：my-testing-branchNote GitHub上の抽出リクエスト番号です。
2. 新しいローカルブランチを確認してください：git check my testing branch
3. テストに必要なテストまたはビルドを実行してから、マスターに戻ってブランチを削除します。git checkout mastergit branch -D my-testing-branch

抽出依頼ガイドライン

新規RPを提出する場合は、必ず以下のことを行ってください。まだ行っていない場合は、Gitエンゲージメントメッセージの書き方を読んでください。Gitエンゲージメントメッセージは、有用なエンゲージメントメッセージを書くための優れたリソースです。

• RPを提出する前に、カボチャの「ジャンク」はストーリー全体をクリーンに保つことに同意します。 1つのコミットで1つの重要な変更をカバーする必要があります。特に、多くのファイルに触れる大規模なRPの場合は、すべての変更を破棄しないでください。ただし、ブランチの履歴に「修正済み」、「エラー」と入力しないでください。プロジェクトの最終話で不要な混乱。
• 変更された内容をすばやく説明する適切なタイトルを付けます。たとえば、「JellyfinにLDAPサポートを追加します。」 「Gitエンゲージメントメッセージの書き方」で述べたように、常に命令的なムードを使用し、タイトルは短くてわかりやすいものにしてください。タイトルは最終的には変更ログのエントリになるので、適切な大文字を使用してくださいが、句読点は使用しないでください。コアチームがタイトルを変更して、マージする前にこの標準をよりよく確認する場合があることに注意してください。
• （短い）タイトルで完全に説明できる最も些細な変更以外の場合は、PRテンプレートに従って、可能な限り詳細に説明するPR本文を記述します。変更。可能であれば、特定のトピックをキーワード（修正、締めくくり、住所など）で参照します。トピックへの対処方法（該当する場合）を示し、特に大きなRPの変更について簡単に説明します。
• 引き出しリクエストがまだ完了していない場合は、開くときに「ドラフト」としてマークしてください。このタグが配置されている限り、プルリクエストはマージされず、リビジョンはコメントとしてのみ残されます。 RPの最終ステータスに満足したら、このタグを削除してください。それを忘れると、RPがまだ開発中であるかのように、RPが意図せずに無視される可能性があります。非アクティブなWIPにより、チームのpingがステータスを要求する場合があり、応答がない場合は閉じられます。
• 可能であれば、特にパッチ適用後は、大規模または複雑なプルリクエストのオーバーシュートや強制を回避してください。不必要なレビューを強制して、変更がまだ正常であり、適切に構築されていることを確認します。
• レビューとディスカッションを期待してください。良い説明とレビューで変更をバックアップできない場合は、それを実行する必要があるかどうか再検討してください。すべての広報活動は、管理チームのメンバーによる少なくとも1つの承認レビューを必要としますが、特にあなたが知っている地域にいる場合は、寄稿者によるレビューを歓迎し、奨励します。より多くの目は常に優れています。
• すべての広報活動は、マスターに統合される前に少なくとも2人のチームメンバーのレビューを必要としますが、寄稿者からのレビューは歓迎します！ 2人目のチームメンバーのレビュー後、RPはすぐにマージされるか、必要に応じて他のコントリビューターから明示的に要求された追加のレビューまたはコメントがマージされます。

すべての開発依存関係をインストールし、コンパイルして実行する前に、コンテナーからコードを取得する必要があります。

注

各コマンドを別々の行に記述します。テストするコンテナーはjftestと呼ばれます。 Docker内では、エントリポイントの実行可能ファイルが終了するたびにセッションが再開されるので、もう一度実行して続行します。そのため、新しいバージョンをリロードするために明示的に強制終了します。

マスターブランチ

docker exec -ti jftest bashapt-get update && apt-get install gnupg wget apt-transport-https curlwget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor> microsoft.asc.gpg && mv microsoft.asc.gpg /etc/apt/trusted.gpg。 d / wget -q https://packages.microsoft.com/config/debian/10/prod.list && mv prod.list /etc/apt/sources.list.d/microsoft-prod.listcurl -sS https：/ /dl.yarnpkg.com/debian/pubkey.gpg | apt-key add-&& echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee / etc / apt / sources。 list.d / yarn.listapt-get update && apt-get install dotnet-sdk-3.1 yarncd / opt && git clone https://github.com/jellyfin/jellyfin.git && git clone https://github.com/ jellyfin / jellyfin-web.gitmv / jellyfin / /jellyfin.bak && cd / opt / jellyfin && dotnetはJellyfinを公開します。サーバー--configuration Debug --output = "/ jellyfin"-自己完結型--runtime linux-x64cd / opt / jellyfin-web &&糸インストール&&糸ビルド&& cp -r / opt / jellyfin-web / dist / jellyfin / jellyfin-webkill -15 $（pidof jellyfin）

投げる要求

最初に、前の手順を実行して、マスターブランチをビルドするようにコンテナーを構成します。

注

GitHub上の抽出リクエスト番号です。

docker exec -ti jftest bashcd / opt / jellyfingit fetch origin pull /  / head：my-testing-branchgit merge my-testing-branchdotnet publish Jellyfin.Server --configuration Debug --output = "/ jellyfin" --self-contained --runtime linux-x64kill -15 $（pidof jellyfin）