Start the review

Author: MariaShaposhnikova

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

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). 
 

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).
 

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.