ブランチ

:guilabel:`ブランチ`ビューでは、リポジトリ内の異なるブランチの概要が表示されます。

ステージ

Odoo.shは3つの異なるブランチステージを提供します:

• 本番

• ステージング

• 開発

ブランチのステージを変更するには、目的のステージの下にドラッグアンドドロップします。

注釈

• 開発ブランチは:guilabel:`ステージング`に移動できます。開発ブランチを:guilabel:`本番`に移動しようとすると、プロジェクトごとに本番ブランチは1つしか持てないことを説明する警告メッセージが表示されます。

• ステージングブランチは:guilabel:`開発`に移動できますが、:guilabel:`本番`に移動することはできません。

• 本番ブランチは:guilabel:`開発`にのみ移動できます。:guilabel:`ステージング`に移動しようとすると、統合のみ実行できます。このプロセスの詳細については、:ref:`統合 <odoo-sh/branches/stages/merging>`のセクションを参照してください。

製造

本番ブランチには、本番データベースを実行するために使用されるコードが含まれています。本番ブランチは1つしか持てません。

このブランチに新しいコミットをプッシュすると、本番サーバは修正されたコードで更新され、再起動されます。

変更がフォームビューの変更など、モジュールの更新を必要とし、更新を自動的に実行したい場合は、マニフェストファイル(__manifest__.py)でモジュールのバージョン番号を増やすことができます。プラットフォームは更新を実行し、その間、インスタンスは保守のため一時的に利用できなくなります。

この方法は、アプリ`メニューまたは:doc:`コマンドライン <../../../developer/reference/cli>`の-u`スイッチを使用してモジュールをアップグレードすることと同等です。

注釈

• 変更によりサーバの再起動が妨げられる場合、またはモジュールの更新が失敗した場合、サーバは自動的に以前の成功したコードリビジョンに戻され、データベースは以前の状態にロールバックされます。失敗した更新のログにアクセスしてトラブルシューティングを行います。

• デモデータは本番データベースでの使用を想定していないため、読み込まれません。`ユニットテスト<https://en.wikipedia.org/wiki/Unit_testing>`_は、更新中の本番データベースの利用不可時間が増加するため、実行されません。

Odoo.shは本番データベースを自動的にバックアップします。日次7回、週次4回、月次3回のバックアップが保持されます。各バックアップには、データベースダンプ、ファイルストア(添付ファイルとバイナリフィールド)、ログ、セッションが含まれます。

警告

**トライアルプロジェクト**を使用する場合、本番ブランチとすべてのステージングブランチは**30日後**に自動的に開発ステージに戻されます。

ステージング

ステージングブランチは、テストレコードで実際の本番データベースを危険にさらすことなく、本番データを使用して新機能をテストすることを目的としています。本番データベースの無害化された複製を作成します。

無害化により以下が無効になります:

• スケジュール済のアクション

  注釈

  テストするには、手動でトリガーするか、再度有効にしてください。リソースを節約するため、データベースを使用している人がいない場合、プラットフォームはそれらのトリガー頻度を減らすことに注意してください。

• 送信メール

  注釈

  代わりに、メールキャッチャーを使用して傍受されます。データベースから送信されたメールを表示する:ref:`インターフェース <odoo-sh/branches/tabs/mails>`がOdoo.shプロジェクトで提供されます。これにより、連絡先にメールが送信されることはありません。

• IAPサービス

• 支払いプロバイダーと配送コネクタ

  注釈

  テストモードに設定されます。

ステージングデータベースで設定を変更または表示する場合は、必ず記録してください（ステップごとにメモを取る、本番環境で再現するなど）。または、XMLデータファイルを使用してデフォルト設定やビューを上書きし、ブランチのモジュールに直接記述してください。例を確認するには、:ref:`最初のモジュールのドキュメント <odoo-sh/module/add>`をご覧ください。

注釈

ユニットテストは実行されません。ユニットテストはデモデータに依存していますが、デモデータは本番環境およびステージング環境のデータベースには読み込まれません。Odoroがデモデータなしでユニットテストの実行をサポートするようになれば、Odoo.shはステージングデータベースでのテスト実行を検討します。

