Git Notes

Hub Benefits of Git and GitHub - Why They Matter Git vs GitHub Version Control System What Is Git What Is GitHub Configure Git - User Identity and Settings Create GitHub Account - Sign Up Guide First Git Repository - Getting Started Install Git on Linux - Complete Setup Guide Install Git on macOS - Installation Guide Install Git on Windows - Step-by-Step Guide Git Add - Stage Changes Git Clone - Copy Remote Repositories Locally Git Commit - Save Changes Git Diff - Compare Changes in Your Repository Git Ignore - Exclude Files from Version Control Git Init - Initialize Repository Git Log - View Commit History Git Status - Check Repository State Git Fetch - Download Remote Changes Without Merging Git Pull - Fetch and Merge Remote Changes Git Push - Upload Local Commits to Remote Repository Git Remote - Manage Remote Repository Connections Local Repository - Understanding Your Git Working Environment Remote Repository - Collaborate Through Shared Repositories Sync Local and Remote - Keep Repositories in Harmony Amend Commit - Fix Last Commit Delete Branch - Clean Up Branches Git Reset - Move HEAD and Undo Commits Git Restore - Discard Changes Git Revert - Safely Undo Changes Recover Lost Commits - Reflog Guide Fork Repository GitHub Pages GitHub Profile Setup GitHub Repositories GitHub Stars and Watchers Repository Settings Code Reviews Git Clone Git Fetch Git Pull Git Push GitHub Issues Labels and Milestones Open Source Contributions GitHub Project Boards Pull Requests - Propose and Review Code Changes Team Collaboration with Git and GitHub Automated Testing with GitHub Actions CI/CD with GitHub Actions Deployment Automation with GitHub Actions Introduction to GitHub Actions GitHub Actions Runners GitHub Actions Workflows Enterprise Git Workflows - Scale Git for Large Organizations Feature Branch Workflow - Isolate Development Work GitFlow Workflow - Structured Release Management Monorepo Workflow - Manage Multiple Projects in One Repository Trunk-Based Development - Ship Code Fast and Safely Deployment Workflows GitHub Pages Deployment Netlify Deployment from GitHub Render Deployment from GitHub Vercel Deployment from GitHub Branch Protection Rules - Secure Your Git Branches Personal Access Tokens - Authenticate with GitHub Repository Security Best Practices Secret Scanning - Detect Leaked Credentials in Code Signed Commits - Verify Commit Authenticity with GPG SSH Keys - Secure Git Authentication Without Passwords Git Bisect - Find Bugs with Binary Search Git Cherry-Pick - Apply Specific Commits to Any Branch Git Hooks - Automate Workflows with Git Events Git Internals - Understanding How Git Works Under the Hood Git Stash - Temporarily Save Uncommitted Changes Git Submodules - Manage External Dependencies as Git Repos Git Tag - Mark Important Points in History Git Worktrees - Work on Multiple Branches Simultaneously Collaborative Web App Project Complete Team Workflow Project GitHub Actions Project - Build a CI/CD Pipeline Open Source Project Contribution - Guided Exercise Portfolio Project with Git - Showcase Your Skills Git Command Cheatsheet Git Interview Questions - Comprehensive Preparation Guide GitHub Interview Questions Scenario-Based Git Interview Questions Git Troubleshooting Guide Git Best Practices - Professional Development Habits Common Git Errors and Fixes - Quick Solutions Git Command Reference - Complete Command Guide Learning Resources - Continue Your Git & GitHub Education Branch Strategies - Choosing the Right Git Branching Model Create Branch in Git - Start New Development Lines Fast-Forward Merge in Git - Clean Linear History Git Branch Git Checkout Git Merge Git Rebase Merge Branches in Git - Combine Development Work Merge Conflicts - Resolve Git Conflicts Like a Pro Switch Branch in Git - Navigate Between Branches

Open Source Project Contribution - Guided Exercise

Practice contributing to open source through a structured exercise. Fork, fix, and submit a PR following best practices for community contribution.

Contributing to open source is one of the most valuable things you can do as a developer. It builds your portfolio with publicly visible work, connects you with experienced developers worldwide, teaches you professional collaboration practices, and demonstrates to employers that you can work effectively in codebases you did not create. Many developers land jobs directly because a hiring manager saw their open-source contributions.

This exercise guides you through making your first real contribution, from finding a project to getting your pull request merged.

Step 1: Find a Suitable Project

