solution_summary

CONTRIBUTING.md

@@ -127,22 +127,38 @@ git clone https://github.com/username/repository.git
 1. Create or modify a file in your repository
 2. Stage your changes:
 
-   ```bash
+**For single file change:**
+
+```bash
+git add <file name>
+```
+
+**For all changes in severals files:**
+
+  ```bash
    git add .
    ```
 
-3. Commit your changes:
+1. Commit your changes:
 
    ```bash
    git commit -m "Initial commit: Add project setup files"
    ```
 
-4. Push to the main branch:
+2. Push to the main branch:
+
+For the main branch:
 
    ```bash
    git push origin main
    ```
 
+For certain branch:
+
+```bash
+git push origin <branch_name>
+```
+
 #### Troubleshooting Common Setup Issues
 
 - If you encounter permission denied errors, verify your SSH key is properly
@@ -252,76 +268,107 @@ Spot the "Compare & pull request" button? Give it a click to start the magic.
 - Changes: 20+ files
 - Lines of Code: 1000+ lines
 - Feature Focus: Multiple features mixed
+
+  ---
+
+## ⚠️ Merge Conflict
+
+If you encounter merge conflicts while merging a PR:
+
+1. **Checkout Your Branch**
+
+    ```bash
+    git checkout your-branch
+    ```
+
+2. **Pull Latest Changes from Main**
+
+    ```bash
+    git pull origin main
+    ```
+
+3. **Resolve Conflicts**
+
+   Open the conflicting files in your code editor (e.g., VS Code) and manually
+   resolve the conflicts.
+
+4. **Stage the Changes**
 
-## Merge Conflicts
+    ```bash
+    git add .
+    ```
 
-If You Get Merge Conflicts
+5. **Commit the Resolution**
 
-- Checkout your branch: git checkout your-branch
-- Pull the latest changes from main: git pull origin main
-- Resolve conflicts: Open the conflicting files in your code editor (e.g.,
-  VS Code) and manually resolve the conflicts
-- Stage the changes: git add .
-- Commit the resolution: git commit -m "Resolve merge conflicts with main"
-- Push the resolved changes: git push
+    ```bash
+    git commit -m "Resolve merge conflicts with main"
+    ```
+
+6. **Push the Resolved Changes**
+
+    ```bash
+    git push
+    ```
+
+After pushing, GitHub will automatically update the PR with the resolved conflicts.
 
 ## Best Practices for Collaboration 🤝
 
-Collaboration is key to successful teamwork, and following best practices helps
-keep everything running smoothly. Below are some important practices to follow,
+Collaboration is key to successful teamwork, and following best practice helps
+heep everything running smoothly. Below are some important practices to follow,
 complete with examples to ensure effective collaboration:
 
 ### Write Commit Messages 📝
 
-Commit messages should clearly describe what changes have been made and why.
-A well-written commit message helps other developers understand the purpose of
-the change and makes it easier to navigate the project's history.
+Commit messages should clearly describe what changes
+have been made and why. A well-written commit message helps other developers
+understand the purpose of the change and make it easier to navigate
+the project's history.
 
-**Best Practice for Commit Messages:** ✏️
+   **Best Practice for Commit Messages:** ✏️
 
 - **Be clear and concise:** Briefly describe what was changed and why.
 - **Follow a consistent format:** This makes it easier to read and understand.
-- **Use the imperative mood:** Write messages as commands (e.g., "Fix bug"
-  instead of "Fixed bug").
+- **Use the imperative mood:** Write messages as commands (e.g "Fix bug"
+ instead of "Fixed bug").
 
-**Examples:**
+ **Examples:**
 
 - **Good Commit Message:**
 
 ```bash
