Challenge #1 - #29 : Sukriti Kuila

[sukriti-kuila]

name: Sukriti Kuila github_user_name: sukriti-kuila discord_id: sukriti kuila#5415

[sukriti-kuila]

URL of forked repository Screenshot of the cloned repo:

[sukriti-kuila]

[sukriti-kuila]

[sukriti-kuila]

Challenge 7

[sukriti-kuila]

Challenge 9

[sukriti-kuila]

Challenge 10

[sukriti-kuila]

Challenge 11

[sukriti-kuila]

Challenge 15

[sukriti-kuila]

Challenge 16

[sukriti-kuila]

Challenge 17

[sukriti-kuila]

Challenge 18

[sukriti-kuila]

Challenge 19

[sukriti-kuila]

Challenge 20

[sukriti-kuila]

Challenge 21

[sukriti-kuila]

Challenge 22

Creating Aliases List of Aliases Use Case

[sukriti-kuila]

Challenge 24

Branching

Git branching strategies allow the separation of work. Broadly, we can divide Git branches into two categories: Regular and temporary Branches.

Regular Branches Dev: Developers push changes into this branch. Master: No one should directly push their code into the Master branch. After code review, one branch should be merged into the master branch. QA: r test branch, contains all the code for QA testing and automation testing of all changes implemented

Temp Branches

Bug Fix Hot Fix Feature Branches Experimental Branches WIP branches

Naming Convention

• Start the branch name with a Group word
• Use Unique ID in branch names
• Use Hyphen or Slash as Separators
• Git Branch with Author Name
• Avoid using numbers only

Pull Request Best Practices

• If your project has more than two contributors, it can be useful to prefix your branch names with your initials
• Also, if you've created a PR that's not quite ready to be merged, give the title a prefix like “WIP:” or “IN PROGRESS:” to avoid someone accidentally reviewing your work prematurely.

• Give your PR a meaningful description

  • A PR description section is where you let the reviewer know why you opened the pull request; the more information you give them before they look at your actual code, the easier their job will be. A basic description usually has these elements:

  "Why?" Why is this new code necessary? Providing a little extra context helps give your reviewer a clearer understanding of what they are about to be looking at. "How?" Provide a bullet point list of the most important commits, expanding on each as necessary. "What?" Demonstrate the functionality that was added or changed, calling out particular parts of your feature that warrant extra attention. Images and animated GIFs are a great way to do this.

  • Show your functionality visually, whenever possible

Finding An Issue

Issues available for community contribution: The following tags mark issues that are open for community contribution:

• help wanted: Open to participation from the community but not necessarily beginner-friendly
• good first issue: Open to participation from the community and friendly towards new contributors

[sukriti-kuila]

Challenge 25 After searching for a lot of projects couldn't able to find a project to which I could contribute. Hopefully, by tomorrow I will be able to find a project for contribution.

[sukriti-kuila]

Challenge 26 I have already registered for Scaler OpenQuest Hackathon I have found one repo where I can contribute. I have cloned the repo in the local machine and tried to understand the codebase.

[sukriti-kuila]

Challenge 27

Commits of BranchA

Cherry-pick on BranchB

[sukriti-kuila]

Challenge 28

Challenge 25 Progress I have made one PR & now I am waiting for the maintainer's reply Repo: Click here

---

Registered For Hacktoberfest

[sukriti-kuila]

Challenge 29

My Readme.md