Not all projects are beginner-friendly. Look for these signals that a project welcomes new contributors:

bash example

# Search GitHub for beginner-friendly issues
# Use these filter combinations:
#   label:"good first issue" language:javascript is:open
#   label:"help wanted" language:python is:open stars:>100
#   label:"beginner friendly" is:open

Recommended starter projects:

first-contributions — Designed specifically for first-time contributors
EddieHubCommunity — Welcoming community with mentorship
freeCodeCamp — Large project with many issues
Any project you actually use that has "good first issue" labels

Signs of a healthy project:

Recent commits (active maintenance)
Responsive to issues and PRs (check response times)
Has CONTRIBUTING.md with clear guidelines
Uses labels to categorize issues
Has a Code of Conduct

Step 2: Fork and Clone the Repository

bash example

# 1. Fork on GitHub (click the "Fork" button on the repository page)
# This creates a copy under your account

# 2. Clone YOUR fork (not the original)
git clone https://github.com/YOUR-USERNAME/project.git
cd project

# 3. Add the original repository as "upstream"
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git

# 4. Verify your remotes
git remote -v

Output

origin    https://github.com/YOUR-USERNAME/project.git (fetch)
origin    https://github.com/YOUR-USERNAME/project.git (push)
upstream  https://github.com/ORIGINAL-OWNER/project.git (fetch)
upstream  https://github.com/ORIGINAL-OWNER/project.git (push)

Step 3: Set Up the Development Environment

Every well-maintained project has setup instructions. Follow them precisely:

Example

# Read the contributing guide FIRST cat CONTRIBUTING.md # Install dependencies (varies by project) npm install # JavaScript/Node.js pip install -e . # Python bundle install # Ruby make setup # C/C++/Go # Run the test suite to confirm everything works BEFORE making changes npm test # All tests should pass. If they don't, check the README for prerequisites

If you encounter setup issues, check existing GitHub Issues — someone probably had the same problem.

Step 4: Create a Feature Branch

Never work directly on main. Always create a branch:

bash example

# Sync your fork with upstream first
git fetch upstream
git checkout main
git merge upstream/main

# Create a descriptive branch
git checkout -b fix/improve-error-message-for-invalid-email

# Branch naming conventions vary by project. Common patterns:
# fix/description
# feat/description
# docs/description
# Issue number: fix/123-email-validation

Step 5: Make Your Contribution

Types of contributions ranked by difficulty:

Fix typos in documentation (easiest, great for first contribution)
Improve error messages (helps users, low risk)
Add missing tests (improves quality, teaches you the codebase)
Fix bugs labeled "good first issue" (real impact)
Update outdated dependencies (maintenance work)
Add small features (most impactful, requires understanding)

bash example

# Make focused changes — one issue per PR
# Follow the project's code style exactly
# Run linting and tests after making changes

# Example: fixing a documentation typo
code docs/installation.md
# Make your fix...

# Example: fixing a labeled bug
code src/validation.js
# Implement the fix following existing patterns...

# Run tests to verify nothing broke
npm test
npm run lint

Step 6: Commit with Clear Messages

Follow the project's commit conventions (check CONTRIBUTING.md):

bash example

# Stage your changes
git add docs/installation.md

# Commit with a clear message
git commit -m "docs: fix typo in installation guide"

# If the project references issues:
git commit -m "fix: validate email format before submission

Closes #234"

Step 7: Push and Create a Pull Request

bash example

# Push your branch to YOUR fork (origin)
git push -u origin fix/improve-error-message-for-invalid-email

Then on GitHub:

Navigate to the original repository
Click "Compare & pull request" (GitHub prompts you automatically)
Fill out the PR template completely
Reference the issue number (e.g., "Fixes #234")
Explain what you changed and why
Include screenshots if it is a visual change

Step 8: Respond to Review Feedback

Maintainers will review your PR. Be prepared for:

Requests to change code style
Suggestions for different approaches
Questions about your implementation decisions

bash example

# Make requested changes
code src/validation.js
git add src/validation.js
git commit -m "fix: address review feedback - add edge case handling"
git push

# The PR updates automatically

Etiquette tips:

Be patient — maintainers are volunteers
Be respectful and grateful for feedback
Respond to all comments, even if just "Done!"
Do not take rejection personally — learn from it
Thank reviewers for their time

Step 9: After Your PR Is Merged

bash example

# Celebrate! Then clean up:
git checkout main
git pull upstream main
git push origin main
git branch -d fix/improve-error-message-for-invalid-email