ステージングデータベースは自動的にバックアップされません。ただし、テスト目的や本番データベースから誤って削除されたデータを手動で復元するために、本番データベースのバックアップをステージングブランチに復元することができます。ステージングデータベースの手動バックアップを作成することは可能です。

警告

ステージングブランチ用に作成されたデータベースは、1か月後に自動的に削除されます。ブランチを再度使用するには、再構築する必要があります。

開発

開発ブランチでは、ユニットテストを実行するためにデモデータを使用して新しいデータベースが作成されます。インストールされるモジュールは、ブランチに含まれるモジュールです。インストールするモジュールのリストは、:doc:`プロジェクト設定 <settings>`で変更できます。

開発ブランチにコミットをプッシュすると、新しいサーバーが起動し、ゼロから作成されたデータベースでブランチが更新されます。デモデータが読み込まれ、変更がテスト対象の機能を破壊しないことを検証するため、デフォルトでユニットテストが実行されます。テストを無効にしたり、カスタムタグで特定のテストを実行したりするには、:ref:`ブランチの設定 <odoo-sh/branches/tabs/settings>`にアクセスしてください。

ステージングブランチと同様に、メールは送信されずメールキャッチャーによって傍受され、データベースが使用されていない限りスケジュール済アクションはトリガーされません。

開発データベースは自動的にバックアップされず、手動バックアップもできません。

警告

開発ブランチ用に作成されたデータベースは、約3日間保持されることを想定しています。その後、予告なく自動的にガベージコレクションされ、新しいデータベース用のスペースが確保される可能性があります。

ブランチの統合

ブランチをドラッグ&ドロップして相互に統合できます。

開発ブランチの変更を本番環境データでテストするには、次のいずれかの方法を使用できます:

• 開発ブランチを目的のブランチにドラッグ&ドロップしてステージングブランチに統合する、または

  

• 開発ブランチを:guilabel:`ステージング`セクションの下にドラッグ&ドロップして、ステージングブランチにします。

  

変更が本番環境に対応できる状態になったら、ステージングブランチを本番環境ブランチにドラッグ&ドロップして統合およびデプロイします。

注釈

• 開発ブランチを本番環境ブランチに直接統合することもできます。ただし、ステージングブランチを経由して本番環境データで変更が検証されないため、本番環境データベースで問題が発生するリスクが高くなります。

• 開発ブランチ同士、およびステージングブランチ同士を統合できます。

• ワークステーションで直接`git merge`を使用してブランチを統合することもできます。Odoo.shは、ブランチに新しい変更履歴がプッシュされると通知を受け取ります。

ステージングブランチをプロダクションブランチにマージすると、ソースコードのみがマージされます。ステージングデータベースに加えられた変更は、プロダクションデータベースには渡されません。ただし、リポジトリ内のコードを変更した場合、マージ時にプロダクションブランチに渡されます。

ステージングブランチで設定変更をテストし、それらをプロダクションブランチに適用したい場合は、次のいずれかを行う必要があります。

• 設定変更をXMLデータファイルに記述してブランチのデフォルト設定やビューを上書きし、マニフェスト(__manifest__.py)でモジュールのバージョンを上げて、ステージングブランチをプロダクションブランチにマージする際にモジュールの更新をトリガーします。

  注釈

  この方法は、すべての設定変更にGitのバージョン管理機能を使用することで変更の追跡可能性を確保し、開発のスケーラビリティを向上させるため推奨されます。

• ステージングデータベースからプロダクションデータベースへ、コピー&ペーストで手動で渡します。

タブ

履歴

:guilabel:`履歴`タブには、ブランチの履歴の概要が表示されます。

• コミットメッセージとその作成者

• ステージ変更、データベースインポート、バックアップ復元など、プラットフォームに関連するさまざまなイベント

各イベントの右上隅にあるステータスは、データベースで現在実行中の操作(インストール、更新、バックアップインポートなど)またはその結果(テストフィードバック、バックアップインポート成功など)を示します。操作が成功すると、:guilabel:`接続`ボタンが表示され、データベースにアクセスできます。

