Adds tutorial video on MR workflow

docs/developer/get-source-code.md

@@ -59,4 +59,4 @@ git fetch
 git pull origin main
 ```
 
-Watch the [Cloning & Working with repositories](../../assets/videos/Cloning&Working_with_repositories.mp4) video for a more detailed explanation of above mentioned steps.
\ No newline at end of file
+Watch the first part of [Merge Request Workflow](../../assets/videos/Merge_Request_Workflow.mp4) video for a more detailed explanation of above mentioned steps.
\ No newline at end of file

docs/developer/merge-request.md

@@ -11,7 +11,7 @@ date: 2024-09-25
 You have already implemented an improvement to the current code base or intend to? Awesome 😎
 Here are some instructions, on how to to that:
 
-- First, make sure you have read [How to contribute to UNICADO](contribute.md")
+- First, make sure you have read [How to contribute to UNICADO](../developer/contribute.md)
 - Read the following instructions:
 
 There are several ways to create a merge request within GitLab, which are explained in detail in the [official GitLab docs](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html).
@@ -51,7 +51,7 @@ Next, commit your changes with a meaningful commit message:
 ```bash
 git commit -m "Description of the changes made"
 ```
-#### Guidelines for a Good Commit Message:
+#### Guidelines for a Good Commit Message 
 
 - **Title**: A short description of what the commit does (use present tense).
 - **Body**: Explain why and how the change was made. Include any relevant details, such as specific files changed or issues addressed. Should be clear and concise. Use **English** language.
@@ -81,9 +81,9 @@ After pushing your branch, GitLab will often suggest creating a Merge Request (M
 
 ### 6. Review, Approval, and Merging
 
-Then you have to wait for the **Merge request pipeline** to pass ✅ (and hopefully not fail🤞) and for the **reviewer** to approve 👍 the request. In case you need to commit adaptions, check the [commit rules](#commitrules) again! Afterwards on the page of the merge request, you can click on **merge**. Then your feature branch will be automatically merged into `main` (in this example).
+Then you have to wait for the **Merge request pipeline** to pass ✅ (and hopefully not fail🤞) and for the **reviewer** to approve 👍 the request. In case you need to commit adaptions, check the [Guidelines for a Good Commit Message](#guidelines-for-a-good-commit-message) again! Afterwards on the page of the merge request, you can click on **merge**. Then your feature branch will be automatically merged into `main` (in this example).
 ```
-📝 As a reviewer, **don't close** the merge request. It will be closed automatically, when the merge is completed.
+📝 As a reviewer, don't close the merge request. It will be closed automatically, when the merge is completed.
 
 📝 Choose squash as merge strategy, to keep the git history streamlined
 
@@ -100,8 +100,16 @@ By following these steps, you ensure that your contributions are properly tracke
 ```
 The flowchart below illustrates the Merge Request workflow, along with the commands used at each stage.
 
-<p align="center">
-  <img src="../assets/images/MR_Workflow.png" alt="Merge Request Workflow" width="600" />
+<style>
+  .center-img {
+    text-align: center;
+  }
+</style>
+
+<p class="center-img">
+  <img src="../../assets/images/MR_Worflow.png" alt="Merge Request Workflow" width="600" />
   <br>
   <i>Merge Request Workflow</i>
 </p>
+
+For a more detailed explanation of the steps mentioned above, watch the [Merge Request Workflow](../../assets/videos/Merge_Request_Workflow.mp4) video.
\ No newline at end of file