Now find your next contribution. Each successive PR builds on the relationships and knowledge you gained.

Common Mistakes in Open Source

Mistake 1: Opening a PR without reading CONTRIBUTING.md. Projects have specific processes, and ignoring them signals that you do not respect the maintainers' time.

Mistake 2: Making unsolicited large PRs. For anything beyond a typo fix, comment on the issue first saying "I would like to work on this" and wait for assignment.

Mistake 3: Changing formatting or style across the whole project. Only change what is needed for your fix unless asked to do otherwise.

Mistake 4: Disappearing after getting review feedback. If you cannot complete the work, say so. Maintainers would rather reassign than wait indefinitely.

Interview Questions

Q1: Describe your open source contribution process.

I find projects using "good first issue" labels in technologies I use, read their CONTRIBUTING.md, fork and clone, set up the development environment, create a focused branch, make the change with tests, push to my fork, and open a well-documented PR. I respond to review feedback promptly.

Q2: What did you learn from contributing to open source?

Following project conventions is crucial, communication matters (comment before starting work), small focused PRs get reviewed faster, testing is expected, and maintainers appreciate contributors who follow the process rather than creating work for them.

Q3: How do you find projects to contribute to?

GitHub Explore page, "good first issue" label searches filtered by language, technologies I use daily that have active issue trackers, awesome-lists on GitHub, and community recommendations from developer Discord servers and forums.

Q4: What makes a contribution likely to be accepted?

Following the project's contribution guidelines exactly, keeping changes small and focused, including tests when appropriate, writing a clear PR description with context, communicating with maintainers before starting large changes, and being responsive to feedback.

Q5: How has open source contribution helped your career?

Built a public portfolio of real-world code, improved code review and collaboration skills, networked with industry professionals who later became references, learned professional-grade codebases with real-world complexity, and demonstrated to employers the ability to work in unfamiliar environments.

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Open Source Project Contribution - Guided Exercise.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.

Search Terms

git-github, git & github, git, github, projects, open, source, project

Related Git & GitHub Topics

Continue learning this concept

ProjectsCollaborative Web App ProjectThis project guides you through building a web application as a team using professional Git and GitHub workflows. You will experience the complete software...ProjectsComplete Team Workflow ProjectThis capstone project simulates a full team development workflow from start to finish. You will practice every aspect of professional Git and GitHub usage —...ProjectsGitHub Actions Project - Build a CI/CD PipelineHands-on project building a complete CI/CD pipeline with GitHub Actions. Set up testing, building, deployment, and monitoring automation.ProjectsPortfolio Project with Git - Showcase Your SkillsBuild a developer portfolio website while demonstrating Git best practices. Use proper commits, branching, and deployment to showcase both coding and Git skills.CollaborationOpen Source ContributionsContributing to open source projects is one of the best ways to improve your development skills, build a professional reputation, and give back to the...CollaborationGitHub Project BoardsGitHub Projects (formerly Project Boards) is a built-in project management tool that brings Kanban-style and table-style views directly into your GitHub...

PreviousGitHub Actions Project - Build a CI/CD Pipeline NextPortfolio Project with Git - Showcase Your Skills

Git Notes

Open Source Project Contribution - Guided Exercise

Practice contributing to open source through a structured exercise. Fork, fix, and submit a PR following best practices for community contribution.

This exercise guides you through making your first real contribution, from finding a project to getting your pull request merged.

Step 1: Find a Suitable Project

Not all projects are beginner-friendly. Look for these signals that a project welcomes new contributors:

bash example

# Search GitHub for beginner-friendly issues
# Use these filter combinations:
#   label:"good first issue" language:javascript is:open
#   label:"help wanted" language:python is:open stars:>100
#   label:"beginner friendly" is:open

Recommended starter projects:

first-contributions — Designed specifically for first-time contributors
EddieHubCommunity — Welcoming community with mentorship
freeCodeCamp — Large project with many issues
Any project you actually use that has "good first issue" labels

Signs of a healthy project:

Recent commits (active maintenance)
Responsive to issues and PRs (check response times)
Has CONTRIBUTING.md with clear guidelines
Uses labels to categorize issues
Has a Code of Conduct

Step 2: Fork and Clone the Repository

bash example

# 1. Fork on GitHub (click the "Fork" button on the repository page)
# This creates a copy under your account

