Challenge-1 to challenge-15 Anurag Pandey

[i-am-anurag]

Task-1 name: Anurag Pandey github_user_name: i-am-anurag discord_id: anurag_12

[i-am-anurag]

Challenge #2 URL of fork repo : https://github.com/i-am-anurag/scaler-open-source-september-challenge

Screenshot of clone repo :

[i-am-anurag]

Challenge #3 Screenshot of a new branch :

[i-am-anurag]

Completed challenge #4: Screenshot:

[i-am-anurag]

I have completed the challenge #5

[i-am-anurag]

I have completed the challenge #7 Added new markdown file commit, and pushed the changes in forked repository:

Remove commit using git reset :

Force push to update pull request :

[i-am-anurag]

I successfully completed challenge #8 before rebas and squash :

After rebase and squash :

[i-am-anurag]

I have successfully completed challenge #10

before rebase :

After rebase :

[i-am-anurag]

I have completed Challenge 11

[i-am-anurag]

I have completed challenge #14

1. Created a new signed commit

Commits are reflected in the PR request

Squash 2 commits and then force push

[i-am-anurag]

I have completed challenge 15

1. Initialize the new git repo create a new file and make 1st commit on master

2. created new branch(feature_branch) and added some content

3. checkout to master and add some content

4. merge the master branch with feature_branch and resolve a merge conflict

[i-am-anurag]

I have completed challenge 16

1. Added user name and GitHub URL :

2. Changes that are reflected in my PR request :
   • ignore the DCO error for the timing I will solve it

[i-am-anurag]

I have completed challenge 18

1. Created a new repo with GitHub Desktop

2. Changes on GitHub

[i-am-anurag]

I have completed challenge 19

1. setup GitHub Codespace with my local VScode and made some changes on my existing repository

2. Changes in the repository

My experience with Github CodeSpace

GitHub CodeSpace streamlines development with its seamless integration, we don't need to worry about local environment setup for projects. It offers cross-platform accessibility, which allows developers to work from any device with an internet connection and we can select machine types which provides scalability for resource-intensive tasks.

Overall, GitHub CodeSpace enhances productivity by simplifying development workflows and enabling collaborative efforts.

[i-am-anurag]

I have completed challenge 20

1. Created lint.yml file in github Action workflow

2. added code in existing repo :

3. Runnig GitHub Codelint

4. After Solving some error in lint.yml file

My experience with GitHub Actions and code linting

GitHub Actions and code linting offer substantial benefits to the development process. GitHub Actions automates tasks, such as testing and deployment, streamlining workflows and reducing manual effort. Its seamless integration with GitHub repositories and versatility in creating custom workflows make it a powerful tool. Additionally, it scales well for large projects with complex build processes. On the other hand, code linting enhances code quality by identifying and rectifying style and syntax issues early in development. It enforces consistency, resulting in more readable and maintainable code, while also detecting potential bugs before runtime.

[i-am-anurag]

I have completed challenge 21

[i-am-anurag]

I have completed challenge 22:

1. Create some aliases for some git commands :

2. done hands-on practice with aliase commands:

[i-am-anurag]

Challenge 23: GitHub Pages

1. Created static portfolio site :

2. Added links to the deployed GitHub portfolio page and its repository URL:

3. Changes reflected in my PR request :

[i-am-anurag]

Challenge day 24

1. Best Practice of Git branching name convention link

---

• In our development process, we have a branch called "dev" which serves as a safe space for making changes without affecting the master branch. Any changes made in this branch undergo a review and testing process before they are merged with the master branch.

• As a best practice, the default branch in Git repositories is referred to as the "master" branch. It is crucial that it remains stable, so direct check-ins are not allowed. Prior to merging any changes to this branch, code reviews are mandatory. It is the responsibility of every team member to ensure that the "master" branch remains stable and updated.

• QA (QA), or test branch, contains all the code for "QA testing" and "automation testing" of all changes implemented. Before any change goes to the production environment, it must undergo QA testing to get a stable codebase.

Temporary Git Branches:

• Bug Fix
• Hot Fix
• Feature Branches
• Experimental Branches
• WIP branches
• Bug – The bug that needs to be fixed soon
• WIP – The work is in progress, and I am aware it will not be finished soon

==================================================================================================================================================

2. Open source issue creation: Finding an issue

---

List of the issues available for community contribution:

1. The below 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 toward new contributors
• You may work on an issue labeled good first issue even if it's not your first issue. Issues not available for community contribution:

2. The below tags mark issues that are not open for community contribution:

   • 🔒 staff only: Requires infrastructure access or institutional knowledge that would be impractical to provide to the community

3. Issues not ready for work: These are the following tags mark issues that are not open for community contribution:

• 🚧 status: blocked: Blocked by other work that needs to be done first
• 🧹 status: ticket work required: Needs additional work before it is ready to be taken up
• 🚦 status: awaiting triage: Has not been triaged by a maintainer

3. Pull request creation Building a Great Pull Request

---

When creating a pull request (PR), it's important to keep a few things in mind.

TIP 1: Give your feature branch a clear name:

• A well-formed PR should start with a well-named feature branch. At Tighten, we typically use the Git Flow workflow (similar to GitHub Flow).
• This means we use a main branch for "production" that is only merged into development. Developers create branches off of development for their work on an individual feature, and giving that feature branch a clear name is an important first step when collaborating with others on a single repository.

TIP 2: Give your commits and PRs active and descriptive titles:

• For both commit messages and PR titles, it's a good idea to use the present imperative tense — for example, use “Fix dashboard typo” instead of “Fixed” or “Fixes.”

• I came across a helpful blog post by Chris Beams called "How to Write a Git Commit Message" that I highly recommend checking out (https://chris.beams.io/posts/git-commit/). One interesting tip he suggests is using the imperative mood in the subject line (tip number 5).

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.

TIP 3: 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.

TIP 4: Show your functionality visually, whenever possible

• You can save your reviewer a lot of time by allowing them to get the gist (gist--get it?) of your changes without pulling your branch down to their machine and clicking through a UI.
• You can take screenshots natively on OSX and save them into your clipboard directly by doing Command-Control-Shift-4. You can then just paste these screenshots directly into your PR description on GitHub!

TIP 5: Review your own PR before you assign it to others

• Make sure you are caught up with the latest changes in the develop branch; resolve any conflicts that might exist, so that merging is as easy as pressing a button.
• Run your tests! Nothing is worse than pushing up a PR that you think is done, but which actually breaks functionality.
• Lint your code! Use your team's established standard tools.

Make sure you sanity-check your changes. After pushing up your code, you can use the awesome GitHub UI to read through all of your changes and catch any glaring issues.

[i-am-anurag]

Challenge 24 completed :

1. created a new branch from the master and added some code :

2. added some commits on the dev branch :

3. Applied cherry-pick on several commits from the dev branch :

4. After applying cherry-pick some conflicts that arise and resolve them and push code in master: