Git & GitHub Field Guide

Everything you need to go from zero to confidently contributing to open-source projects — with real examples.

$ git init your-career $ git push origin awesome $ git pull knowledge

🧭 What is Git?

Git is aversion control system — it tracks every change you make to your code, lets you collaborate with others, and lets you safely experiment without breaking anything. Think of it as a “save history” for your entire project, plus a superpower for teamwork.

// Install & First-Time Setup

# 1. Check if Git is already installed
git --version

# 2. Set your name and email (stored in every commit you make)
git config --global user.name  "Your Name"
git config --global user.email "you@example.com"

# 3. Verify your config
git config --list

1. Create a Repository

$ git init — the beginning of every project

A repository (repo) is a folder that Git is tracking. There are two ways to create one: start fresh on your machine, or create one on GitHub first.

Method A — Start Locally

# Create a new folder and enter it
mkdir my-awesome-project
cd my-awesome-project

# Turn this folder into a Git repo
git init

# Output:
Initialized empty Git repository in /my-awesome-project/.git/

# Create your first file
echo "# My Awesome Project" > README.md# Link your local folder to GitHub
git remote add origin https://github.com/yourusername/my-awesome-project.git

# Push your code to GitHub for the first time
git push -u origin main

Method B — Create on GitHub Then Push

1. Go to github.com → click the + → New repository
2. Give it a name (e.g.my-awesome-project), choose Public or Private
3. Click Create repository — GitHub shows you the commands to run
4. Run those commands in your terminal (shown below)

# Step 1: Initialize Git
git init

# Step 2: Create a README file
touch README.md

# Step 3: Add files to Git
git add .

# Step 4: Create first commit
git commit -m "Initial commit"

# Step 5: Rename branch to main
git branch -M main

# Step 6: Connect local project to GitHub repository
git remote add origin https://github.com/yourusername/my-awesome-project.git

# Step 7: Push code to GitHub
git push -u origin main

💡 What is origin?

"origin" is just a nickname for the remote GitHub URL. You can name it anything, but "origin" is the universal convention.

2. Clone a Repository

$ git clone — copy a project to your machine

Cloning downloads an entire repository — all files, all history — to your computer so you can work on it locally.

# Basic clone (creates a folder named after the repo)
git clone https://github.com/facebook/react.git

# Clone into a custom folder name
git clone https://github.com/facebook/react.git my-react-copy

# Clone only the latest snapshot (faster for huge repos)
git clone --depth 1 https://github.com/facebook/react.git

# After cloning, enter the folder
cd react

⚠️ Don’t have write access?

Cloning lets you read and experiment locally, but you can’t push changes back unless you have permission. For projects you don’t own, use Fork instead (see Section 08).

3. Add, Commit & Push

$ git add → git commit → git push — the daily loop

This three-step workflow is the heartbeat of Git. You’ll do this dozens of times every day.

# Check what files have changed
git status

# Stage a specific file
git add index.html

# Stage ALL changed files at once
git add .

# Commit with a message describing WHAT and WHY
git commit -m "Add hero section to homepage"

# Push to the current branch on GitHub
git push origin main

# See what you've committed so far
git log --oneline

✍️ Write good commit messages

Use the present tense imperative: “Add feature” not “Added feature”. Keep it under 72 characters. Future-you (and your team) will thank you.

✅ "Fix login bug when email contains uppercase letters" ❌ "fix stuff"

// // Undo Mistakes

# Unstage a file (undo git add)
git restore --staged index.html

# Discard changes in a file (get back last committed version)
git restore index.html

# Fix the last commit message (before pushing!)
git commit --amend -m "Better commit message"

4. Pull & Stay Updated

$ git pull — sync with the team

git pull downloads the latest changes from GitHub and merges them into your local code. Always pull before you start working each day.

# Pull latest changes from the main branch
git pull origin main

# Pull = fetch + merge (these two together equal git pull)
git fetch origin
git merge origin/main

# Pull with rebase (cleaner history — advanced)
git pull --rebase origin main

🔥 Merge Conflicts

When two people edit the same lines, Git will tell you there’s a conflict. Open the file and you’ll see markers like <<<<<<< HEAD. Edit the file to keep the right code, then git add it and git commit.

5. Pull Requests & Code Reviews

