メインコンテンツまでスキップ

運用上の注意事項

Next Design および NDGit を用いたGitでの開発フローにおいて、下記の点にご注意いただくことで運用しやすくなります。

コンフリクトを極力少なくする​

  • NDGit では、Next Design上で直感的にコンフリクトの解消ができますが、不要なコンフリクトは極力少なくした方がスムーズに開発できます。下記の点に注意しておくことでコンフリクトが起きにくくなります。

    • 細かくモデルファイル分割しておくことで、コンフリクトしにくくなります。
      • 特に並行して開発する可能性のあるモデル同士はモデルファイル分割しておくことをお勧めします。
    • メタモデルの構造も並行開発を前提とした構造で定義しておくと、より運用がスムーズとなります。
      • 例えば共通のデータ定義を参照用に1つ用意しデータ定義を参照できるようにした上で、コンポーネント毎に分割・設計できるような構造などが挙げられます。
    • さらに下記にご注意いただくことで、余分なコンフリクトを避け運用することができます。
      • プロジェクト自体の編集は並行して行わない。
        • 特にモデルファイルの分割、統合、参照登録はブランチ個別では行わない。
      • プロファイルの編集は並行して行わない。
      • プロダクトラインのモデル(特にフィーチャモデル、コンフィグレーション)の編集は並行して行わない。

モデルの不整合を防ぐ​

次のケースでは、マージ結果として不整合なモデルとなる可能性があります。以下のケースでマージするときは、マージ後のモデルを確認してご利用ください。
不整合なモデルとなった場合、ファイル読み込み時の警告と対処方法 または エディタ表示時の警告と対処方法に従って対処してください。

1-1. Ownはモデルファイルの分割や統合をした一方、Otherはそのモデルファイル内のモデルを編集した。

発生条件

  • Own: モデルファイルの分割・統合を行う。
  • Other: Ownで変更されたモデルファイル内のモデルを編集する。

対処方法

モデルファイルの分割・統合を行った場合、マージが発生しないようにしてください。
例: 他の編集者はローカルのコミットなしの状態でプルする。

1-2. Ownはモデルファイルをまたがるモデルの移動をした一方、Otherはそのモデルのフィールドを編集した。

発生条件

  • Own: モデルファイルをまたがるモデルの移動をする。
  • Other: Ownで変更されたモデルファイル内のモデルを編集する。

対処方法

モデルファイルをまたがるモデルの移動を行った場合、マージが発生しないようにしてください。
例: 他の編集者はローカルのコミットなしの状態でプルする。

1-3. Ownはモデルの型変更をした一方、Otherはそのモデルのフィールドを編集した。

発生条件

  • Own: モデルの型変更をする。
  • Other: Ownが型変更したモデルのフィールドを編集する。

対処方法

モデルの型変更をした場合、そのモデルの編集とマージされないようにしてください。
例: 他の編集者はローカルのコミットなしの状態でプルする。

1-4. Ownはモデルの子要素モデルや参照モデルの順序を編集した一方、Otherは同じモデルの子要素モデルや参照モデルの順序を編集した。

発生条件

  • Own: モデルの子要素モデルや参照モデルの順序を編集する。
  • Other: Ownと同じモデルの子要素モデルや参照モデルの順序を編集する。

対処方法

順序が意味を持つモデルの順序を変更してマージが発生した場合、マージ後に順序が期待通りになっていることを再確認してください。

1-5. Ownはデータ数が単数のフィールドにモデルを関連付けた一方、Otherは同じフィールドに別のモデルを関連付けた。

発生条件

  • Own: データ数が単数(「0または1」および「1」)のフィールドにモデルを関連付ける。
  • Other: 同じフィールドにOwnで関連付けたモデルと別のモデルを関連付ける。

対処方法

データ数が単数のフィールドにモデルを関連付けてマージが発生した場合、データ数の制約を違反してOwnとOther両方のモデルが関連付けられます。
リボンの [ホーム] > [モデル] > [エラーチェック] によりデータ数の制約違反箇所を確認してください。

1-6. Ownはモデルにフィーチャを割り当てた一方、Otherは同じモデルを削除した。