メール

:guilabel:`メール`タブには、データベースから送信されたメールの概要を提供するメールキャッチャーが含まれています。

注釈

メールキャッチャーは、開発ブランチとステージングブランチで利用できます。プロダクションデータベースからのメールは実際に送信され、メールキャッチャーには捕捉されません。

シェル

:guilabel:`シェル`タブは、コンテナへのシェルアクセスを提供します。

シェル`をクリックすると新しいブラウザタブが開き、基本的なLinuxコマンド(`ls、top)を実行できます。`psql`を実行することで、データベースでシェルを開くことができます。

ちなみに

複数のシェルタブを同時に開き、ドラッグ&ドロップでレイアウトを調整できます。

注釈

• プロダクションインスタンスのシェルは、プロダクションインスタンスを直接操作する危険性を強調するために赤色で表示され、ステージング/開発インスタンスのシェルは黄色で表示されます。

• 長時間実行されているシェルインスタンス/アイドル状態のシェルセッションは、リソースを解放するためにいつでも終了できます。

コマンド

Odoo.shデータベース端末で実行できる便利なコマンドの概要は次のとおりです:

• odoo-bin shell: Odooシェルを開く

• odoo-update: データベース内のモジュールを更新する

• odoosh-restart: Odoo.shサービス (httpまたはcron) を再起動する

• odoosh-storage: インスタンスのコンテナファイルシステムのストレージ使用量を確認する

• psql: データベースシェルを開く

• mutt: テキストクライアントで電子メールがどのように表示されるかを確認する (ステージングおよび開発インスタンス)

• lnav ~/logs/odoo.log: インスタンスの:file:`odoo.log`ファイル内を移動する

• ncdu: 対話型インターフェースでディスク使用量アナライザーを起動する

• grep: ログまたは設定ファイル内の情報をフィルターして検索する

エディター

:guilabel:`エディター`をクリックすると、新しいブラウザタブが開き、ソースコードを編集するためのオンライン統合開発環境 (IDE) にアクセスできます。ターミナル、Pythonコンソール、Odooシェルコンソールを開くこともできます。

複数のタブを開いて、ドラッグ&ドロップでレイアウトを自由に配置できます。

参照

オンラインエディタのドキュメント。

監視

:guilabel:`監視`タブには、現在のビルドのさまざまなパフォーマンス監視メトリックが表示されます。

カーソルでズームインして時間範囲を調整するか、時間範囲セレクターから手動で選択します。タイムゾーンを変更することも可能です。

注釈

• 技術ログは常に:abbr:`UTC (協定世界時)`を使用します。これらのログを監視メトリックと一緒に分析するには、監視ツールで:abbr:`UTC (協定世界時)`が選択されていることを確認してください。

• 同様に、サポートチケットを送信する際は、共有する情報が:abbr:`UTC (協定世界時)`に基づいていることを確認してください。Odooはこのタイムゾーンを使用してパフォーマンスの問題を調査します。

情報は定期的に集約されます。この場合、青い点線が:guilabel:`集約日`タグとともに表示されます。これは、この日付より前のデータがこの日付より後のデータと比較して平坦化されて表示されることを意味します。そのため、監視ツールを使用する際は、最も詳細な情報を得るために最近のイベントに焦点を当てることをお勧めします。

注釈

他の色の点線は、ビルドに関する他の変更（データベースインポート、gitプッシュなど）との関連を示します。

ちなみに

各グラフの左上隅に 𝕚（情報）アイコンが表示されます。マウスをその上に置くと、グラフが何を表しているかの詳細が表示されます。

メトリクス

システム

:guilabel:`メモリ`グラフは、メモリ消費に関する情報を表示します：

• :guilabel:`メモリコンテナ`は、Odooワーカーとコンテナプロセスを表します。

• :guilabel:`メモリpostgresql`は、データベースを表します。

:guilabel:`CPU`グラフは、CPU消費に関する情報を表示します：

