Operational notes

The Git development flow using Next Design and NDGit will be easier to operate by paying attention to the following points.

Minimize conflicts as much as possible

• NDGit allows you to resolve conflicts intuitively on Next Design, but it is better to minimize unnecessary conflicts for smoother development. By paying attention to the following points, conflicts will be less likely to occur.

  • By dividing the model file into smaller parts, conflicts are less likely to occur.
    • It is recommended to separate model files, especially for models that may be developed in parallel.
  • Operation will be smoother if the metamodel structure is defined based on parallel development.
    • For example, there is a structure in which one common data definition is prepared for reference, and the data definition can be referenced, and then it can be divided and designed for each component.
  • Additionally, you can avoid unnecessary conflicts by paying attention to the following.
    • Do not edit the project itself in parallel.
      • In particular, splitting, merging, and registering model files as references should not be done on individual branches.
    • Do not edit profiles in parallel.
    • Product line models (especially feature models and configurations) should not be edited in parallel.

Prevent model inconsistencies

The following cases can result in an inconsistent model being merged: When merging in the following cases, please check the merged model before use.
If the model becomes inconsistent, Warning and handling when loading files or [Warning when displaying the editor and how to deal with it] ](/manual/en/docs/reference/warning-and-handling-when-show-editors).

1-1. Own split or merged the model file, while Other edited the model within that model file.

Occurrence conditions

• Own: Split/integrate model files.
• Other: Edit models in model files modified with Own.

Workaround

If you split or merge model files, make sure that merging does not occur.
Example: Other editors pull without local commits.

1-2. Own moved the model across model files, while Other edited the fields of the model.

Occurrence conditions

• Own: Move the model across model files.
• Other: Edit models in model files modified with Own.

Workaround

If you move a model across model files, make sure that merging does not occur.
Example: Other editors pull without local commits.

1-3. Own changed the model type, while Other edited the model's fields.

Occurrence conditions

• Own: Change the model type.
• Other: Edit the field of the model whose type was changed by Own.

Workaround

If you change the type of a model, make sure that it is not merged with your edits to that model.
Example: Other editors pull without local commits.

1-4. Own edited the order of child element models and reference models of a model, while Other edited the order of child element models and reference models of the same model.

Occurrence conditions

• Own: Edit the order of the model's child element models and referenced models.
• Other: Edit the order of child element models and reference models of the same model as Own.

Workaround

If the merge occurs by reordering models where order is meaningful, double check that the order is as expected after the merge.

1-5. Own associates a model with a field with a single number of data, while Other associates a different model with the same field.

Occurrence conditions

• Own: Associates the model with a field with a singular number of data ("0 or 1" and "1").
• Other: Associate the model associated with Own with the same field and another model.

Workaround

If a merge occurs when a model is associated with a field with a single number of data, both the Own and Other models will be associated, violating the data number constraint.
Check the location where the data count constraint is violated by selecting [Home] > [Model] > [Check Error] on the ribbon.

1-6. Own assigned features to the model, while Other deleted the same model.

Occurrence conditions

• Own: Assign features to the model.
• Other: Delete the same model as Own.

Workaround

If you assign features to the model, ensure that merging does not occur.
Example: Other editors pull without local commits.

1-7. Own edited the profile, while Other edited the model related to it.

Occurrence conditions

• Own: Edit the profile.
• Other: Edit models that affect Own profile changes.

Workaround

If you edit your profile, make sure that the merge does not occur.
Example: Other editors pull without local commits.

1-8. Own added a shape (or connector) to the model, while Other added a shape (or connector) to the same model.

Occurrence conditions

• Own: Add a shape (or connector) to the model.
• Other: Add a shape (or connector) to the same model as Own.

Workaround

• Display the editor and check if the shape (or connector) is displayed as expected.
  • If the shape (or connector) is not displayed as expected, refer to the previous revision and edit the shape (or connector) again.

Caution

If multiple shapes (or connectors) exist for the same model, all shapes (or connectors) other than the first one found when the editor is displayed will be deleted.

In the following cases, specifying the left and right directions during conflict analysis using NDGit may result in an inconsistent model. In conflict analysis, please specify left and right so that it is consistent as a project.

2-1. When resolving conflicts between elements with a parent-child relationship, delete parent elements and add child elements.

Occurrence conditions

• Own: Delete the model.
• Other: Edit the child model of the model being deleted with Own.

At this time, if you apply the following in the conflict analysis window, it will result in an inconsistent model.

• Parent model: Apply deletion.
• Child model: Undelete and apply changes.

Workaround

Apply consistent direction for parent and child.
Example: If you delete the parent model, also delete the child model. Or, if you want to cancel the deletion of the child model, also cancel the deletion of the parent model.

Caution

Even if you swap the edited contents of Own and Other, the same inconsistency will occur.

Make it easier to confirm text differences

• By saving the project in JSON format, you can check the difference in model changes as text. By paying attention to the following points, it will be easier to check text differences on Git.
  • Re-save the DB format project as a JSON format project.
    • DB format files can also be saved in JSON format by saving as.
    • The default save format can be changed from Save Format' in the Options' tab on the backstage ribbon.
• If you set it to include the reference model path, it will be easier to understand the relationship between the reference source and destination.
  • NDMerge merges file by file, so if the model indicated by the referenced path is a different file, it may not necessarily indicate the correct path.
    • If the name of the referenced model changes in a separate file or the model is moved, the path may be different.
  • You can change the settings and update the reference path below.
    • You can change the setting by Include referenced model path'' from Save options'' in the ``Information'' tab of the backstage ribbon.
    • You can update the referenced path to the latest by executing Update project file'' from Project file management'' on the ``Information'' tab.
• Structuring elements in a parent-child relationship will make it easier to check additions, deletions, and order changes.
  • You can change the settings using Save as structured in the Field item of the field inspector.

Prevent garbled characters in file names

If the file name of the changed file displayed by selecting a commit in the repository's commit history contains Japanese characters, the characters may be garbled.

info

If the characters are garbled, you can resolve it by setting [core.quotepath] to [false] as shown below.

git config --global core.quotepath false

Related item

• Overview of team development using Git