From 7cbbd5d2a87d552655116b1eadb21a2aae289763 Mon Sep 17 00:00:00 2001 From: "MENDIXDOMAIN\\Maria.Shaposhnikova" Date: Fri, 13 Mar 2026 12:44:22 +0100 Subject: [PATCH 1/2] Start the review --- content/en/docs/refguide/version-control/_index.md | 2 ++ .../using-version-control-in-studio-pro/managing-branches.md | 2 +- .../using-version-control-in-studio-pro/push-pull.md | 4 ++-- .../using-version-control-in-studio-pro/reverting-changes.md | 2 +- 4 files changed, 6 insertions(+), 4 deletions(-) diff --git a/content/en/docs/refguide/version-control/_index.md b/content/en/docs/refguide/version-control/_index.md index 6e838b53fbb..36b4932591d 100644 --- a/content/en/docs/refguide/version-control/_index.md +++ b/content/en/docs/refguide/version-control/_index.md @@ -16,6 +16,8 @@ Version Control allows you to manage your app development in two ways: * Firstly, it allows you to store ([commit](/refguide/version-control/glossary/#commit)) the current revision of your model and all its resources. You give it an identifier so that you can get that revision again and share it with other team members. * Secondly, it allows work to take place on multiple [development lines](/refguide/version-control/glossary/#development-line) so that several different features can be worked on at once. These development lines can then be [merged](/refguide/version-control/glossary/#merge) back together so that your [main line](/refguide/version-control/glossary/#main-line) contains all the completed features that have been worked on separately. +For more information on what version control is and version control-related definitions, see [Version Control Glossary](/refguide/version-control/glossary/). + Version control in Mendix is built on top [Git](https://git-scm.com). The concepts will be familiar to seasoned users of these version control systems (VCS). Mendix simplifies the VCS commands by building them into Studio Pro and the Mendix Portal. ## Mendix Team Server diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/managing-branches.md b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/managing-branches.md index 77fb5ba86e9..fb3f13c807d 100644 --- a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/managing-branches.md +++ b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/managing-branches.md @@ -10,7 +10,7 @@ description: "Describes how to work with branches." A repository (remote or local) can contain a number of development lines. Each development line offers independent development from the other development lines. In the simple case there is just one development line called the main line. All development then happens inside that one line. -{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/main-branch-line.png" class="no-border" >}} +{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/main-branch-line.png" >}} It is often convenient to have more than one development line. For example, one development line is for fixing bugs in the currently deployed version of your app and another line is where you develop new functionality. If you then find a bug in the deployed version, you can fix it in the corresponding development line irrespective of the state of the development line where new functionality is developed. For more information about branches, see [Version Control Glossary: Branches](/refguide/version-control/glossary/#branches). diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/push-pull.md b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/push-pull.md index ec0ce1e7fb6..b4d09b0c36e 100644 --- a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/push-pull.md +++ b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/push-pull.md @@ -72,7 +72,7 @@ Git only creates a local commit. To submit your local commit (or commits) to the For example, you are developing a feature together with another developer on the same branch. You both have the same starting point (3). When your colleague commits a change, you can choose to retrieve these changes and integrate them. To enable this, developers first need to commit existing changes locally (6), so that the changes can be automatically merged when they are retrieved by other developers. After this, you commit the merged result, and optionally push the merged result (7) to be used by your colleague. Because changes are already explicitly committed, you can always see what you changed and you cannot accidentally override your local changes when you are resolving conflicts. -{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/incoming-changes.png" alt="Incoming changes in Git" class="no-border" >}} +{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/incoming-changes.png" alt="Incoming changes in Git" >}} In general, it is a good idea to commit after implementing one feature or fixing one bug. By committing often, your work is integrated with the work of others regularly. The benefits of committing include the following: @@ -132,7 +132,7 @@ If the changes are discovered during the push, an information dialog with instru Git prevents you from pushing your changes if it sees your changes and the remote changes as potentially conflicting. In this diagram, you see that Git does not know how to combine commits #3 and #4. -{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/server-your-work.png" alt="The local changes consist of commits 1, 3, while the remote server has commits 1, 2, and 4 on the same branch." class="no-border" >}} +{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/server-your-work.png" alt="The local changes consist of commits 1, 3, while the remote server has commits 1, 2, and 4 on the same branch." >}} There are two ways for Studio Pro to combine the commits: **Rebase** (default) and **Merge**. For more information, see [Combining Changes and Conflict Resolution](/refguide/resolving-conflicts/#combine-changes). diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/reverting-changes.md b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/reverting-changes.md index 809dfad7780..44e8eefe975 100644 --- a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/reverting-changes.md +++ b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/reverting-changes.md @@ -18,7 +18,7 @@ Deletes of documents, folders, and modules can also be reverted. This brings the You can revert changes in the **Changes** pane, from **Version Control** > **Revert All Changes**, or from the right-click menu on the document you want to revert. -{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/revertx2.png" alt="Two ways of reverting" class="no-border" >}} +{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/revertx2.png" alt="Two ways of reverting" >}} {{% alert color="info" %}} You can also **Revert All Changes** while [merging](/refguide/resolving-conflicts/#merge). This will restore your app to the most recent commit, discarding changes creating by the merging process. From a3a68adee062b737bd104f2b4065d0284ec31e53 Mon Sep 17 00:00:00 2001 From: "MENDIXDOMAIN\\Maria.Shaposhnikova" Date: Fri, 13 Mar 2026 13:00:28 +0100 Subject: [PATCH 2/2] Suggest a rename --- .../{peer-review.md => using-history.md} | 2 +- .../version-control-troubleshooting/repository-size.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) rename content/en/docs/refguide/version-control/using-version-control-in-studio-pro/{peer-review.md => using-history.md} (96%) diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/peer-review.md b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/using-history.md similarity index 96% rename from content/en/docs/refguide/version-control/using-version-control-in-studio-pro/peer-review.md rename to content/en/docs/refguide/version-control/using-version-control-in-studio-pro/using-history.md index c17ef786f2c..6e46c5ad228 100644 --- a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/peer-review.md +++ b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/using-history.md @@ -25,4 +25,4 @@ The [Name and Email settings](/refguide/preferences-dialog/#name) can be adjuste Select a revision to see additional details, such as related stories, changed documents, Studio Pro version, and changes on disk. Icons summarize the kinds of changes that happened in the app. -{{< figure src="/attachments/refguide/modeling/menus/version-control-menu/history-dialog/revisions.png" class="no-border" >}} \ No newline at end of file +{{< figure src="/attachments/refguide/modeling/menus/version-control-menu/history-dialog/revisions.png" >}} \ No newline at end of file diff --git a/content/en/docs/refguide/version-control/version-control-troubleshooting/repository-size.md b/content/en/docs/refguide/version-control/version-control-troubleshooting/repository-size.md index 24e9b1e40f5..f2ce042514b 100644 --- a/content/en/docs/refguide/version-control/version-control-troubleshooting/repository-size.md +++ b/content/en/docs/refguide/version-control/version-control-troubleshooting/repository-size.md @@ -79,7 +79,7 @@ This tool is executed on a Mendix Git repository. If your Mendix app is still on The cleanup tool will reduce the size of the repository to a minimum, by only retaining the latest commit of the main branch. This means that all work on branches that have been merged to main branch are kept, but the commits themselves (author, changes per commit, ...) are not. -{{< figure src="/attachments/refguide/version-control/troubleshoot-version-control-issues/git_fixer_mode.png" class="no-border" >}} +{{< figure src="/attachments/refguide/version-control/troubleshoot-version-control-issues/git_fixer_mode.png" >}} {{% alert color="info" %}} Uncommitted work, or work committed to branches that have not been merged to the main branch, will be permanently removed from the repository. @@ -207,7 +207,7 @@ If you are still on SVN in Studio Pro 9, see the [Recommendation on Avoiding Git Follow the decision tree in the image below to troubleshoot Git-related performance issues: -{{< figure src="/attachments/refguide/version-control/troubleshoot-version-control-issues/migration-advice-mx11.png" class="no-border" >}} +{{< figure src="/attachments/refguide/version-control/troubleshoot-version-control-issues/migration-advice-mx11.png" >}} \* In case your *.git* folder is less than 2GB but you are having performance issues when cloning, please see the [Verify Full Clone Through Git CLI](/refguide/troubleshoot-team-server-issues/#verify-full-clone-through-git-cli) section in *Troubleshooting Team Server Issues* and contact Support with the relevant information.