発生条件

  • Own: モデルにフィーチャを割り当てる。
  • Other: Ownと同じモデルを削除する。

対処方法

モデルにフィーチャを割り当てた場合、マージが発生しないようにしてください。
例: 他の編集者はローカルのコミットなしの状態でプルする。

1-7. Ownはプロファイルを編集した一方、Otherはそれに関係するモデルを編集した。

発生条件

  • Own: プロファイルを編集する。
  • Other: Ownのプロファイル変更に影響するモデルを編集する。

対処方法

プロファイルを編集した場合、マージが発生しないようにしてください。
例: 他の編集者はローカルのコミットなしの状態でプルする。

1-8. Ownはモデルに対してシェイプ（又はコネクタ）を追加した一方、Otherは同一のモデルに対してシェイプ（又はコネクタ）を追加した。

発生条件

  • Own: モデルに対してシェイプ（又はコネクタ）を追加する。
  • Other: Ownと同一のモデルに対してシェイプ（又はコネクタ）を追加する。

対処方法

  • エディタを表示し、期待通りのシェイプ（又はコネクタ）が表示されているか確認してください。
    • 期待通りのシェイプ（又はコネクタ）が表示されていない場合、変更前のリビジョンを参照し、シェイプ（又はコネクタ）を再編集してください。
注意

同一のモデルに対して複数のシェイプ（又はコネクタ）が存在する場合、エディタ表示時に最初に見つかったシェイプ（又はコネクタ）以外は削除されます。

次のケースでは、NDGitを使ったコンフリクト分析で左右の方向を指定した結果として不整合なモデルとなる可能性があります。コンフリクト分析ではプロジェクトとして一貫するように左右を指定してください。

2-1. 親子関係を持つ要素のコンフリクトを解決する際に、親要素を削除・子要素を追加で適用する。

発生条件

  • Own: モデルを削除する。
  • Other: Ownで削除されるモデルの子モデルを編集する。

このとき、コンフリクトの分析ウィンドウにて以下のように適用すると不整合なモデルとなります。

  • 親モデル: 削除を適用する。
  • 子モデル: 削除を取り消して変更を適用する。

対処方法

親子で一貫する方向を適用してください。
例: 親モデルを削除する場合は子モデルも削除する。または、子モデルの削除を取り消す場合は親モデルの削除も取り消す。

注意

OwnとOtherの編集内容を入れ替えても、同様に不整合が起きます。

テキストでの差分を確認しやすくする​

  • プロジェクトをJSON形式で保存することで、モデルの変更差分がテキストでも確認できるようになります。下記の点に注意しておくことでGit上でのテキスト差分を確認しやすくなります。
    • DB形式のプロジェクトを、JSON形式のプロジェクトで保存しなおします。
      • DB形式のファイルも名前を付けて保存により、JSON形式で保存しなおすことができます。
      • デフォルトの保存形式は、リボンのバックステージのオプションタブにある保存形式から変更できます。
  • 参照先のモデルパスも含める設定にしておくと、参照元・先の関係性がわかりやすくなります。
    • NDMerge ではファイル単位でマージされるため、参照先のパスで示すモデルが別ファイルの場合、必ずしも正しいパスを示すとは限りません。
      • 別ファイルで、参照先モデルの名前が変わったり、モデルの移動があった場合に異なるパスとなる可能性があります。
    • 下記にて設定変更、および参照先のパスを最新に更新できます。
      • リボンのバックステージの情報タブにある保存オプションから参照先のモデルパスを含めるで設定を変更できます。
      • 同じく情報タブにあるプロジェクトファイルの管理からプロジェクトファイルの更新を実行することで参照先のパスを最新に更新できます。
  • 親子関係にある要素は構造化しておくと、追加・削除・順序変更が確認しやすくなります。
    • フィールドインスペクタのフィールド項目にある構造化して保存するで設定を変更できます。

ファイル名の文字化けを防ぐ​

リポジトリのコミット履歴で、コミットを選択することで表示される変更ファイルのファイル名に日本語が含まれる場合、文字化けすることがあります。

備考

文字化けした場合、以下のように [core.quotepath] を [false] にすると解消できます。

git config --global core.quotepath false

関連項目​

に最終更新