Merge branch 'main' into patch-2

content/admin/enterprise-management/configuring-clustering/evacuating-a-cluster-node.md

@@ -12,55 +12,74 @@ topics:
   - Clustering
   - Enterprise
 ---
-If you only have three nodes in your data services cluster, you can't evacuate the nodes, because `ghe-spokes` doesn’t have another place to make a copy. If you have four or more, `ghe-spokes` will move all the repositories off of the evacuated node.
 
-If you're taking a node offline that has any data services (like git, pages, or storage) evacuate each node before taking the node offline.
+## About evacuation of cluster nodes
 
-1. Find the `uuid` of the node in with the `ghe-config`command.
+In a cluster configuration for {% data variables.product.product_name %}, you can evacuate a node before taking the node offline. Evacuation ensures that the remaining nodes in a service tier contain all of the service's data. For example, when you replace the virtual machine for a node in your cluster, you should first evacuate the node.
 
-    ```shell
-    $ ghe-config cluster.<em>HOSTNAME</em>.uuid
-    ```
+For more information about nodes and service tiers for {% data variables.product.prodname_ghe_server %}, see "[About cluster nodes](/admin/enterprise-management/configuring-clustering/about-cluster-nodes)."
 
-2. You'll need to monitor the status of your node while the data is being copied. Ideally, the node shouldn't be taken offline until the copying is complete. To monitor the status of your node, run any of the following commands:
+{% warning %}
 
-    For Git
-    ```
-    ghe-spokes evac-status
-    ```
-    For {% data variables.product.prodname_pages %}
-  
-    ```shell
-    echo "select count(*) from pages_replicas where host = 'pages-server-<em>UUID</em>'" | ghe-dbconsole -y
-    ```
-  
-    For storage
-    ```
-    ghe-storage evacuation-status
-    ```
+**Warnings**:
 
-3. After the copying is complete, you can evacuate the storage service. Run any of the following commands:
+- To avoid data loss, {% data variables.product.company_short %} strongly recommends that you evacuate a node before taking the node offline. 
 
-    For Git
+- If you only have three nodes in your data services cluster, you can't evacuate the nodes because `ghe-spokes` doesn't have another place to make a copy. If you have four or more, `ghe-spokes` will move all the repositories off of the evacuated node.
 
-    ```shell
-    ghe-spokes server evacuate git-server-<em>UUID</em> \'<em>REASON FOR EVACUATION</em>\'
-    ```
-   
-    For {% data variables.product.prodname_pages %}
-    
-    ```shell
-    ghe-dpages evacuate pages-server-<em>UUID</em>
-    ```
-    
-    For storage, take the node offline
-    
-    ```shell
-    ghe-storage offline storage-server-<em>UUID</em>
-    ```
-    
-      then evacuate
-    
-    ```shell
-    ghe-storage evacuate storage-server-<em>UUID</em>
-    ```
+{% endwarning %}
+
+## Evacuating a cluster node
+
+If you plan to take a node offline and the node runs a data service role like `git-server`, `pages-server`, or `storage-server`, evacuate each node before taking the node offline.
+
+{% data reusables.enterprise_clustering.ssh-to-a-node %}
+1. To find the UUID of the node to evacuate, run the following command. Replace `HOSTNAME` with the node's hostname.
+
+   ```shell
+   $ ghe-config cluster.<em>HOSTNAME</em>.uuid
+   ```
+1. Monitor the node's status while {% data variables.product.product_name %} copies the data. Don't take the node offline until the copy is complete. To monitor the status of your node, run any of the following commands, replacing `UUID` with the UUID from step 2.
+
+   - **Git**:
+
+     ```shell
+     $ ghe-spokes evac-status git-server-<em>UUID</em>
+     ```
+
+   - **{% data variables.product.prodname_pages %}**:
+
+     ```shell
+     $ echo "select count(*) from pages_replicas where host = 'pages-server-<em>UUID</em>'" | ghe-dbconsole -y
+     ```
+
+   - **Storage**:
+
+     ```shell
+     $ ghe-storage evacuation-status storage-server-<em>UUID</em>
+     ```
+1. After the copy is complete, you can evacuate the node by running any of the following commands, replacing `UUID` with the UUID from step 2.
+
+   - **Git**:
+
+     ```shell
+     $ ghe-spokes server evacuate git-server-<em>UUID</em> \'<em>REASON FOR EVACUATION</em>\'
+     ```
+
+   - **{% data variables.product.prodname_pages %}**:
+
+     ```shell
+     $ ghe-dpages evacuate pages-server-<em>UUID</em>
+     ```
+
+   - For **storage**, first take the node offline by running the following command.
+
+     ```shell
+     $ ghe-storage offline storage-server-<em>UUID</em>
+     ```
+
+     After the storage node is offline, you can evacuate the node by running the following command.
+
+     ```shell
+     $ ghe-storage evacuate storage-server-<em>UUID</em>
+     ```

content/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository.md

@@ -19,7 +19,7 @@ To transfer an open issue to another repository, you must have write access to t
 
 You can only transfer issues between repositories owned by the same user or organization account. {% ifversion fpt or ghes or ghec %}You can't transfer an issue from a private repository to a public repository.{% endif %}
 
-When you transfer an issue, comments and assignees are retained. The issue's labels and milestones are not retained. This issue will stay on any user-owned or organization-wide project boards and be removed from any repository project boards. For more information, see "[About project boards](/articles/about-project-boards)."
+When you transfer an issue, comments, labels and assignees are retained. The issue's milestones are not retained. This issue will stay on any user-owned or organization-wide project boards and be removed from any repository project boards. For more information, see "[About project boards](/articles/about-project-boards)."
 
 People or teams who are mentioned in the issue will receive a notification letting them know that the issue has been transferred to a new repository. The original URL redirects to the new issue's URL. People who don't have read permissions in the new repository will see a banner letting them know that the issue has been transferred to a new repository that they can't access.
 

data/reusables/desktop/revert-commit.md

@@ -1 +1 @@
-1. Right-click the commit you want to revert and click **Revert This Commit**.
+1. Right-click the commit you want to revert and click **Revert Changes in Commit**.