diff --git a/README.md b/README.md
deleted file mode 100644
index ede183d..0000000
--- a/README.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# DevOps Introduction Course: Learn the Fundamentals of DevOps
-
-Welcome to the DevOps Introduction Course, where you will gain a solid foundation in DevOps principles and practical skills. This course is designed to provide you with a comprehensive understanding of DevOps and its key components. Through hands-on labs and lectures, you will learn about various topics such as version control, software distribution, CI/CD, containers, and cloud computing.
-
-## Course Overview
-
-In this course, we will cover the following topics:
-
-1. Introduction to DevOps: Understand the core principles and concepts of DevOps.
-2. Tooling: Explore the essential tools used in the DevOps ecosystem.
-3. Version Control: Learn about version control systems and their importance in collaborative software development.
-4. Software Distribution: Gain insights into software distribution strategies and best practices.
-5. GitOps & SRE: Discover the principles of GitOps and Site Reliability Engineering (SRE).
-6. Operating Systems & Networking: Get familiar with operating systems and networking fundamentals in a DevOps context.
-7. Virtualization: Understand the concepts and benefits of virtualization in modern IT infrastructures.
-8. Containers: Dive into containerization technologies like Docker and container orchestration with Kubernetes.
-9. CI/CD: Explore continuous integration and continuous deployment practices.
-10. Cloud Computing: Learn about cloud platforms and their integration with DevOps workflows.
-
-## Lab Instructions and Grading
-
-To ensure hands-on learning, this course includes practical labs. Each lab has specific tasks that need to be completed for grading purposes. The labs contribute 80% to your final grade, while a final exam accounts for the remaining 20%.
-
-Here are some guidelines and rules for lab submissions:
-
-- You need to submit each lab and achieve a minimum score of 6/10 to pass the course.
-- Attending all lectures, practices, and submitting all lab assignments exempts you from the final exam and earns you extra points.
-- To create a lab submission, create a new branch in your forked repository specifically for that lab.
-- Complete the lab tasks in your branch and submit a pull request (PR) to the main branch of the course repository.
-- Only the last commit of your PR before the deadline will be checked and graded.
-- The deadline for lab submissions will be discussed and communicated.
-
-## Grading and Grades Distribution
-
-The course grading is as follows:
-
-- Labs: 80% of the final grade.
-- Final Exam: 20% of the final grade.
-
-The grade ranges are as follows:
-
-- [90-100] - A
-- [75-90) - B
-- [60-75) - C
-- [0-60) - D
-
-Each lab is marked out of 10 points. Completing the main tasks correctly will earn you the maximum of 10 points. However, if you're short on time or unable to complete all tasks, you can still achieve a minimum of 6 points by completing a subset of tasks.
-
-## Submission Policy
-
-It's essential to submit your lab results on time to maximize your grading. Late submissions will receive a maximum score of 6 points for the corresponding lab. Remember, submitting all labs is a requirement to pass the course successfully.
-
-We look forward to embarking on this DevOps learning journey together and helping you build valuable skills for your career.
diff --git a/index.html b/index.html
deleted file mode 100644
index 5738bc1..0000000
--- a/index.html
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
-
-
- My Simple Website
-
-
- Welcome to My Simple Website
- This is the content of the folder.
-
- - File 1
- - File 2
- - File 3
-
-
-
\ No newline at end of file
diff --git a/lab1.md b/lab1.md
deleted file mode 100644
index 7a94f7a..0000000
--- a/lab1.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Lab 1: Introduction to DevOps with Git
-
-## Overview
-
-This lab assignment introduces you to Git and its essential operations. You will complete two tasks focusing on commit signing and understanding merge strategies. Follow the tasks below to complete the lab assignment.
-
-## Task 1: SSH Commit Signature Verification
-
-**Objective**: Understand the importance of commit signing using SSH keys and set up commit signature verification.
-
-1. **Explore the Importance of Signed Commits**:
- - **Research**: Learn why commit signing is crucial for verifying the integrity and authenticity of commits.
- - Resources:
- - [GitHub Docs on SSH Commit Verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification)
- - [Atlassian's Guide to SSH and Git](https://confluence.atlassian.com/bitbucketserver/sign-commits-and-tags-with-ssh-keys-1305971205.html)
- - **Summary**: Create a submission1.md file. Write a brief summary explaining the benefits of signing commits.
-
-2. **Set Up SSH Commit Signing**:
- - **Option 1: Use an Existing SSH Key**:
- - Ensure you have an existing SSH key pair.
- - Add the public key to your GitHub account.
- - [GitHub Guide to Adding SSH Key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
-
- - **Option 2: Generate a New SSH Key (Recommended: ed25519 Format)**:
- - Generate a new SSH key pair using the ed25519 format.
-
- ```sh
- ssh-keygen -t ed25519 -C "your_email@example.com"
- ```
-
- - Add the public key to your GitHub account.
- - [GitHub Guide to Adding SSH Key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
-
- - Configure Git to use your new SSH key for signing commits.
-
- ```sh
- git config --global user.signingkey
- git config --global commit.gpgSign true
- git config --global gpg.format ssh
- ```
-
-3. **Make a Signed Commit**:
- - Create and sign a commit.
-
- ```sh
- git commit -S -m "Your signed commit message"
- ```
-
- - Push the commit with your submission1.md file.
-
-## Task 2: Merge Strategies in Git
-
-**Objective**: Research the differences between merge strategies in Git and modify repository settings to allow only the standard merge strategy.
-
-1. **Research Merge Strategies**:
- - **Standard Merge**: Combines two branches by creating a merge commit.
- - **Squash and Merge**: Combines all commits from a feature branch into a single commit before merging.
- - **Rebase and Merge**: Reapplies commits from a feature branch onto the base branch.
- - **Summary**: Write a brief summary comparing these merge strategies in the submission1.md file, including their pros and cons. Highlight why the standard merge strategy is often preferred in collaborative environments.
-
- Resources:
- - [GitHub Docs on Merging](https://docs.github.com/en/pull-requests/collaborating-with-issues-and-pull-requests/about-pull-request-merge-squash-and-rebase)
- - [Atlassian Git Tutorials](https://www.atlassian.com/git/tutorials/using-branches/merge-strategy)
-
-2. **Modify Repository Settings**:
- - **Disable Squash and Rebase Merge**:
- - Go to the Settings page of your forked repository on GitHub.
- - Navigate to the "Options" section.
-
-## Additional Resources
-
-- [Git Documentation](https://git-scm.com/doc)
-- [GitHub Guides](https://guides.github.com/)
-
-### Guidelines
-
-- Use proper Markdown formatting for documentation files.
-- Organize files with appropriate naming conventions.
-- Create a PR from your fork to the master branch of this repository with your completed lab assignment.
-
-> Note: Please check the links and thoroughly read the documentation to gain new knowledge and enhance your Git skills.
diff --git a/lab2.md b/lab2.md
deleted file mode 100644
index 1b99cc0..0000000
--- a/lab2.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# DevOps Tool Exploration
-
-In this lab, you will explore essential DevOps tools and set up a project on the Fleek service. Follow the tasks below to complete the lab assignment.
-
-## Task 1: Set Up an IPFS Gateway Using Docker
-
-**Objective**: Understand and implement an IPFS gateway using Docker, upload a file, and verify it via an IPFS cluster.
-
-1. **Set Up IPFS Gateway**:
- - Install Docker on your machine if it's not already installed.
- - [Docker Installation Guide](https://docs.docker.com/get-docker/)
-
- - Pull the IPFS Docker image and run an IPFS container:
-
- ```sh
- docker pull ipfs/go-ipfs
- docker run -d --name ipfs_host -v /path/to/folder/with/file:/export -v ipfs_data:/data/ipfs -p 8080:8080 -p 4001:4001 -p 5001:5001 ipfs/go-ipfs
- ```
-
- - Verify the IPFS container is running:
-
- ```sh
- docker ps
- ```
-
-2. **Upload a File to IPFS**:
- - Open a browser and access the IPFS web UI:
-
- ```sh
- http://127.0.0.1:5001/webui/
- ```
-
- - Explore the web UI and wait for 5 minutes to sync up with the network.
- - Upload any file via the web UI.
- - Use the obtained hash to access the file via any public IPFS gateway. Here are a few options:
- - [IPFS.io Gateway](https://ipfs.io/ipfs/)
- - [Cloudflare IPFS Gateway](https://cloudflare-ipfs.com/ipfs/)
- - [Infura IPFS Gateway](https://ipfs.infura.io/ipfs/)
-
- - Append your file hash to any of the gateway URLs to verify your file is accessible. Note that it may fail due to network overload, so don't worry if you can't reach it.
-
-3. **Documentation**:
- - Create a `submission2.md` file.
- - Share information about connected peers and bandwidth in your report.
- - Provide the hash and the URLs used to verify the file on the IPFS gateways.
-
-## Task 2: Set Up Project on Fleek.co
-
-**Objective**: Set up a project on the Fleek service and share the IPFS link.
-
-1. **Research**:
- - Understand what IPFS is and its purpose.
- - Explore Fleek's features.
-
-2. **Set Up**:
- - Sign up for a Fleek account if you haven't already.
- - Use your fork of the Labs repository as your project source. Optionally, set up your own website (notify us in advance).
- - Configure the project settings on Fleek.
- - Deploy the Labs repository to Fleek, ensuring it is uploaded to IPFS.
-
-3. **Documentation**:
- - Share the IPFS link and domain of the deployed project in the `submission2.md` file.
-
-## Additional Resources
-
-- [IPFS Documentation](https://docs.ipfs.io/)
-- [Fleek Documentation](https://docs.fleek.co/)
-
-### Guidelines
-
-- Use proper Markdown formatting for documentation files.
-- Organize files with appropriate naming conventions.
-- Create a Pull Request to the main branch of the repository with your completed lab assignment.
-
-> Note: Actively explore and document your findings to gain hands-on experience with IPFS and Fleek.
diff --git a/lab3.md b/lab3.md
deleted file mode 100644
index 2f8463c..0000000
--- a/lab3.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Version Control
-
-In this lab, you will learn about version control systems and their importance in collaborative software development. You will specifically focus on Git, one of the most widely used version control systems. Follow the tasks below to complete the lab assignment.
-
-## Task 1: Understanding Version Control Systems
-
-**Objective**: Understand how Git stores data.
-
-1. **Create and Explore a Repository**:
- - Use the current repository and make a few commits.
- - Use `git cat-file` to inspect the contents of blobs, trees, and commits.
-
- ```sh
- # Example commands to inspect contents
- git cat-file -p
- git cat-file -p
- git cat-file -p
- ```
-
- - Create a `submission3.md` file.
- - Provide the output in the `submission3.md` file.
-
-## Task 2: Practice with Git Reset Command
-
-**Objective**: Practice using different ways to use the `git reset` command.
-
-1. **Create a New Branch**:
- - Create a new branch named "git-reset-practice" in your Git repository.
-
- ```sh
- git checkout -b git-reset-practice
- ```
-
-2. **Explore Advanced Reset and Reflog Usage**:
- - Create a series of commits.
-
- ```sh
- echo "First commit" > file.txt
- git add file.txt
- git commit -m "First commit"
-
- echo "Second commit" >> file.txt
- git add file.txt
- git commit -m "Second commit"
-
- echo "Third commit" >> file.txt
- git add file.txt
- git commit -m "Third commit"
- ```
-
- - Use `git reset --hard` and `git reset --soft` to navigate the commit history.
-
- ```sh
- git reset --soft HEAD~1
- git reset --hard HEAD~1
- ```
-
- - Use `git reflog` to recover commits after a reset.
-
- ```sh
- git reflog
- git reset --hard
- ```
-
-3. **Documentation**:
- - Document the steps taken and push the final state to GitHub.
- - Document your practice in the `submission3.md` file and include the following details:
- - Steps you took to perform the Git reset operations.
- - Explain the reset and reflog process in the `submission3.md`.
- - Examples and outputs of the commands executed.
-
-## Additional Resources
-
-- [Git Documentation](https://git-scm.com/doc)
-- [Pro Git Book](https://git-scm.com/book/en/v2)
-
-### Guidelines
-
-- Use proper Markdown formatting for documentation files.
-- Organize files with appropriate naming conventions.
-- Create a Pull Request to the main branch of the repository with your completed lab assignment.
-
-> Note: Actively explore and document your findings to gain hands-on experience with Git.
diff --git a/lab4.md b/lab4.md
deleted file mode 100644
index d66a686..0000000
--- a/lab4.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# Software Distribution
-
-In this lab, you will explore software distribution strategies and best practices. You will gain insights into the different approaches used to distribute software and understand the importance of effective software distribution in the development lifecycle. Follow the tasks below to complete the lab assignment.
-
-## Task 1: Configure and Use a Local Package Repository
-
-**Objective**: Set up a local package repository and use it to install packages.
-
-1. **Create a Local Repository**:
- - Create a directory to hold your repository and place some `.deb` files in it.
-
- ```sh
- mkdir -p ~/local-apt-repo
- cp /path/to/package.deb ~/local-apt-repo/
- ```
-
-2. **Generate the Package Index**:
- - Use `dpkg-scanpackages` to create a `Packages` file. Compress this file into a `Packages.gz` archive.
-
- ```sh
- dpkg-scanpackages ~/local-apt-repo /dev/null | gzip -9c > ~/local-apt-repo/Packages.gz
- ```
-
-3. **Add the Local Repository to Your Sources List**:
- - Add the repository to your `sources.list`.
-
- ```sh
- echo "deb [trusted=yes] file:/home/yourusername/local-apt-repo ./" | sudo tee /etc/apt/sources.list.d/local-apt-repo.list
- sudo apt update
- ```
-
-4. **Verify the Contents of the Packages.gz File:**:
- - Check that the Packages.gz file contains the correct paths and metadata for your .deb files, **it must be relative path like `./your_package.deb`**. Also you can see the package name there. Then check the repository of your package, make sure it's local one.
-
- ```sh
- zcat Packages.gz
- apt policy your-package-name
- ```
-
-5. **Install a Package from the Local Repository**:
- - Install a package using `apt` from your local repository.
-
- ```sh
- sudo apt install your-package-name
- ```
-
-6. **Document the Process**:
- - Create a `submission4.md` file.
- - Provide step-by-step documentation of your setup and installation process in the `submission4.md` file.
-
-## Task 2: Simulate Package Installation and Identify Dependencies
-
-**Objective**: Use `apt` to simulate package installation and identify dependencies without actually installing the packages.
-
-1. **Choose a Package to Simulate**:
- - Select a package to simulate its installation.
-
- ```sh
- apt-cache showpkg your-package-name
- ```
-
-2. **Simulate the Installation**:
- - Use the `-s` flag to simulate the installation.
-
- ```sh
- sudo apt-get install -s your-package-name
- ```
-
-3. **Analyze the Output**:
- - Identify the dependencies and the packages that would be installed.
- - Document the findings in the `submission4.md` file, including which dependencies are required and their versions.
-
-## Task 3: Hold and Unhold Package Versions
-
-**Objective**: Prevent a package from being upgraded and then allow it to be upgraded again.
-
-1. **Install a Package**:
- - Install a package that is commonly updated.
-
- ```sh
- sudo apt install your-package-name
- ```
-
-2. **Hold the Package**:
- - Use `apt-mark` to hold the package.
-
- ```sh
- sudo apt-mark hold your-package-name
- ```
-
-3. **Verify the Hold Status**:
- - Check the status of held packages.
-
- ```sh
- apt-mark showhold
- ```
-
-4. **Unhold the Package**:
- - Use `apt-mark` to unhold the package.
-
- ```sh
- sudo apt-mark unhold your-package-name
- ```
-
-5. **Documentation**:
- - Document the steps taken to hold and unhold the package, including any verification commands in the `submission4.md` file.
-
-## Additional Resources
-
-- [Apt Documentation](https://manpages.debian.org/buster/apt/apt.8.en.html)
-- [Debian Package Management](https://www.debian.org/doc/manuals/debian-faq/pkg-basics.en.html)
-
-### Guidelines
-
-- Use proper Markdown formatting for documentation files.
-- Organize files with appropriate naming conventions.
-- Create a Pull Request to the main branch of the repository with your completed lab assignment.
-
-> Note: Actively explore and document your findings to gain hands-on experience with `apt` and software distribution strategies.
diff --git a/submission1.md b/submission1.md
new file mode 100644
index 0000000..db69982
--- /dev/null
+++ b/submission1.md
@@ -0,0 +1,24 @@
+# Merge strategies
+1. **Standatd Merge**:
+- Summary: just a regular merge.
+- Pros:
+ - Preserves the full commit history.
+ - Is easy to revert.
+- Cons:
+ - Too many commits create a lot of clutter, which is undesireable in complex projects.
+2. **Squash and merge**:
+- Summary: you combine some consecutive commits into a single commit.
+- Pros:
+ - Clean history.
+ - Developmental "steps" feel more distinct.
+- Cons:
+ - Loss of all squashed commits' messages.
+ - Therefore, it's harder to track the changes.
+3. **Rebase and Merge**:
+- Summary: Reapplies commits from the feature branch onto the base barnch in the same order, without actually merging.
+- Pros:
+ - No merge commits, somewhat cleaning up the tree.
+- Cons:
+ - Prone to conflicts between collaborators, therefore requiring more care.
+
+Standatd Merge is often preferred because it maintains a complete history, which is important for debugging.
\ No newline at end of file