# 2. Clone YOUR fork (not the original)
git clone https://github.com/YOUR-USERNAME/project.git
cd project

# 3. Add the original repository as "upstream"
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git

# 4. Verify your remotes
git remote -v

Output

origin    https://github.com/YOUR-USERNAME/project.git (fetch)
origin    https://github.com/YOUR-USERNAME/project.git (push)
upstream  https://github.com/ORIGINAL-OWNER/project.git (fetch)
upstream  https://github.com/ORIGINAL-OWNER/project.git (push)

Step 3: Set Up the Development Environment

Every well-maintained project has setup instructions. Follow them precisely:

Example

If you encounter setup issues, check existing GitHub Issues — someone probably had the same problem.

Step 4: Create a Feature Branch

Never work directly on main. Always create a branch:

bash example

# Sync your fork with upstream first
git fetch upstream
git checkout main
git merge upstream/main

# Create a descriptive branch
git checkout -b fix/improve-error-message-for-invalid-email

# Branch naming conventions vary by project. Common patterns:
# fix/description
# feat/description
# docs/description
# Issue number: fix/123-email-validation

Step 5: Make Your Contribution

Types of contributions ranked by difficulty:

Fix typos in documentation (easiest, great for first contribution)
Improve error messages (helps users, low risk)
Add missing tests (improves quality, teaches you the codebase)
Fix bugs labeled "good first issue" (real impact)
Update outdated dependencies (maintenance work)
Add small features (most impactful, requires understanding)

bash example

# Make focused changes — one issue per PR
# Follow the project's code style exactly
# Run linting and tests after making changes

# Example: fixing a documentation typo
code docs/installation.md
# Make your fix...

# Example: fixing a labeled bug
code src/validation.js
# Implement the fix following existing patterns...

# Run tests to verify nothing broke
npm test
npm run lint

Step 6: Commit with Clear Messages

Follow the project's commit conventions (check CONTRIBUTING.md):

bash example

# Stage your changes
git add docs/installation.md

# Commit with a clear message
git commit -m "docs: fix typo in installation guide"

# If the project references issues:
git commit -m "fix: validate email format before submission

Closes #234"

Step 7: Push and Create a Pull Request

bash example

# Push your branch to YOUR fork (origin)
git push -u origin fix/improve-error-message-for-invalid-email

Then on GitHub:

Navigate to the original repository
Click "Compare & pull request" (GitHub prompts you automatically)
Fill out the PR template completely
Reference the issue number (e.g., "Fixes #234")
Explain what you changed and why
Include screenshots if it is a visual change

Step 8: Respond to Review Feedback

Maintainers will review your PR. Be prepared for:

Requests to change code style
Suggestions for different approaches
Questions about your implementation decisions

bash example

# Make requested changes
code src/validation.js
git add src/validation.js
git commit -m "fix: address review feedback - add edge case handling"
git push

# The PR updates automatically

Etiquette tips:

Be patient — maintainers are volunteers
Be respectful and grateful for feedback
Respond to all comments, even if just "Done!"
Do not take rejection personally — learn from it
Thank reviewers for their time

Step 9: After Your PR Is Merged

bash example

# Celebrate! Then clean up:
git checkout main
git pull upstream main
git push origin main
git branch -d fix/improve-error-message-for-invalid-email

Now find your next contribution. Each successive PR builds on the relationships and knowledge you gained.

Common Mistakes in Open Source

Mistake 1: Opening a PR without reading CONTRIBUTING.md. Projects have specific processes, and ignoring them signals that you do not respect the maintainers' time.

Mistake 2: Making unsolicited large PRs. For anything beyond a typo fix, comment on the issue first saying "I would like to work on this" and wait for assignment.

Mistake 3: Changing formatting or style across the whole project. Only change what is needed for your fix unless asked to do otherwise.

Mistake 4: Disappearing after getting review feedback. If you cannot complete the work, say so. Maintainers would rather reassign than wait indefinitely.

Interview Questions

Q1: Describe your open source contribution process.

Q2: What did you learn from contributing to open source?

Q3: How do you find projects to contribute to?

Q4: What makes a contribution likely to be accepted?

Q5: How has open source contribution helped your career?

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Open Source Project Contribution - Guided Exercise.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.

Search Terms

git-github, git & github, git, github, projects, open, source, project

Related Git & GitHub Topics

Continue learning this concept

PreviousGitHub Actions Project - Build a CI/CD Pipeline NextPortfolio Project with Git - Showcase Your Skills