• :guilabel:`CPU http`は、Odooワーカーを表します。

• :guilabel:`CPU cron/mail`は、スケジュール済アクションと受信メールを表します。

• :guilabel:`CPU postgresql`（データベースプロセス）

• :guilabel:`CPU other`は、Webシェル、エディタなどを表します。

:guilabel:`ストレージ`グラフは、使用されているストレージに関する情報を表示します：

• :guilabel:`コンテナ`は、ファイルストア、ログファイル、ユーザファイルを表します。

• :guilabel:`Postgresql`は、データベースとインデックスを表します。

HTTP

:guilabel:`リクエスト`グラフには、1秒あたりのHTTPリクエスト数に関する情報が表示されます。

• :guilabel:`HTTP成功`は、成功したリクエストを表します。

• :guilabel:`HTTPエラー`は、失敗したリクエストを表します（:file:`odoo.log`を確認してください）。

• :guilabel:`HTTPレート制限`は、拒否されたリクエストを表します。ワーカー不足が原因の可能性があります。

:guilabel:`同時リクエスト（最大）`グラフには、1秒あたりの同時HTTPリクエストの最大数が表示されます。

注釈

データベースワーカーは、同時に処理できる並行リクエストの数を決定します。到着するすべてのリクエストを処理するために十分なワーカーを確保することが重要です。ただし、これを超えて追加のワーカーを用意しても、リクエストの処理速度は向上しません。

:guilabel:`平均応答時間`には、HTTPリクエストに対する平均応答時間（ミリ秒）が表示されます。

メール

:guilabel:`受信`グラフには、1日あたりの受信メール数に関するデータが表示されます。

• :guilabel:`受信メール`は、正常に受信されたメールを表します。

• :guilabel:`受信メールバウンス`は、受信に失敗したメールを表します。

:guilabel:`送信`グラフには、1日あたりの送信メール数に関するデータが表示されます。

• :guilabel:`送信メール`は、正常に送信されたメールを表します。

• :guilabel:`送信メールバウンス`は、送信に失敗したメールを表します。

ログ

:guilabel:`ログ`タブでは、サーバのログをリアルタイムで表示できます。

さまざまなログが利用可能です:

• pip.log: Python依存関係のインストール

• install.log: データベースのインストール（開発ブランチの場合、テストを含む）

• odoosh-import-database.log: 直近のダンプインポートプロセス

• odoo.log: 実施中のサーバ

• update.log: データベースの更新

• pg_slow_queries.log: 通常より時間がかかるpsqlクエリ

• sh_webshell.log: webshellで実行されたアクション

• sh_editor.log: エディタで実行されたアクション

• neutralize.log: データベースの無効化（ステージング環境のみ）

新しい行がログに追加されると、自動的に表示されます。下部までスクロールしている場合、新しい行が追加されるたびにブラウザが自動的にスクロールします。

右上隅の:icon:fa-pause`（:guilabel:`一時停止）ボタンをクリックすると、ログ取得プロセスを一時停止できます。それ以外の場合、プロセスは5分後に停止します。）ボタンをクリックすると再開できます。

バックアップ

:guilabel:`バックアップ`タブには、ダウンロードおよび復元可能なバックアップが一覧表示され、手動バックアップの実行とデータベースのインポートが可能です。

本番データベースは毎日自動的にバックアップされます。7日分の日次バックアップ、4週分の週次バックアップ、3か月分の月次バックアップが保持されます。各バックアップには、データベースダンプ、ファイルストア（添付ファイルとバイナリフィールド）、ログ、セッションが含まれます。

注釈

`自動バックアップの予定スケジュール<https://docs.google.com/spreadsheets/d/e/2PACX-1vSJpyyyQ7kr5WSutkrDE3ybgpYySogseN7x2Og6fIbpPYABHe0q8xq0y0xh7P-QSHkX3RTTVqKMIExy/pubhtml?gid=0&single=true>`_を参照すると、システムの仕組みをより深く理解できます。このファイルは毎日更新され、当日を起点としています。

