refactor: minor cleanup and expanding explanations for multiplayer

01-essentials/08-multiplayer/03_README.md

@@ -12,7 +12,6 @@ Learn to collaborate on a shared repository using:
 
 ```
 1. Create branch    →    2. Make changes    →    3. Push branch
-                                                       ↓
 6. Delete branch    ←    5. Merge PR        ←    4. Create PR
 ```
 
@@ -110,9 +109,15 @@ git pull
 
 1. Both people should create a branch with changes to `feature-1` and `feature-2`, you task is to change the position of number 5. Where you place it is up to you.
 2. Now both people should push their respective branch `git push <the-branch>`
-3. Now merge `feature-1` branch first, going throught the Pull Request flow.
+    1. Person A pushes their branch `git push feature-1`
+    2. Person B pushes their branch `git push feature-2`
+3. Now merge `feature-1` branch first, going throught the Pull Request flow (see Step 5).
 4. Then merge `feature-2` branch second, and notice you'll get a MERGE CONFLICT.
-5. It is not the owner of `feature-2` branch to resolve the conflict. This is done by merge the `main` branch into `feature-2` locally and so the owner of `feature-2` has to do the following
+5. The owner of `feature-2` (Person B) is now tasked with resolving the conflict. 
+    
+    In order to solve merge conflicts through a Shared Server (Azure DevOps) you have to do merges in <q>reverse</q>, meaning: Instead of, like in module <q>03-branching-and-merging</q>, merging the feature-branch into the `main` branch, we merge the `main` branch into the feature branch. 
+    
+    Doing so ensures that the `main` branch maintains the integrity it's supposed to have and the conflicts are solved on the feature-branch side before being merged into the `main` branch. The idea here being that, we ONLY modify the main branch through merges facilitated (and reviewed) by Pull Requests. We want the `main` branch to be as stable as possible.
     ```pwsh
     # First get the latest changes on main
     git switch main