Gitオペレーション

デフォルトで Git が統合されているプロジェクトでは、プロジェクト作成時に、そのプロジェクトに関連付けられた Git リポジトリが空である必要はありません。 たとえば、ワークステーション上のIDEでコードを開発し、それを Cloud Pak for Data のプロジェクトに移行したい場合は、すでにコードが含まれているリポジトリをクローンすることができます。 その後、リポジトリから取得したファイルの内容に基づいて、プロジェクト内の JupyterLab で作業を続けることができます。

Git 操作は、以下から実行できます。

  • プロジェクト内の JupyterLab または RStudio IDE 内で

  • プロジェクトのアクション・バー。 Git アイコン (Git アイコンを表示します。) を選択します。 以下の Git 操作を選択できます。

    • プル: リポジトリー内のリモート・ブランチからプロジェクトに最新の変更をプルします。

      プロジェクトが初めてで、リポジトリーへのアクセス・トークンを作成していない場合は、アクセス・トークンを作成するように求めるプロンプトが出されます。

    • コミット: トラッキング解除されたローカル変更をクローン・ブランチにコミットします。

    • プッシュ: ローカルでの変更をリモート・ブランチにプッシュして、他のユーザーによるトラッキングを有効にします。

    • チェックアウト・ブランチ: プロジェクトの Git ブランチを選択または切り替えできます。

    • マージの競合: マージに使用するファイル・バージョン (ローカルまたはリモート) を選択できます。

      Git が自動的にマージできない場合は、ローカルの変更を破棄してリモートファイルを使用するか、受信した変更を破棄してローカルファイルを保持するかを選択できます。

      ローカルとリモートの両方の変更を保持するファイルの場合は、ローカルとリモートのいずれも選択せず、代わりに競合を手動で解決してください。 プロジェクト端末を使用して、複雑な競合を手動で解決できます。 プロジェクト・ターミナルを参照してください。

    • コミット履歴: コミット履歴をログに記録します。

競合のマージのシナリオ

以下のシナリオでは、 Git の操作中に発生する可能性のある競合をマージする方法と、それらを最適に解決する方法について説明します：

  • 接続にプライベート資格情報を使用する:

    • User1 は、プロジェクト・インターフェースで新規接続および関連付けられた接続済みデータ資産を作成します。 User1 は、接続のためのプライベート資格情報を提供します。
    • User1 は、この変更をコミットし、リモート・ブランチにプッシュします。
    • User2 は、この変更をリモート・ブランチからプルし、プロジェクトの「資産」ページに新しい接続と接続されたデータ資産を表示します。
    • user2 が初めて接続または接続されたデータ資産を使用する場合、 user2 はプライベート資格情報を入力するように求められます。 User1 は、 user2 に資格情報を提供する必要があります。

  • フィーチャー・ブランチ上の同じノートブック・ファイルでの作業:

    • User1 と user2 は、ノートブック・ファイルに対して競合する変更を行いますが、 user2 は最初にコミットしてプッシュします。
    • user1 がコミット前にこれらの変更を取得すると、 user1ipynb はファイル内でファイルレベルの競合を検出します。
    • User1 プロジェクトの Git のユーザーインターフェース上で、どのファイルの変更を保持するかを直接決定します。 あるいは、 user1 は JupyterLab にアクセスして、変更内容を確認し、マージすることができます。

  • フィーチャー・ブランチ上の同じ Data Refinery フローでの作業:

    • User1 と user2 が既存の Data Refinery フローに対して競合する変更を行いますが、 user2 が最初にコミットしてプッシュします。 Data Refinery フローへの変更は、 assets/.METADATA ディレクトリーと assets/data_flow ディレクトリーの両方のファイルに影響します。
    • user1 がコミット前にこれらの変更を取得すると、 user1 は競合が発生していることを検知します。
    • ファイル名から、 user1 はこの競合がどの Data Refinery フローで発生しているかを特定できます。 User1 どの変更を反映するかを決定し、と assets/data_flow ディレクトリ assets/.METADATA の両方でファイルの変更を行います。

  • フィーチャー・ブランチ上のユーティリティー Python ファイルに対する変更により、呼び出しスクリプトが中断されます。

    • User1 は、フィーチャー・ブランチ上のユーティリティー Python ファイルに変更をコミットしてプッシュします。
    • User2 は、 user1の変更をリモート・リポジトリーからプルします。
    • 競合は発生しませんが、 user2 がテスト中に互換性のない変更を検出します。
    • User2 は、変更をコミットしてプッシュする前に呼び出しスクリプトを修正します。

  • プロジェクトの Git ユーザー・インターフェースで、フィーチャー・ブランチ上のデータ資産の説明に対する競合する変更を解決するには、以下のようにします。

    • User1 と user2 は、データ資産の説明に対して競合する変更を行いますが、 user2 は最初にコミットしてプッシュします。
    • user1 がコミット前に user2 の変更を取得すると、 user1 は、ディレクトリ assets/.metadata 内の該当 .json ファイルで競合が発生していることを検知します。
    • ファイル名から、 user1 はこの競合が発生しているアセットを判別できます。 User1 は、保持する変更を決定します。

  • のフィーチャーブランチで、 データ資産説明に対する競合する変更を解決する。 JupyterLab:

    • User1 と user2 は、データ資産の説明に対して競合する変更を行いますが、 user2 は最初にコミットしてプッシュします。
    • user1 がコミット前に user2 の変更を取得すると、 user1 は、ディレクトリ assets/.metadata 内の該当 .json ファイルで競合が発生していることを検知します。
    • ファイル名から、 user1 はこの競合が発生しているアセットを判別できます。 User1 はマージをキャンセルします。
    • user1 がプロジェクトの「資産」ページでその資産を検索して詳細を確認すると、その資産が存在しないことを示すエラー・メッセージが表示されます。
    • User1 JupyterLab を開き、ターミナルウィンドウを起動します。 User1 .metadata ディレクトリに移動し、2つの説明にある情報を組み合わせて、ファイルの競合を解決します。
    • User1 Git のaddコマンドを実行し、そのファイルの競合が解決されたことを示します。 その後、 User1 はプロジェクトのUI上で競合が解消されたことを確認し、変更内容をコミットしてプッシュします。