ステージング環境と開発環境のデータベースは自動的にバックアップされません。ただし、テスト目的でステージングブランチに本番データベースのバックアップを復元したり、本番データベースから誤って削除されたデータを手動で復旧したりできます。

リストには、本番データベースのサーバに保持されているバックアップが含まれています。このサーバには1か月分のバックアップのみが保持されます：7日分の日次バックアップと4週分の週次バックアップです。

専用バックアップサーバには、同じバックアップと3か月分の追加の月次バックアップが保持されます。これらの月次バックアップのいずれかを復元またはダウンロードする場合は、`Odoサポート<https://www.odoo.com/help>`_にお問い合わせください。

1つまたは複数のモジュールのバージョンを更新するコミット（:file:`__manifest__.py`内）、または関連するPython依存関係を更新するコミット（:file:`requirements.txt`内）をマージすると、Odoo.shは自動バックアップを実行します（リスト内で`Update`タイプのフラグが付けられます）。これは、新しいpipパッケージのインストールによってコンテナが変更されるか、その後にトリガーされるモジュール更新によってデータベース自体が変更されるためです。これらの2つのケースでは、何かが壊れる可能性があるためバックアップがトリガーされます。

マージされたコミットがモジュールまたはリンクされた依存関係のバージョンを更新しない場合、Odoo.shによるバックアップはトリガーされません。コンテナもデータベースも変更されないためです。そのため、プラットフォームはこれを十分安全と見なします。念のため、本番環境のソースを変更する前に手動バックアップを作成できます。

手動バックアップの目的は、本番環境またはステージング環境のデータベースの特定のスナップショットを作成することです(開発環境では利用不可)。これらは7日間利用可能です。ただし、1日あたり5回の手動バックアップという制限があります。

ステージ	自動バックアップ	手動バックアップ
製造	対応可能(最大3か月)	対応可能(3日間)
ステージング	利用不可	対応可能(3日間)
開発	利用不可	利用不可

:guilabel:`データベースのインポート`機能は、以下からのデータベースアーカイブを受け入れます:

• 標準のOdooデータベースマネージャー(オンプレミスのOdooサーバで`/web/database/manager`から利用可能)

• Odoo Onlineデータベースマネージャー

• Odoo.shの:guilabel:バックアップ`タブ(:icon:`fa-download`(:guilabel:`ダウンロードオプション)ボタンを使用)

• Odoo.shの:doc:`ビルド <builds>`ビュー(:guilabel:`DBダンプをダウンロード`をクリック)

アップグレード

:guilabel:`アップグレード`タブは、有効なプロジェクトの本番環境およびステージング環境のブランチをアップグレードするために使用できます。アップグレードプロセスの詳細については、:doc:`アップグレードドキュメント <../../upgrade>`を参照してください。

ツール

:guilabel:`ツール`タブには、コードプロファイラーが含まれています。これは、プロファイリングセッションを開始し、インスタンスで実行されているOdooワーカーのアクティビティを最大5分間記録するために使用されます。レポート内のノイズ量を減らすため、より短い時間でツールを実行することで、セッションを早めに終了することもできます。

各セッションの後、インタラクティブなフレームグラフが作成され、Odooワーカーが時間をどのように割り当てているかを視覚化するのに役立ちます。

警告

プロファイラーの実行は多くのサーバリソースを消費するため、長時間実行しないようにしてください。目的は、データベース内の特定のアクションを記録することです。

管理設定

:guilabel:`設定`タブには、現在選択されているブランチで利用可能な設定オプションが一覧表示されます。オプションは各ステージによって異なります。

新しいコミット時の動作

**開発**ブランチと**ステージング**ブランチでは、新しいコミットを受信した際のブランチの動作を変更できます。

デフォルトでは、**開発**ブランチは新しいビルドを作成し、ステージングブランチは以前のビルドを更新します。これは、作業中の機能に特定の設定が必要な場合に便利です。コミットごとに手動で再設定する必要がなくなります。

**ステージング**ブランチで:guilabel:`新しいビルド`を選択すると、コミットがプッシュされるたびに本番ビルドの新しいコピーが作成されます。

