Challenge 19

.github/workflows/linter.yaml

@@ -1,38 +1,39 @@
-name: Lint Code Base
-
-on:
-  push:
-    branches-ignore: [master, main]
-    # Remove the line above to run when pushing to master
-  pull_request:
-    branches: [master, main]
-
-jobs:
-  build:
-    # Name the Job
-    name: Lint Code Base
-    # Set the agent to run on
-    runs-on: ubuntu-latest
-
-    ##################
-    # Load all steps #
-    ##################
-    steps:
-      ##########################
-      # Checkout the code base #
-      ##########################
-      - name: Checkout Code
-        uses: actions/checkout@v3
-        with:
-          # Full git history is needed to get a proper list of changed files within `super-linter`
-          fetch-depth: 0
-
-      ################################
-      # Run Linter against code base #
-      ################################
-      - name: Lint Code Base
-        uses: github/super-linter@v4
-        env:
-          VALIDATE_ALL_CODEBASE: false
-          DEFAULT_BRANCH: main
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+name: Lint Code Base 
+
+ on: 
+   push: 
+     branches-ignore: [master, main] 
+     # Remove the line above to run when pushing to master 
+   pull_request: 
+     branches: '*detail*'    # Run it on details branch only
+
+ jobs: 
+   build: 
+     # Name the Job 
+     name: Lint Code Base 
+     # Set the agent to run on 
+     runs-on: ubuntu-latest 
+
+     ################## 
+     # Load all steps # 
+     ################## 
+     steps: 
+       ########################## 
+       # Checkout the code base # 
+       ########################## 
+       - name: Checkout Code 
+         uses: actions/checkout@v3 
+         with: 
+           # Full git history is needed to get a proper list of changed files within `super-linter` 
+           fetch-depth: 0 
+
+       ################################ 
+       # Run Linter against code base # 
+       ################################ 
+       - name: Lint Code Base 
+         uses: github/super-linter@v4 
+         env: 
+           VALIDATE_ALL_CODEBASE: false 
+           DEFAULT_BRANCH: main 
+           FILTER_REGEX_EXCLUDE: .*Challenges/.*    # Ignore Challenges/ markdown files
+           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -0,0 +1,44 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+
+# IDE-specific files and directories
+.idea/
+
+# Environment-specific files
+.env
+venv/
+.vscode/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# Logs and databases
+*.log
+*.sqlite3
+
+# OS-generated files
+.DS_Store
+Thumbs.db

Challenges/challenge10.md

@@ -0,0 +1,24 @@
+## Welcome to Challenge 10
+
+Welcome to the 10th challenge! 
+
+Today's let's try to use the concept for Git Rebase you learnt but on a Pull Request.
+
+
+Task: 
+1. Checkout to the branch you created in Challenge 3 in your forked repository. 
+
+2. Create another commit by making some change in the markdown file (`<YOUR-GITHUB-USERNAME>.md`) you created in Challenge 5 and push the change to your forked repository.
+
+3. Now, we will use the concept of Git Rebase to squash the last two commits into one commit.
+
+4. For this. Review the commits you've made on the branch using the git log --oneline command. You should see a number of commits on the branch. Use the interactive rebase command to squash the commits.
+
+5. In the interactive rebase editor, change the word pick to squash (or s) for the commits you want to combine. Save and close the editor. Edit the combined commit message when prompted. Force push the changes to your forked repository.
+
+6. Check if the commit reflects in the Pull request you created in Challenge 5 in the main challenge repository.
+
+( If it does not, then sync your forked repository with the main repository and push the changes to your forked repository.)
+
+7. Take the screenshot of the terminal when you have successfully used the git rebase to squash the commits and post it in the comment created in the first challenge (challenge 1).
+

Challenges/challenge11.md