GitHub UI — propose your changes professionally

A Pull Request (PR) is how you say “I’ve made changes — please review and merge them.” It’s the cornerstone of team collaboration.

# 1. Create a feature branch
git checkout -b feature/user-login

# 2. Make your changes, then add and commit
git add .
git commit -m "Add user login with email verification"

# 3. Push this branch to GitHub
git push origin feature/user-login

Then on GitHub

1. GitHub shows a yellow banner:”Compare & pull request” — click it
2. Write a clear title and description — explain WHAT changed and WHY
3. Assign reviewers(teammates who should look at your code)
4. Add labelslikebug,enhancement,documentation
5. Click Create pull request
6. Address reviewer comments → push more commits if needed
7. Once approved, click Merge pull request→Confirm merge

📝 Great PR Description Template What:Describe what you changed. Why:Explain the reason / problem it solves. How to Test:Tell reviewers how to verify the change works. Screenshots:Include before/after images for UI changes.

6. Branching Techniques

$ git branch — work in parallel safely

A branch is an independent line of development. It’s like a parallel universe for your code — you can experiment freely without affecting the main codebase.

# List all branches (* marks current)
git branch

# Create a new branch
git branch feature/payment-gateway

# Switch to that branch
git checkout feature/payment-gateway

# Shortcut: create AND switch in one command
git checkout -b feature/payment-gateway

# Modern alternative (Git 2.23+)
git switch -c feature/payment-gateway

# Merge your branch into main
git checkout main
git merge feature/payment-gateway

# Delete a branch (after it's merged)
git branch -d feature/payment-gateway

# Delete the remote branch too
git push origin --delete feature/payment-gateway

main      ●─────────────────────────────● ← merge
           \                          /
feature/    ●───●───●───●──/
  Branches keep your work isolated until it's ready

Branch Naming Conventions (use these!)

feature/user-authentication   # New feature
fix/login-redirect-bug        # Bug fix
hotfix/critical-payment-error # Urgent production fix
docs/update-readme            # Documentation only
chore/upgrade-dependencies    # Maintenance task
refactor/clean-auth-module    # Code cleanup

🌿 Git Flow Strategy

Most teams use:

main(production-ready),

develop(integration),