**ステージング**から**開発**に移動されたブランチは、自動的に:guilabel:`何もしない`に設定されます。

モジュールのインストール

**開発**ブランチで自動的にインストールするモジュールを選択できます。

デフォルトの動作を変更するには、:guilabel:`デフォルトを使用`の:guilabel:`開発ビルドの動作`のチェックを外し、:guilabel:`モジュールのインストール`で次のいずれかのオプションを選択します:

• 自分のモジュールのみインストール(サブモジュールを含まない): :doc:`サブモジュール <../advanced/submodules>`を除く、ブランチのモジュールのみをインストールします。これがデフォルトオプションです。

• 完全インストール(テストスイートなし): ブランチのモジュール、サブモジュール、およびすべての標準Odooモジュールをインストールします。完全インストールを実行する場合、テストスイートは無効になります。

• モジュールのリストをインストール: 指定されたモジュールをインストールします。技術名を入力し、カンマで区切ります(例: sale_management,website,accountant)。

注釈

テストスイートが有効な場合、すべての標準Odooモジュールのインストールには最大1時間かかることがあります。

テストスイート

デフォルトでは、**開発**ブランチのテストスイートは有効になっています。テストタグ <developer/reference/testing/selection>`を入力し、カンマで区切ることで、実行するテストを制限できます(例: `custom_tags,at_install,post_install)。

テストスイートを完全に無効にするには、:guilabel:`新しいビルドでテストスイートを検証`のチェックを外します。

Odooバージョン

:guilabel:`バージョン`を選択することで、**開発**ブランチのOdooバージョンを変更できます。例えば、アップグレードされたコードをテストしたり、本番データベースが新しいバージョンへのアップグレード中に機能を開発したりする場合に便利です。

デフォルトでは、:guilabel:`最新`が:guilabel:`変更履歴`として選択されており、Odooサーバのソースは毎週自動的に更新され、最新のバグ、セキュリティ、パフォーマンスの修正が適用されます。

特定の変更履歴を選択する場合は、:guilabel:`変更履歴`フィールドで選択してください。

警告

変更履歴は3か月後に期限切れになります。変更履歴の有効期限が近づくとメールで通知されます。期限切れ時に何も対応しなかった場合、:guilabel:`変更履歴`フィールドは自動的に:guilabel:`最新`に戻されます。

カスタムドメイン

すべてのブランチタイプに対して、追加の`<name>.odoo.com`ドメインまたは独自のカスタムドメインを設定できます。

独自のカスタムドメインを使用するには、次の作業が必要です:

• ドメイン名を所有または購入する。

• カスタムドメイン`にドメイン名(例:`www.mycompany.com)を入力し、:guilabel:`ドメインを追加`をクリックします。

• レジストラのドメイン名マネージャを使用して、ドメイン名(例:www.mycompany.com)を**CNAME**レコードで設定し、値を本番データベースのドメイン名(例:mycompany.odoo.com)に設定します。

重要

ベアドメイン(例:mycompany.com)は使用できません。ベアドメインは値としてIPアドレスのみを受け付ける**A**レコードでしか設定できません。そのため、データベースのIPアドレスが変更されると(例:アップグレード、ハードウェア障害、データベースのホスティング場所の変更など)、ベアドメインが突然機能しなくなる可能性があります。

ベアドメイン(例:mycompany.com)と*www*ドメイン(例:www.mycompany.com)の両方を機能させるには、ベアドメインを*www*ドメインにリダイレクトする必要があります。ほとんどのドメインマネージャは、一般的にウェブリダイレクトと呼ばれるこのリダイレクトを設定する方法を提供しています。

HTTPS/SSL

リダイレクトが正しく設定されている場合、1時間以内に`Let's Encrypt <https://letsencrypt.org/about>`_を使用してSSL証明書が自動的に生成され、ドメインはHTTPS経由でアクセス可能になります。

SPFおよびDKIMへの準拠