@@ -0,0 +1,11 @@
+## Welcome to Challenge 11
+
+Welcome to the 11th Challenge 
+
+Today's challenge involves how to use ``git stash`` command effectively. You can refer on how to stash your commits [here](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning)
+
+Task: 
+1. Inside the branch you created in the previous challenge (challenge 3) ``your_github_username-details`` create a new file inside the directory ``contributors/<YOUR-GITHUB_USERNAME>/`` directory. 
+2. Use the git stash command to move these changes to the stash area
+3. Delete the content from the stash area and share a screenshot of this inside the Github issue you created in the first challenge. 
+

Challenges/challenge12.md

@@ -0,0 +1,22 @@
+## Welcome to Challenge 12
+
+Welcome to the 12th challenge! 
+
+Today's challenge is based on the concept of signing your commits. Signing the commits is a way of showing that only authentic commits are being made. 
+
+A lot of open source projects have DCO which stands for [Developer Certification of Origin](https://github.com/apps/dco) including this repository itself and it tries to verify that each commit is signed or not. In case your commit is not signed it will reflect in the pull request that it doesn't pass the DCO test. 
+
+You can read more about how to sign commits [here](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
+
+Task: 
+1. Setup the ability to sign commits locally in your systems 
+2. Whenever committing in the future always try to use signed commits 
+3. Make a new signed commit to the pull request that you have made in previous challenges by making this change to the ``<YOUR-GITHUB-USERNAME>.md`` file: 
+```
+---
+name: your_name
+github_user_name: YOUR-GITHUB-USERNAME
+url_of_github_issue: Link_of_the_github_issue_created_in_first_challenge
+your_favroite_programming_language: Add your favorite programming language here
+---
+```

Challenges/challenge13.md

@@ -0,0 +1,26 @@
+## Welcome to Challenge 13th
+
+Welcome to the 13th Challenge 
+
+Today we will be learning to work with GitHub Gists. 
+
+Github Gists are a great way to share ideas and code snippets with others.
+
+#### Brief Overview
+
+GitHub Gist is two fold and you can either use it for sharing ideas or sharing smaple code. It supports **Markdown**
+To learn more, vist:
+- [Learn more about GitHub gist](https://help.github.com/en/enterprise/2.13/user/articles/about-gists)
+
+## Task
+
+- Create a gist writing on any software development related topic that interests you
+- Create a gist sharing a small code snippet in your preferred programming language
+
+## How to Submit
+
+- Create your submission a markdown file named ``gist-solutions.md`` and add it inside the branch ``your_github_username-details`` used in previous challenges
+- In your submission file add the links to your **2 gists**
+- Ensure you push it so that it reflects inside your Pull request created in previous challenges
+
+Do remember to update your forum post on Discord with today's task completion and screenshot

Challenges/challenge14.md

@@ -0,0 +1,14 @@
+## Welcome to Challenge 14
+
+Welcome to the 14th Challenge 
+
+Today's challenge is a re-practice of the 8th and 9th Challenge. 
+
+So focus for this challenge will be to practice the ``git rebase`` command.
+
+Ensure to practice the ``git rebase`` command by creating your own local git repository. You can checkout this guide: https://www.freecodecamp.org/news/git-squash-explained/
+
+Task: 
+1. Practice git rebase, and how to squash commit using git rebase in your local projects. For this you can make some changes in the branch and the file created in Challenge 3 & 5. 
+2. Once done, try to squash the commits in your pull request in the Challenge repository. 
+3. Also do sign your commits, covered in the Challenge 12. 

Challenges/challenge15.md

@@ -0,0 +1,151 @@
+## Welcome to Challenge 15
+
+Congratulations on successfully completing the 14th challenge! This marks the completion of the second milestone of the challenge.
+
+Before you proceed with the 15th challenge, ensure you are required to have completed the following tasks to successfully mark the completion of the 2nd milestone: 
+
+## Preqrequisites to mark completion of 2nd Checkpoint (Milestone):
+
+1. Use the creative shared for the successful completion of the second milestone: [Second Milestone Creative](https://github-production-user-asset-6210df.s3.amazonaws.com/129844674/268165917-34df9c63-be61-4ffc-af43-264703f89f0a.jpg) to share on any social platform: LinkedIn, Twitter, Facebook, Instagram, etc. marking the completion of the second milestone.
+
+2. Fill the Google form the following Google form: [Google Form](https://forms.gle/JnzBURSEjRejEgw4A) to mark the completion of the second milestone. Note: This is a mandatory task to be eligible for the prize at the end of the challenge as it allows us to evaluate the submissions in the challenge so far.
+
+
+Once you have completed the above, you can proceed with the 15th challenge.
+
+
+## Task: 
+Welcome to the 15th challenge! 
+
+Read this [article on merge conflicts](https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts) as it is very important. 
+
+Today is the first part of a two-part challenge related to resolving merge conflicts. To get started, follow these steps:
+
+Task:
+Create a Scenario for Merge Conflict:
+
+- Create a new project on your local system (e.g., a code project or a text file).
+
+- Intentionally make changes to the same lines of code or content in different branches of your project to create a scenario where a merge conflict would occur during a merge or pull request.
+Resolve the Merge Conflict:
+
+- Follow the steps outlined in this [article](https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts) to understand how to resolve merge conflicts.
+
+- Use the techniques mentioned in the article to resolve the conflict you intentionally created in your project.
+
+- Share Screenshot: Take a screenshot of your terminal or Git client when you are resolving the merge conflict. 
+
+- Share this screenshot in the issue you created during the first challenge (Challenge 1) to demonstrate that you have successfully resolved a merge conflict.
+
+
+
+
+### Sample Example for merge conflict
+Here is an example of a merge conflict:
+
+
+Step 1: Set Up Your Repository
+a. Create a new directory on your computer for your Git project:
+
+```
+mkdir merge-conflict-example
+cd merge-conflict-example
+```
+
+b. Initialize the directory as a Git repository:
+
+```
+git init
+```
+
+Step 2: Create Two Branches
+a. Create a new branch called feature-branch:
+
+    ``` 
+    git checkout -b feature-branch
+
+    ```
+b. Create a file and make some changes in it. For example, create a file named example.txt and add the following content:
+
+```
+This is some content on the feature branch.
+```
+
+c. Stage and commit your changes:
+
+```
+git add example.txt
+git commit -m "Add feature branch content"
+
+```
+d. Switch back to the main (or master) branch:
+
+```
+git checkout main
+```
+e. Make changes to the same file, example.txt, in the main branch. For example:
+
+```
+This is some content on the main branch.
+```
+
+f. Stage and commit your changes on the main branch:
+```
+git add example.txt
+git commit -m "Add main branch content"
+```
+
+Step 3: Create a Merge Conflict
+a. Attempt to merge the feature-branch into main:
+
+```
+git merge feature-branch
+```
+
+At this point, you'll encounter a merge conflict because both branches have made changes to the same part of the example.txt file.
+
+
+Step 4: Resolve the Merge Conflict
+a. Open the example.txt file in your code editor.
+
+b. You'll see Git's conflict markers, which look like this:
+
+```
+<<<<<<< HEAD
+This is some content on the main branch.
+=======
+This is some content on the feature branch.
+>>>>>>> feature-branch
+```
+
+c. Manually edit the file to decide which changes to keep. Remove the conflict markers and choose the content you want to keep. For example:
+
+```
+This is some content on the main branch.
+
+This is some additional content on the feature branch.
+```
+
+d. Save the file.
+
+
+Step 5: Commit the Resolved Merge Conflict
+a. Stage the resolved file:
+
+```
+git add example.txt
+```
+
+b. Commit the changes:
+
+```
+git commit -m "Resolve merge conflict"
+```
+
+Now, you've successfully created a scenario for a merge conflict, resolved it, and committed the changes. You can use these steps as a practical exercise to understand how merge conflicts work in Git.
+
+
+
+
+
+