-git commit -m "Fix bug in user login validation"
+  git commit -m "Fix bug in user login validation"
 ```
 
-**Explanation:** This message clearly explains that a bug in the validation
-has been fixed, which helps others understand the purpose of the change.
+  **Explanation:** This message clearly explains that a bug in the
+validation has been fixed, which helps others understand the purpose of the change.
 
 - **Bad Commit Message:**
 
 ```bash
 git commit -m "Fixed login"
 ```
 
-**Explanation:** This message is vague and doesn't explain what part of the
+  **Explanation:** This message is vague and doesn't explain what part of the
 login process was fixed or why.
-
-**Why this is important:** Clear commit messages make it easier for your team
-to understand changes without needing to dive into the code, and they make
-reviewing and tracking changes much easier.
+  **Why this important:** Clear commit messages make it easier for your team to
+understand changes without needing to dive into the code, and they make reviewing
+and tracking changes much easier.
 
 ---
 
 ### Use Proper Branching Strategies 🌱
 
-Use a structured branching strategy to ensure the team works in an organized
-manner. Each new task should be worked on in its own branch, which keeps the
-main codebase clean and makes collaboration easier.
-
+Use a structured branching strategy ensures the team works in an organized manner.
+Each new task should be worked on in its won branch, which keeps the main
+codebase clean and makes collaboration easier.
 **Best Practices for Branching:**
 
 - **Create a branch for each task:** Each feature, bug fix, or improvement
-  should have its own branch.
-- **Name branches descriptively:** Use branch names that reflect the task
-  you're working on.
+should have its own branch.
+
+- **Name branches descriptively:** Use branch names that reflect the task you're
+working on.
 
 **Examples:**
 
@@ -332,97 +379,119 @@ git checkout -b feature/login-page
 ```
 
 **Explanation:** You're creating a branch specifically to work on the login
-page feature.
+page feature
 
-- **Bug Fix Branch:**
+- **Bug Fixe Branch:**
 
 ```bash
-git checkout -b bugfix/fix-header-alignment
+git checkout -b bugfix/fic-header-alignment
 ```
 
-**Explanation:** This branch is dedicated to fixing an issue with the header
-alignment.
+**Explanation:** This branch is dedicated to fixing an issue with the header alignment.
 
 - **Hotfix Branch:**
 
 ```bash
 git checkout -b hotfix/fix-crash-on-startup
 ```
 
-**Explanation:** A hotfix branch is used to fix a critical issue, such as a
-crash when starting the application.
+**Explanation:** A hotfix branch is used to add a critical issue, such as a
+when starting the application.
 
-**Why this is important:** By creating separate branches for each task and
-naming them descriptively, the team can work on multiple tasks at once without
-interfering with each other's work. It also makes it easy to track what each
-branch is working on.
+**Why this is important:** By creating separate branches for each task and naming
+them descriptively, the team can work on multiple tasks at once without interfering
+with each other's work. It also makes it easy to track what each branch is
+working on.
 
 ---
 
 ## **Resolving Merge Conflicts 🔧**
 
-Merge conflicts occur when two or more team members make changes to the same
-part of a file. You need to resolve these conflicts manually to make sure that
-all changes are merged correctly.
+Merge conflicts occur when two or more team members changes to the same part of
+a file. You need to resolve these conflicts manually to make sure that all
+changes are merged correctly.
 
 **Steps for Resolving Merge Conflicts:**
 
-**Understanding Merge Conflicts** When there's a conflict, Git will mark the
-conflicting areas in the file. These markers indicate the changes made by
-both you and the other developer.
+ **Understanding Merge Conflicts** When there's a conflict,
+Git will mark the conflicting areas in the file. These markers indicate the
+changes made by both you and the other developer.
 
-Imagine two developers are working on the Markdown file `README.md` or Python
-file `Calculation.py`. For example, in a Markdown file:
+Imagine two developers are working on the Markdown file ```README.md``` or
+python file ```Calculation.py```  for example, in Markdown file:
 
-```markdown
+```Markdown
+<<<<<<< HEAD
 # How to Contribute  
 This guide will help you contributing effectively.
 
+=======
+# How to Contribute 
+
+This document explains the best practices for contributing to the project.
+>>>>>>> fearuer/section-1
 ```
 
-In this case, the conflict is in the header (`# How to contribute`), and
+In this case, the conflict is in the header(```# How to contribute```), and
 both versions contain different text following the heading.
 
 Similarly, in a **Python file**, a conflict could look like this:
 
 ```python
+<<<<<<< HEAD
 def greeting():
     print("Welcome to the project!")
+=======
+def greeting():
+    print("Hello, thanks for contributing!") 
+>>>>>>> fearuer/greeting
 ```
 
 ### **How to Resolve Merge Conflicts** 🔧
 
-**Steps for resolving conflicts in Markdown or Python files:**
+  **Steps for resolving conflicts in Markdown or Python files:**
 
 - **Step 1: Identify the Conflict** 🕵️‍♂️
