diff --git a/lab3/GitResetPractice.md b/lab3/GitResetPractice.md
new file mode 100644
index 00000000..78829896
--- /dev/null
+++ b/lab3/GitResetPractice.md
@@ -0,0 +1,48 @@
+# Git reset
+
+  
+
+## reset soft
+> git reset --soft **commit**
+
+The first of the three modes you can use with Git reset is --soft for the Git reset soft command. This option moves HEAD back to the specified commit, undoes all the changes made between where HEAD was pointing and the specified commit, and saves all the changes in the index. In other words, Git re-adds the changes as staged, ready to be committed again.
+### commit changes
+![alt commit](https://github.com/Usama050/Lab3/blob/main/Screenshot%20(1).png)
+
+### reset
+![alt reset](https://github.com/Usama050/Lab3/blob/main/Screenshot%20(2).png)
+
+## reset mixed
+> git reset --mixed **commit**
+
+Similar to Git reset soft, performing a Git reset with the `--mixed` option will undo all the changes between HEAD and the specified commit, but will preserve your changes in the Working Directory, as unstaged changes. If you perform a Git reset and do not supply an option of `--soft`, `--mixed`, or `--hard`, Git will use `--mixed` by default.
+
+
+### staged changes
+![alt staged](https://github.com/Usama050/Lab3/blob/main/Screenshot%20(5).png)
+
+## reset hard
+> git reset --hard **commit**
+
+Unlike with the Git reset soft and mixed, Git reset hard carries some danger, as it will automatically discard all the changes made between HEAD and the specified commit.
+
+Git reset hard should be used with extreme caution and only for local changes you’re sure you want to eliminate. Performing a Git reset –hard when working on a shared branch with commits that can be accessed by other contributors can cause issues with your Git history.
+
+### reset
+![alt reset](https://github.com/Usama050/Lab3/blob/main/Screenshot%20(4).png)
+
+
+
+## Reflection on Benefits and Use Cases of Git Reset
+
+Git reset is a valuable command in version control workflows, offering several benefits and use cases:
+
+1. **Undoing commits**: Git reset allows us to undo one or more commits by moving the branch pointer to a previous commit. This is useful when a commit needs to be removed from the commit history or if a commit was made in error and needs to be corrected.
+
+2. **Selective staging**: With `git reset --mixed`, changes can be unstaged while keeping them in the working directory. This allows for selective staging of changes before committing, providing greater control over which changes are included in the next commit.
+
+3. **Branch maintenance**: Git reset can be used to fix mistakes or rearrange commits in a branch, aiding in maintaining a clean commit history. It allows for rewriting commits, combining or splitting commits, or rearranging the commit order.
+
+4. **Reverting changes**: By using `git reset --hard`, all changes after a specific commit can be discarded, effectively reverting the project to a previous state. This is useful when it's necessary to completely remove unwanted changes and start fresh.
+
+5. **Collaboration workflows**: Git reset is often used in collaboration workflows to undo changes before pushing to a shared repository. It allows developers to review and refine their changes locally before sharing them with the team.
diff --git a/lab3/README.md b/lab3/READMEe.md
similarity index 100%
rename from lab3/README.md
rename to lab3/READMEe.md
diff --git a/lab3/Screenshot (1).png b/lab3/Screenshot (1).png
new file mode 100644
index 00000000..4d073ef7
Binary files /dev/null and b/lab3/Screenshot (1).png differ
diff --git a/lab3/Screenshot (2).png b/lab3/Screenshot (2).png
new file mode 100644
index 00000000..6eaab2d5
Binary files /dev/null and b/lab3/Screenshot (2).png differ
diff --git a/lab3/Screenshot (3).png b/lab3/Screenshot (3).png
new file mode 100644
index 00000000..65e2b332
Binary files /dev/null and b/lab3/Screenshot (3).png differ
diff --git a/lab3/Screenshot (4).png b/lab3/Screenshot (4).png
new file mode 100644
index 00000000..b82983db
Binary files /dev/null and b/lab3/Screenshot (4).png differ
diff --git a/lab3/Screenshot (5).png b/lab3/Screenshot (5).png
new file mode 100644
index 00000000..65893b98
Binary files /dev/null and b/lab3/Screenshot (5).png differ
diff --git a/lab3/VersionControl.md b/lab3/VersionControl.md
new file mode 100644
index 00000000..43b1eae3
--- /dev/null
+++ b/lab3/VersionControl.md
@@ -0,0 +1,39 @@
+# Version Control
+
+## Definition
+
+Version control systems (VCS) are tools used to manage changes to files and documents over time. They enable multiple people to collaborate on a project, tracking modifications, and allowing for easy access to different versions of the files. VCS keeps a record of every change made to the project, allowing users to roll back to previous versions, compare differences between versions, and merge changes made by different contributors.
+
+## Purpose of Version Control Systems
+
+The primary purpose of version control systems is to facilitate collaboration and provide a systematic approach to managing code or other files. They offer the following benefits:
+
+1. **Change tracking**: VCS keeps a complete history of all changes made to files, including who made the changes, when they were made, and what specific modifications were done. This information is invaluable for understanding the project's evolution and for troubleshooting issues.
+
+2. **Collaboration**: VCS allows multiple people to work on the same project simultaneously. It enables contributors to merge their changes seamlessly, preventing conflicts and ensuring a smooth collaborative workflow.
+
+3. **Versioning**: VCS provides the ability to create and manage different versions of files. This allows users to experiment with changes, branch off from the main codebase, and revert to previous versions if needed.
+
+4. **Backup and recovery**: VCS acts as a backup mechanism, as it stores a complete history of the project. In case of data loss or accidental file deletion, it is possible to restore a previous version of the project easily.
+
+5. **Code review and quality control**: VCS allows for code review processes, where changes made by contributors can be reviewed and discussed before being merged into the main codebase. This helps maintain code quality and ensure that the project follows established standards.
+
+## Types of Version Control Systems
+
+There are different types of version control systems, including:
+
+1. **Centralized Version Control Systems (CVCS)**: In CVCS, there is a central server that stores the entire history and versions of the files. Contributors check out the latest version of the files from the server, make changes locally, and then commit those changes back to the server. Examples of CVCS include Subversion (SVN) and Perforce.
+
+2. **Distributed Version Control Systems (DVCS)**: DVCS provides each contributor with a complete copy of the project's repository, including the entire history. Contributors can make changes and commit them locally without needing constant access to a central server. Git, Mercurial, and Bazaar are popular examples of DVCS.
+
+## Comparison of Popular Version Control Systems
+
+Here is a brief comparison of three widely used version control systems:
+
+1. **Git**: Git is a distributed version control system known for its speed, flexibility, and powerful branching and merging capabilities. It has become the de facto standard for version control in open-source projects and is widely adopted in the software development industry.
+
+2. **Subversion (SVN)**: Subversion is a centralized version control system that focuses on simplicity and ease of use. It uses a client-server architecture and allows for collaborative development, but it lacks some of the advanced features provided by Git.
+
+3. **Mercurial**: Mercurial is a distributed version control system similar to Git. It aims to provide an intuitive and easy-to-use interface while maintaining a robust set of features. Mercurial has gained popularity for its simplicity and has been adopted by several projects.
+
+Each version control system has its strengths and is suitable for different use cases. The choice of VCS depends on factors such as project requirements, team preferences, and scalability needs.