refactor: minor cleanup and expanding explanations for multiplayer
This commit is contained in:
@@ -34,7 +34,7 @@ Participants need:
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Pre-Workshop Setup
|
## Setup
|
||||||
|
|
||||||
### Step 1: Add User Accounts
|
### Step 1: Add User Accounts
|
||||||
|
|
||||||
|
|||||||
@@ -25,7 +25,7 @@ Before starting, ensure you have:
|
|||||||
```
|
```
|
||||||
|
|
||||||
- **Azure DevOps account** with access to your organization/project
|
- **Azure DevOps account** with access to your organization/project
|
||||||
- If you don't have one, create a free account at [dev.azure.com](https://dev.azure.com)
|
- If you don't ask your organisation for an invitation
|
||||||
|
|
||||||
- **PowerShell 7+ or Bash terminal** for running commands
|
- **PowerShell 7+ or Bash terminal** for running commands
|
||||||
```powershell
|
```powershell
|
||||||
@@ -46,14 +46,14 @@ Open your terminal and run:
|
|||||||
ssh-keygen -t rsa
|
ssh-keygen -t rsa
|
||||||
```
|
```
|
||||||
|
|
||||||
**Note about RSA:** Azure DevOps currently only supports RSA SSH keys. While newer algorithms like Ed25519 offer better security and performance, they are not yet supported by Azure DevOps. See the note at the end of this guide for more information.
|
**Note about RSA:** Azure DevOps currently only supports RSA SSH keys. While newer algorithms like Ed25519 offer better security and performance, they are not yet supported by Azure DevOps.
|
||||||
|
|
||||||
### Save Location
|
### Save Location
|
||||||
|
|
||||||
When prompted for the file location, press `Enter` to accept the default:
|
When prompted for the file location, press `Enter` to accept the default:
|
||||||
|
|
||||||
```
|
```
|
||||||
Enter file in which to save the key (/Users/yourname/.ssh/id_rsa):
|
Enter file in which to save the key (C:\Users\YourName\.ssh\id_rsa):
|
||||||
```
|
```
|
||||||
|
|
||||||
**Default locations:**
|
**Default locations:**
|
||||||
|
|||||||
@@ -12,7 +12,6 @@ Learn to collaborate on a shared repository using:
|
|||||||
|
|
||||||
```
|
```
|
||||||
1. Create branch → 2. Make changes → 3. Push branch
|
1. Create branch → 2. Make changes → 3. Push branch
|
||||||
↓
|
|
||||||
6. Delete branch ← 5. Merge PR ← 4. Create PR
|
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.
|
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>`
|
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.
|
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
|
```pwsh
|
||||||
# First get the latest changes on main
|
# First get the latest changes on main
|
||||||
git switch main
|
git switch main
|
||||||
|
|||||||
Reference in New Issue
Block a user