-  - Look for the conflict markers. You will see:
-    - `<<<<<<< HEAD`: The changes you made
-    - `=======`: The division between your changes and the incoming changes
-    - `>>>>>>> branch-name`: The changes made by someone else (in the
-      specified branch)
+- Look for the conflict markers. You will see:
+  - ```<<<<<<< HEAD```: The changes you made.
+  - ```=======```: The division between your changes and the incoming changes.
+
+  - ```>>>>>>> branch-name```: the changes made by someone else (in the
+specified branch)
 
 **Example (Markdown conflict):**
 
 ```markdown
+
+<<<<<<< HEAD
+
 # How to Contribute
 
 This guide will help you contribute effectively
+=======
+
+# How to Contribute
+
+This document explains the best practices for contributing to the project.
+>>>>>>> feature/section-1
+
 ```
 
 - **Step 2: Decide which changes to keep** ⚖️
-  - You need to decide if you want to keep your changes, the other person's
-    changes, or merge both sets of changes.
+
+  - You need to decide if you want to keep your changes, the other person’s
+changes, or merge both sets of changes.
 
 **In the Markdown file**, you might want to combine both sentences:
 
 ```markdown
 # How to Contribute
 
-This guide will help you contribute effectively and explains the best
-practices for contributing to the project.
+This guide will help you contribute effectively and explains the best practices
+for contributing to the project.
 ```
 
-**In the Python file**, you could keep both greetings or choose one:
+**In the Python file,** you could keep both greetings or choose one:
 
 ```python
 def greeting():
@@ -432,17 +501,22 @@ def greeting():
 ```
 
 - **Step 3: Remove Conflict Markers** 🧹
-  - After deciding, delete the conflict markers (`<<<<<<`, `======`, and
-    `>>>>>>`). For instance, in Markdown:
+
+  - **After deciding, delete the conflict marker(```<<<<<<```,
+```======```, and ```>>>>>>```). For instance, in Markdown:**
 
 ```markdown
+
 # How to Contribute
 
-This guide will help you contribute effectively and explains the best
-practices for contributing to the project.
+This guide will help you contribute effectively and explains the best practices
+for contributing to the project.
 ```
 
 ---
+By following these steps, you'll resolve conflicts easily, whether you'er working
+on a **Markdown** file or a **Python file**. The key is to understand the
+changes, merge them carefully, and test everything before committing your changes.
 
 We are excited to have your contribution to improve the repository and help us
 build better software together! 💪

collaboration/communication.md

@@ -29,10 +29,10 @@ How often we will get in touch on each channel, and what we will discuss there:
 | Clement| 6-8 PM | 6-8 PM  | 6-8 PM    | 6-8 PM   | 6-8 PM | 6-8 PM   | 6-8 PM |
 | Fahed  | 6-8 PM | 7-9 PM  | 6-8 PM    | 5-7 PM   | 8-9 PM | 8-9 PM   | 6-8 PM |
 | Faisal | $TIME$ | $TIME$  | $TIME$    | $TIME$   | $TIME$ | $TIME$   | $TIME$ |
-| Majd   | $TIME$ | $TIME$  | $TIME$    | $TIME$   | $TIME$ | $TIME$   | $TIME$ |
+| Majd   |6-8 PM  | 6-8 PM  | 5-6 PM    | 4-7 PM   | 4-7 PM | 4-7 PM   | 7-9 PM |
 | Mohamed| 6-9 PM | 6-9 PM  | 6-9 PM    | 6-10 PM  | 2-9 PM | 6-9 PM   | 6-9 PM |
 | Obey   | $TIME$ | $TIME$  | $TIME$    | $TIME$   | $TIME$ | $TIME$   | $TIME$ |
-| Özgür  | $TIME$ | $TIME$  | $TIME$    | $TIME$   | $TIME$ | $TIME$   | $TIME$ |
+| Özgür  | 5-7 PM | 5-7 PM  | 5-7 PM    | 5-7 PM   | 5-7 PM | 5-7 PM   | 5-7 PM |
 | Razan  | 7-9 PM | 9-10 PM  | 7-9 PM    | 7-9 PM   | 7-9 PM | 7-9 PM  | 7-9 PM |
 
 ### How many hours everyone reserves for Code review per day
@@ -44,7 +44,7 @@ How often we will get in touch on each channel, and what we will discuss there:
 - Majd: $HOURS$
 - Mohamed: 2 hours
 - Obey: $HOURS$
-- Özgür: $HOURS$
+- Özgür: 2 hours
 - Razan: An hour
 
 ## Asking for Help

collaboration/learning_goals.md

@@ -85,6 +85,8 @@ environment that provides support and help to every member in need.
   - Enhance communication and collaborative skills for a more effective work environment.
 
 - ### **Özgür**
-
- <!-- - goal 1 -->
- <!-- - goal 2 ... etc -->
+
+  - learning team work.
+  - Write clean python code.
+  - Improve communication skills with team members.
+  - Using unit test.