**feature/***(your work),

**release/***(prepare a release),

**hotfix/***(emergency fixes).

Never commit directly to main!

7. Forking a Repository

GitHub UI + git clone — your own copy of someone else’s project

A fork is a complete copy of a repository under your own GitHub account. Unlike cloning, a fork lives on GitHub and stays linked to the original project. This is how open source works.

# 1. On GitHub: click the "Fork" button on any repo page
#    → it appears under YOUR account as yourusername/repo-name

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

# 3. Add the original repo as "upstream" to sync later
git remote add upstream https://github.com/ORIGINAL-OWNER/repo-name.git

# 4. Verify remotes
git remote -v
# origin   → your fork (you can push here)
# upstream → original repo (you can only pull from here)

🔄 Keep your fork updated git fetch upstream git checkout main git merge upstream/main git push origin main

8. ⭐ Contributing to Open Source

Fork → Branch → Code → PR — the complete workflow

🌍 This is the most important section.

Open source contribution is how you build a real portfolio, learn from world-class engineers, and give back to the community. This section walks you through the entire process end-to-end.

The Complete Open Source Workflow

Step 1 — Find a project & read the rules

1. Go to github.com/explore or search forgood first issueorbeginner friendlylabels
2. Read CONTRIBUTING.md — every project has contribution rules. Never skip this.
3. Read the CODE_OF_CONDUCT.md — understand how to communicate
4. Look at existing PRs to understand what’s acceptable

Step 2 — Fork & Clone

# Fork the repo on GitHub, then clone YOUR fork
git clone https://github.com/YOUR-USERNAME/project-name.git
cd project-name

# Add upstream so you can sync with the original
git remote add upstream https://github.com/ORIGINAL-OWNER/project-name.git

# Verify
git remote -v
origin    https://github.com/YOUR-USERNAME/project-name.git (fetch)
origin    https://github.com/YOUR-USERNAME/project-name.git (push)
upstream  https://github.com/ORIGINAL-OWNER/project-name.git (fetch)
upstream  https://github.com/ORIGINAL-OWNER/project-name.git (push)

Step 3 — Sync with upstream before starting work

# Always sync BEFORE starting any new work
git fetch upstream
git checkout main
git merge upstream/main

# Push the update to your fork too
git push origin main

✓ Your fork is now up to date with the original project

Step 4 — Create a dedicated feature branch

# NEVER work on main! Always create a branch for your change
git checkout -b fix/typo-in-readme

# Or for a feature
git checkout -b feature/add-dark-mode

Step 5 — Make your changes

# Make your code changes using your editor...
# Then check what you changed
git status
git diff

# Stage and commit with a clear message
git add .
git commit -m "Fix typo in installation section of README"

# If you make more changes, commit again
git add .
git commit -m "Add missing semicolons in example code"

Step 6 — Sync again before pushing (prevent conflicts!)

# Check if the original project got new commits while you worked
git fetch upstream

# Rebase your branch on top of the latest upstream changes
git rebase upstream/main

# If there are conflicts, Git pauses and tells you which file
# Fix the conflict in your editor, then:
git add the-conflicted-file.js
git rebase --continue

# If you want to abort and start over
git rebase --abort

Step 7 — Push to your fork

# Push your branch to YOUR fork (origin)
git push origin fix/typo-in-readme

# If you rebased, you may need force push (safe for your own branch)
git push --force-with-lease origin fix/typo-in-readme

Step 8 — Open the Pull Request

1. Go to your fork on GitHub — you’ll see a green”Compare & pull request”button
2. Make sure the base repository is the original project and base ismain
3. Make sure head repository is your fork and compare is your branch
4. Write a clear title:"Fix: typo in README installation section"
5. Fill in the PR description (use the template if the project has one)
6. Link the related issue if there is one: typeCloses #42in the description
7. Click Create pull request

Step 9 — Handle review feedback

# A maintainer requested changes — make them locally
# (you're still on your feature branch)
git checkout fix/typo-in-readme

# Make the requested edits, then commit
git add .
git commit -m "Address review: use consistent code style"

# Push again — the PR updates automatically!
git push origin fix/typo-in-readme

✓ Your PR is updated. Leave a comment: "Ready for re-review!"

Step 10 — After merge, clean up

# Celebrate! Your code is in the project 🎉
# Now clean up your local environment

# Switch back to main
git checkout main

# Sync your fork with the now-merged changes
git fetch upstream
git merge upstream/main
git push origin main

# Delete the feature branch (it's merged, no longer needed)
git branch -d fix/typo-in-readme
git push origin --delete fix/typo-in-readme

✓ Clean slate — ready for your next contribution!

🎯 Pro Tips for Open Source Success

• Start with documentation fixes or typos — they’re always welcome and low-risk • Comment on an issue first: “I’d like to work on this, is it available?” • Keep PRs small and focused — one PR, one change • Be patient — maintainers are volunteers • Never argue with feedback — learn from it • Good projects to start: freeCodeCamp, React, VS Code, first-contributions

10. Cheat Sheet & Pro Tips

All the commands you’ll use every day

git initInitialize a new repo in current folder

git clone <url>Download a repo from GitHub

git statusSee what files changed

git add .Stage all changes

git commit -m "msg"Save a snapshot with message

git push origin mainUpload commits to GitHub

git pull origin mainDownload latest changes

git branch -aList all branches

git checkout -b nameCreate and switch to new branch

git merge branchMerge branch into current

git log --onelineSee compact commit history

git diffSee exact lines changed

git stashTemporarily save unfinished work

git stash popRestore stashed changes

git remote -vList remote connections

git fetch upstreamGet updates from original repo

git rebase upstream/mainReplay your commits on top of latest

git reset --soft HEAD~1Undo last commit, keep changes staged

🚀 Useful Git aliases (add to your config) git config --global alias.st status git config --global alias.co checkout git config --global alias.lg "log --oneline --graph --decorate"

Now git st = git status and git lg shows a beautiful visual history.

🛡️ Golden Rules (never break these) 1.Never force-push to main(or any shared branch) 2.Never commit secrets — API keys, passwords, tokens. Use .gitignore 3.Always branch— even for small fixes 4.Write meaningful commit messages— your future self will thank you 5.Pull before you push— always sync first

Written for beginners who want to become contributors.

git commit -m “start your open source journey”