Review

Author: MariaShaposhnikova

content/en/docs/refguide/version-control/using-version-control-in-studio-pro/_index.md

@@ -203,9 +203,9 @@ Select a revision to see additional details, such as related stories, changed do
 
 In case you want to undo changes that have been made, it is important to understand the difference between uncommitted changes, and committed changes that have been pushed to the server. Uncommitted work can simply be reverted, while committed work requires a new **Reverse commit** to undo.
 
-### Revert Uncommitted Changes
+### Reverting Uncommitted Changes
 
-Changes that have not yet been committed can be reverted. Say, for example, that you have made a lot of changes to a page and you are not happy with the result. You can revert the page to the original state, that is, the state of the page before you started making changes.
+Changes that have not yet been committed can be reverted. For example, that you have made a lot of changes to a page and you are not happy with the result. You can revert the page to the original state, that is, the state of the page before you started making changes.
 
 Deletes of documents, folders, and modules can also be reverted. This brings them back into the app. Note that you will get back the latest version you have committed. For example, if you commit, make some changes to a microflow, and then delete the microflow, reverting the delete restores the microflow without the changes that you made.
 
@@ -214,31 +214,30 @@ You can revert changes in the **Changes** pane, from **Version Control** > **Rev
 {{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/revertx2.png" alt="Two ways of reverting" class="no-border" >}}
 
 {{% alert color="info" %}}
-You can also **Revert All Changes** while [merging](#merge). This will restore your app to the most recent, discarding changes creating by the merging process.
+You can also **Revert All Changes** while [merging](#merge). This will restore your app to the most recent commit, discarding changes creating by the merging process.
 {{% /alert %}}
 
-### Revert a Previous Commit
+### Reverting a Previous Commit
 
-Changes that have been committed and pushed to the server can never be deleted from the history. However, you can make another commit to revert the changes. This feature is called **Reverse commit** in Studio Pro.
+Changes that have been committed and pushed to the server can never be deleted from the history. However, you can make another commit to revert the changes. This is called **Reverse commit** in Studio Pro.
 
-Choose the **Version Control** menu > **Revert a Commit...** to revert a commit. This will create the original changes 'in reverse', which you can commit and push to the server.
+Select the **Version Control** menu > **Revert a Commit...** to revert a commit. This will create original changes "in reverse", which you can commit and push to the server.
 
 {{% alert color="warning" %}}
 Reverting a commit creates a new commit that undoes the changes introduced by the original commit. This may lead to unexpected results depending on the context of the original commit.
-
-* **Port fix and reverting:** If you used [Port Fix](/refguide/merge-dialog/#port-fix) to apply a commit from another branch to the current branch, and then you revert that commit, the changes from the cherry-pick will not be applied again if you later merge the entire branch. This is because the revert commit explicitly undoes the changes from the cherry-picked commit, and Git recognizes that these changes have already been handled.
-* **Merging and reverting:** If you [Merged another branch](/refguide/version-control/#merging-branches) into the current branch and then reverted the merge commit, the changes from the merge will not be reapplied if you merge the branch again. This is because the revert commit undoes the changes introduced by the merge commit, and Git recognizes that the changes have already been integrated and reverted.
+* **Port fix and reverting** – If you used [Port Fix](/refguide/merge-dialog/#port-fix) to apply a commit from another branch to the current branch, and then you revert that commit, the changes from the cherry-pick will not be reapplied when merging the full branch. This happens because the revert commit explicitly negates the cherry-picked changes, and Git recognizes them as already addressed.
+* **Merging and reverting** – If you [merged another branch](/refguide/version-control/#merging-branches) into the current branch and then reverted the merge commit, merging the same branch again will not reapply its changes. Git identifies that the merge was undone and prevents those changes from being reapplied.
 {{% /alert %}}
 
-Reverting changes is done with one commit at a time. If you want to revert multiple commits, you can do that by reverting the latest commit, then the previous one, only one by one.
+Reverting changes is done with one commit at a time. If you want to revert multiple commits, you can do that by reverting the latest commit, then the previous one, etc, one by one.
 
 {{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/revert-changes-git.png" class="no-border" >}}
 
-#### Reverse Merge
+#### Reverse Merging
 
-You can also choose to revert a commit in which another branch was merged into the current branch. If you revert the merge, the app will look like the changes never happened: if you reverse merge adding a new page, the page will be deleted locally. 
+You can also revert a commit where another branch was merged into the current branch. Reverting a merge removes the changes introduced by that merge, making it appear as if they never happened. For example, if the merge added a new page, reverting it will remove the page locally. 
 
-Just like when you are doing a normal merge, conflicts can arise. For example, if later commits change the new page, the reverse merge will result in a conflict. After resolving the conflict, you can commit and push the results to the remote repository.
+Just like with a normal merge, conflicts can occur when reverting a merge. For example, if later commits change the new page, the reverse merge will result in a conflict. Once you resolved the conflict, you can commit the changes and push them to the remote repository.
 
 ## Dealing With Conflicts {#conflicts}