scaleracademy
#30 days Challenge: [ Vimal ]
Challenge day 1
name: Vimal github_user_name: vimalJD discord_id: 900373037109633074
Challenge day 2
2 Screenshot of the cloned repo in my local system by Git bash on windows system
3 Local direcory of fork repo
Challenge day 3
1 A new branch has been created locally from my forked clone repository. The new branch name is as vimalJD-details
2 URL of newly created branch vimalJD-details
Challenge day 4
Updated my forked repository locally with the content
Challenge day 5
1 Folder and file created URL: Tasks have been completed with creating folder and file, add, commit, push repo to fork and upstream and pull request as well
Challenge day 6
tasks have been completed but approval for " 1 workflow awaiting approval "
Challenge day 7
-
Created a new file by the name of my-github-username-2.md and add any details you may want to add to this markdown file and push the change to your forked repository.
-
I ensured the change appeared in the Pull request created in previous challenges
-
I have identified the commit ID for the commit you just made and used the git reset command to remove the commit from your local branch.
-
Use git reset and force push, to remove the commit from your pull request.
========================================================
URL of Pull request: https://github.com/scaleracademy/scaler-open-source-september-challenge/pull/894
URL of git reset and force push file: https://github.com/scaleracademy/scaler-open-source-september-challenge/commit/9333478aeefcb93642d6b3335a432d111127d0b3
Challenge day 8
Step 3: Create a new branch in my forked repository by the name of challenge8 and switch to that branch.
Step 4: Add a new file by the name of your-github-username-3.md and add any details you may want to add to this markdown file and push the change to your forked repository.
Challenge day 9
1 I have created another commit by making some changes in the vimalJD-3.md file and pushed the change to my forked repository.
2 I have used the concept of Git Rebase to squash the last two commits into one commit.
2.1 git rebase -i HEAD~2
2.2 In the interactive rebase continue, change the word pick to squash.
2.3 While editing rebase-interactive
2.4 Reabase successive message
2.5 Combine the last 2 commits into 1
2.5 Force push
- Fork repo with changes of MD file and file committed ahead
3.1 image md
3.2 image committed
Challenge day 10
-
vimalJD.md file modified
-
Rebase in interactive mode
-
Pick to Squash
-
Before Pick to Squash
-
After Pick to Squash
Challenge day 11
- New file created
- Edited file
- Under stash mode
- Stash list, pop and clear
Challenge day 12
1 GPG config
Global Configuration
- gpg --full-generate-key
- gpg --list-secret-keys --keyid-format=long
- gpg --armor --export F9642DEE94179AA7
- git config --global user.name "vimalJD"
- git config --global user.email "[email protected]"
- git config --global user.signingkey F9642DEE94179AA7
- git config --global commit.gpgsign true
- git config --global tag.gpgsign true
- git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe" (gpg.program not working on windows 11)
1.1 for working on windows 11
2 Push
3 DCO approved
Pull Request up-to challenge 12
Challenge day 13
1 gist-solutions.md created and add the links to your 2 gists
2 Pushed and reflected inside my Pull request created in previous challenges
Pull Request up-to challenge 13
Challenge day 14
1 git log --oneline
2 Pick to Squash
3 Success commit as modified for challenge 14 pick to squash
4 Pull request conversation
5 Pull Request up-to challenge 14
Challenge day 15
1 Created a new Java file on my local system with feature-challenge-15 as a new branch
2 Merge conflicted from feature to main branch
3 Conflicted file
4 Save the file with new changes
5 Merge conflicts resolved
6 I've successfully created a scenario for a merge conflict, resolved it, committed the changes and understood how merge conflicts work in Git using git bash.
Challenge day 16
1 Update my Forked Repository From the Original [Main Repository] locally.
2 In my branch added my name to the list of challengers.
3 Pushed my changes to the details branch and reflected them in the Pull Request
4 Pull Request up-to challenge 16
Challenge day 17
1 I needed "git pull upstream main" because conflicts show in PR at GitHub repo but were not showing in a local file.
2 Merge conflicts file
3 Merge conflicts resolved
4 Pull Request conversation
5 Pull Request up-to challenge 17
Challenge day 18
1 Created repo using GitHub Desktop
2 Changes in the README.md file
3 Committed history
4 Pushed repo local to GitHub repo
5 A new branch was created as feature1-challenge18 via clone using GitHub.com
6 Feature branch changes
7 1st commit pushed to the feature branch
Challenge day 19
1 Codespaces created
2 Java file created using vs code in Codespace
3 Pushed area in the main repo
4 New branch created as feature1-challenge19
5 Changes in java and md file
6 Stages using vs code
7 Commit and Push for 1st changes
8 Pushed to repo using vs code
9 Could you mention any features you found helpful?
- we can simultaneously use the terminal as a git command and tool feature as well for checking some understanding of switching branches with ease.
9.1 challenges you encountered.
- By using Git bash, We can see a log of upstream, origin, feature branch and merge for better background understanding.
How you envision using Codespaces in your development workflow.
- I think the below image is the first problem or issue while developing some best practices for the first time or might be explored in GitHub Codespaces
It shows, "Codespace usage for this repository is paid for by vimalJD"
Challenge day 20
1 New repo created
2 GitHub action setup by customization
3 yaml pushed successfully
4 New file created
5 Observe how GitHub Actions automatically runs the code linting checks whenever there are new commits or pull requests
6 lint code error
7 Linter job done by excluding some regex of java for now only because linter by default not support java, unlike javascript and python etc. So, it's too complex to set up without connect with any IDE like intellij idea or Eclipse.
8 I have used this Checktyle of java for configuration in yaml file but it needs setup of IDE's and create new action.yml file or Docker file or cicd pipeline in github Actions
8.1
8.2
Challenge day 21
1 Create a project board with a TODO column, In progress, Done and Tech stacks
2 In Progress
3 Move to done
4 Task done
Challenge day 23
1 Created 1st html webpage for this Open source 30 days challenge
2 Go to --> GitHub repo of above webpage
3 Click to go --> PR for challenge 23
Challenge day 24
[1] Open source issue creation: Finding an issue
- Issues available for community contribution: 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 towards 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: 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
-
Issues not ready for work: 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
=================================================================================
[2] Best practices around branch Branches Overview
- Regular Git Branches
- Development (dev) is the main development branch. The dev branch’s idea is to make changes in it and restrict the developers from making any changes in the master branch directly. Changes in the dev branch undergo reviews and, after testing, get merged with the master branch.
- Master (master) is the default branch available in the Git repository. It should be stable all the time and won’t allow any direct check-in. You can only merge it after code review. All team members are responsible for keeping the master stable and up-to-date.
- 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 the QA testing to get a stable codebase.
- Temporary Git Branches
- Bug Fix
- Hot Fix
- Feature Branches
- Experimental Branches
- WIP branches
- Bug – The bug which needs to be fixed soon
- WIP – The work is in progress, and I am aware it will not finish soon
=================================================================================
[3] Pull request creation Building a Great Pull Request
------------------------------------------------ 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 from develop. Developers create branches off of develop 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.”
-
There's a great blog post by Chris Beams entitled "How to Write a Git Commit Message" that's very much worth reading, but one of the most interesting points is his take on the imperative (5. Use the imperative mood in the subject line).
-
One strong reason for using the imperative? Because system-generated commits from Git itself (like "Merge branch...") are written that way.
-
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.
=================================================================================
Challenge day 25
I have gone through some "good first issues" of Open source projects for Java repositories and tried to connect with the issues as mention below
================================================================================= Afterwards I have been finding to get assigned to me one of the best Java repository which i really want to do as good first issues
=================================================================================
Updated at I have got response as assignee to good first issue
- 1st assignor
-------------------------------------------------------------------------------------------------------------------------------------------- 2) 2nd assignor
Challenge day 26
I have been got assigned and working on documentation of codebase.
- Analysing in order to the state of test of codebase.
Challenge day 27
1 Pick hash ID for cherry pick from main
2 merge conflicts resolved
3 file f1.txt in branch-1
Challenge day 30
1 Completed the 30 days open source september challenge successfully and filled the google form
3 Pull Request successfully merged on 2nd oct challenge of the day 25, Having updated last thread at bottom of challenge day 28