メールアドレスのドメインが:abbr:`SPF(Sender Policy Framework)`または:abbr:`DKIM(DomainKeys Identified Mail)`認証プロトコルを使用している場合、送信メールの配信可能性を高めるために、ドメイン名設定でOdooを送信ホストとして承認する必要があります。詳細については、:doc:`OdooでメールするためのDNSレコードの設定ドキュメント <../../../applications/general/email_communication/email_domain>`を参照してください。

重要

Odooが送信ホストとして承認されていない場合、送信メールがスパムとしてフラグ付けされる可能性があります。

シェルコマンド

ビューの右上隅に、いくつかのシェルコマンドが表示されます。これらのコマンドはクリップボードボタンを使用してコピーし、ターミナルで使用できます。さらに、一部のコマンドはOdoo.shのインターフェースから直接使用できます。

クロン

cloneコマンドは、Gitリポジトリのローカルコピーを作成するために使用されます。

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git

• `--recurse-submodules`は、リポジトリのサブモジュールをダウンロードします

• リポジトリの特定のブランチ（例：development）にチェックアウトするには`--branch main`を使用

注釈

このコマンドはマシン上にローカルコピーを作成するために使用されるため、実行ボタンは利用できません。

フォーク

forkコマンドは、現在のブランチを基準に新しいブランチを作成するために使用されます。

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main 現在のブランチ(例:development)を基準に新しいブランチ(例:development-1)を作成するコマンド

• git push -u origin development-1 新しいブランチ(例:development-1)をリモートリポジトリにアップロードするコマンド

統合

mergeコマンドは、あるブランチの変更を別のブランチに統合するために使用されます。

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 現在のブランチの変更を別のブランチ(例:staging-1)に統合するコマンド

• git push -u origin staging 統合された変更をリモートリポジトリのブランチ(例:staging)にアップロードするコマンド

SSH

SSHコマンドは、SSHを使用してビルドに接続するために使用されます。

SSHコマンドを使用するには、最初にSSHキーを設定する必要があります。設定方法：

• 新しいSSHキーを生成する。

• SSHキーをクリップボードにコピーする <https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account#adding-a-new-ssh-key-to-your-account>`_。

• Odoo.shで、右上のGitHubユーザをクリックし、:guilabel:`Profile`を選択します。

  

• :guilabel:`Add a key manually`フィールドにSSHキーを貼り付け、:guilabel:`Add`をクリックします。

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 ビルドID

• my-user-my-repository-staging-25004381.dev.odoo.com ビルドへの接続に使用されるドメイン

プロジェクトに必要な:ref:`アクセス権 <odoo-sh/settings/collaborators>`がある場合、ビルドへのSSHアクセスが付与されます。

注釈

長時間実行されるSSH接続は保証されません。アイドル状態の接続はリソースを解放するために切断される場合があります。

サブモジュール

submoduleコマンドは、別のリポジトリのブランチをサブモジュールとして現在のブランチに追加するために使用されます。

参照

サブモジュールのドキュメント

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> リポジトリ(<URL>)の特定のブランチ(例:master)を、現在のブランチ内の指定されたパス(<PATH>)の下にサブモジュールとして追加するコマンド

• git commit -a 現在のすべての変更をコミットするコマンド

• git push -u origin staging 現在のブランチ(例:staging)の変更をリモートリポジトリにアップロードするコマンド

削除

deleteコマンドは、リポジトリからブランチを削除するために使用されます。

注釈

ブランチを削除すると、バックアップが存在しない限り、それを復元する方法はありません。ステージングブランチは自動的にバックアップされませんが、手動でバックアップできます。開発ブランチはバックアップできません。

Example

git push origin :staging && git branch -D staging

• git push origin :staging リモートリポジトリ上の特定のブランチ(例:staging)を削除するコマンド

• git branch -D staging リポジトリのローカルコピー上の特定のブランチを削除するコマンド

警告

ブランチを削除する前に、:ref:`バックアップセクション <odoo-sh/branches/tabs/backups>`を参照して、バックアップの仕組みと手動バックアップを作成すべきタイミングをよく理解してください。