Git & GitHub
Forking and Contributing
Forking and Contributing
Contributing to open source projects is one of the best ways to improve your skills, build your portfolio, and give back to the developer community. Understanding forking and the contribution workflow is essential for participating in collaborative development.
What is Forking?
A fork is a complete copy of a repository under your GitHub account. It allows you to freely experiment with changes without affecting the original project.
Key Difference: Cloning creates a local copy on your computer, while forking creates a remote copy on your GitHub account. You typically fork first, then clone your fork.
Fork vs Clone
Understanding the difference is crucial:
Forking (GitHub):
- Creates a copy on your GitHub account
- Maintains connection to original repository
- Allows you to propose changes via Pull Requests
- You have full control over your fork
- Done through GitHub web interface
Cloning (Git):
- Creates a local copy on your computer
- Downloads repository to work locally
- No automatic connection to your GitHub account
- Used for both your repos and forks
- Done through git clone command
How to Fork a Repository
Forking is simple on GitHub:
1. Navigate to the repository you want to fork
Example: https://github.com/facebook/react
2. Click the "Fork" button in the top-right corner
3. GitHub creates a copy under your account
Your fork: https://github.com/YourUsername/react
4. You now have full control over this copy
Pro Tip: Before forking, check if the project accepts contributions by reading their CONTRIBUTING.md file and checking for recent merged Pull Requests.
Setting Up Your Fork Locally
After forking, clone your fork to work locally:
# Clone YOUR fork (not the original)
git clone https://github.com/YourUsername/react.git
cd react
# Verify remote
git remote -v
# origin https://github.com/YourUsername/react.git (fetch)
# origin https://github.com/YourUsername/react.git (push)
Adding Upstream Remote
Connect your fork to the original repository to stay synchronized:
# Add the original repository as "upstream"
git remote add upstream https://github.com/facebook/react.git
# Verify remotes
git remote -v
# origin https://github.com/YourUsername/react.git (fetch)
# origin https://github.com/YourUsername/react.git (push)
# upstream https://github.com/facebook/react.git (fetch)
# upstream https://github.com/facebook/react.git (push)
Naming Convention: "origin" refers to YOUR fork, "upstream" refers to the ORIGINAL repository. This is a standard convention in open source.
Keeping Your Fork Synchronized
Keep your fork up-to-date with the original project:
# Fetch latest changes from upstream
git fetch upstream
# Switch to your main branch
git checkout main
# Merge upstream changes into your main
git merge upstream/main
# Push updates to your fork on GitHub
git push origin main
Alternatively, use rebase for a cleaner history:
git fetch upstream
git checkout main
git rebase upstream/main
git push origin main --force-with-lease
Important: Always sync your fork before starting new work to avoid conflicts and ensure you're working with the latest code.
The Complete Contribution Workflow
Here's the step-by-step process for contributing:
# Step 1: Fork the repository on GitHub
# (Click Fork button)
# Step 2: Clone your fork
git clone https://github.com/YourUsername/project.git
cd project
# Step 3: Add upstream remote
git remote add upstream https://github.com/OriginalOwner/project.git
# Step 4: Create a feature branch
git checkout -b fix/typo-in-readme
# Step 5: Make your changes
# Edit files...
# Step 6: Commit with clear message
git add README.md
git commit -m "Fix typo in installation instructions"
# Step 7: Push to your fork
git push origin fix/typo-in-readme
# Step 8: Create Pull Request on GitHub
# Navigate to your fork and click "Compare & pull request"
# Step 9: Wait for review and respond to feedback
# Step 10: After merge, sync and clean up
git checkout main
git fetch upstream
git merge upstream/main
git push origin main
git branch -d fix/typo-in-readme
First Contribution Best Practices
Make your first contribution count:
Before Contributing:
✓ Read CONTRIBUTING.md and CODE_OF_CONDUCT.md
✓ Check existing issues and PRs (avoid duplicates)
✓ Look for "good first issue" or "beginner-friendly" labels
✓ Understand the project's coding style
✓ Make sure tests pass locally
When Contributing:
✓ Start small (fix typos, improve documentation)
✓ Follow the project's commit message format
✓ Write clear PR descriptions
✓ Be respectful and patient with maintainers
✓ Respond promptly to review feedback
Finding Projects to Contribute To
Discover open source projects that need help:
GitHub Explore:
https://github.com/explore
- Browse trending repositories
- Filter by language and topics
Good First Issue:
https://goodfirstissue.dev/
- Curated list of beginner-friendly issues
First Timers Only:
https://www.firsttimersonly.com/
- Resources for first-time contributors
Up For Grabs:
https://up-for-grabs.net/
- Projects with tasks for new contributors
GitHub Topics:
Search: topic:hacktoberfest good-first-issue
Open Source Etiquette
Follow these guidelines to be a respectful contributor:
DO:
✓ Be polite and professional
✓ Ask questions if unclear
✓ Accept feedback gracefully
✓ Give credit to others
✓ Follow project guidelines
✓ Test your changes thoroughly
✓ Keep PRs focused and small
DON'T:
✗ Make demands or expect instant responses
✗ Submit low-quality or spam PRs
✗ Ignore feedback from maintainers
✗ Take criticism personally
✗ Force your preferred approach
✗ Make multiple PRs for the same issue
Golden Rule: Maintainers are volunteers giving their time. Be patient, respectful, and grateful for their efforts.
Writing Contribution-Friendly PRs
Make it easy for maintainers to review and merge your contribution:
Title:
Fix: Correct typo in installation documentation
Description:
## What
Fixed a typo in the installation section of README.md.
Changed "installl" to "install" on line 23.
## Why
The typo might confuse new users following the installation guide.
## Related Issue
Fixes #1234
## Checklist
- [x] Read CONTRIBUTING.md
- [x] Followed code style guidelines
- [x] All tests pass locally
- [x] Updated documentation if needed
- [x] Added tests for new functionality (N/A)
## Screenshots
[If applicable]
Responding to Review Feedback
Handle feedback professionally:
Positive Response Example:
"Thanks for the feedback! I've updated the code to use the
suggested approach. Please let me know if anything else needs
to be changed."
When You Disagree:
"I understand your concern. I chose this approach because [reason].
However, I'm open to alternatives. What do you think about [option]?"
When Unsure:
"I'm not sure I understand the issue. Could you provide an
example or point me to documentation? I'd like to learn more."
After Your PR is Merged
Celebrate and clean up:
# Sync your fork with upstream
git checkout main
git fetch upstream
git merge upstream/main
git push origin main
# Delete your feature branch locally
git branch -d fix/typo-in-readme
# Delete remote branch (GitHub usually does this automatically)
git push origin --delete fix/typo-in-readme
# Celebrate! You're now an open source contributor!
Building Your Open Source Portfolio
Track and showcase your contributions:
On Your Resume/Portfolio:
- Link to your GitHub profile
- Highlight significant contributions
- Mention projects you've contributed to
- Include any maintainer roles
GitHub Profile:
- Pin your best contributions
- Write a compelling bio
- Include links to your work
- Keep contribution graph active
Contribution Examples:
- "Contributed bug fixes to React (10k+ stars)"
- "Improved documentation for Vue.js"
- "Maintainer of [project-name]"
- "Active contributor to open source since 2023"
Becoming a Maintainer
Progress from contributor to maintainer:
Path to Maintainer:
1. Make consistent, quality contributions
2. Help review others' PRs
3. Answer issues and help users
4. Improve documentation
5. Express interest in maintaining
6. Earn trust of current maintainers
7. Receive maintainer/committer access
Maintainer Responsibilities:
- Review and merge Pull Requests
- Triage and respond to issues
- Enforce code of conduct
- Make architectural decisions
- Release new versions
- Mentor new contributors
Practical Exercise:
Task: Make your first open source contribution
- Find a project on GitHub with "good first issue" label
- Fork the repository to your account
- Clone your fork locally
- Add the upstream remote
- Create a feature branch for your fix
- Make your changes and commit them
- Push to your fork
- Create a Pull Request with a detailed description
- Respond to any review feedback
- After merge (or closure), sync your fork
Expected Outcome: You'll have hands-on experience with the complete open source contribution workflow.
Common Forking Scenarios
Scenario 1: Contributing to a project
Fork → Clone → Branch → Commit → Push → Pull Request
Scenario 2: Creating your own version
Fork → Modify extensively → Maintain independently
Scenario 3: Experimenting safely
Fork → Try new features → Delete if unsuccessful
Scenario 4: Syncing with upstream
Fetch upstream → Merge/Rebase → Push to your fork
Summary
In this lesson, you learned:
- Forking creates a personal copy of a repository on GitHub
- Fork vs clone: fork is remote, clone is local
- Upstream remote connects your fork to the original repository
- Complete contribution workflow: fork → clone → branch → commit → PR
- Keep your fork synchronized with upstream regularly
- Open source etiquette: be respectful and patient
- Good first issues are perfect for beginners
- Building an open source portfolio enhances your career
Next Up: In the next lesson, we'll explore GitHub Actions for automating your development workflow!