Learn Git, GitHub &
VS Code Source Control
A visual, hands-on guide for any student or first-time coder: track changes, save meaningful checkpoints, publish projects to GitHub, and work confidently in VS Code.
What Is Version Control?
Picture this: you have been building your first program or website for hours. You finally get it working, try one more improvement, and suddenly nothing works. This is the problem that version control was built to solve.
Version control is a system that tracks changes to your files over time. Think of it like a very detailed "undo history" for your entire project — not just the last few keystrokes, but every meaningful change you've ever saved, with notes about what changed and why.
The Problem Without Version Control
Without version control, beginners commonly fall into patterns like these:
- Saving files as
project_final.py,project_final2.py,project_FINAL_v3_actually.py - Accidentally overwriting working code with broken experiments
- Having no way to tell what changed between two versions
- Sharing code through email or USB drives — a collaboration nightmare
Why It Matters for Every New Coder
Whether you are completing a class project, making a portfolio website, analyzing data, or contributing to an open-source project, your work will grow and change. Version control lets you experiment safely, restore known-working versions, share your progress, and build the workflow expected in software teams.
Understanding Git
Git is a free, open-source version control system created by Linus Torvalds in 2005 — the same person who created the Linux operating system. It runs entirely on your own computer and does not require an internet connection to function.
When you use Git, it creates a hidden folder called .git inside your project directory. That folder is the "database" — it stores every snapshot of your project you've ever saved. The directory it tracks is called a repository (or "repo" for short).
Core Concepts
Three Zones You Must Know
| Zone | Description | Command to move files here |
|---|---|---|
| Working Directory | Where you edit your actual files. Changes here are "untracked" until you tell Git about them. | — |
| Staging Area (Index) | A preview zone. Files you've selected as "ready to save" sit here before they become a commit. | git add filename |
| Repository | The permanent record. A commit moves staged changes into the repo and creates a snapshot with a unique ID. | git commit -m "message" |
git commit and wonder why the commit is empty. The reason: the change was not staged with git add. Git deliberately lets you pick exactly which changes belong in each commit.
Understanding GitHub
GitHub is an online hosting and collaboration platform for Git repositories. When you push a local Git repository to GitHub, you create an online copy you can access from another computer and share with teammates, teachers, reviewers, or future employers when appropriate.
GitHub adds a social and collaborative layer on top of Git. You can browse code, open issues (like bug reports), review changes before they're merged, and contribute to projects happening anywhere in the world — including the open-source software that powers most of what you use daily.
What GitHub Adds
- Remote hosting — your code is backed up in the cloud, not just your laptop.
- Pull Requests (PRs) — a formal way to propose code changes and request review before merging.
- Issues & Project Boards — built-in task tracking. You can file bug reports, feature requests, and track what's in progress.
- GitHub Actions — automated workflows that run tests, build your code, or deploy your app every time you push.
- GitHub Pages — free static website hosting directly from a repository (useful for portfolio sites).
- GitHub Codespaces — a full development environment in your browser, no local install needed.
Git vs GitHub — The Clear Distinction
This is probably the most common source of confusion for beginners, and it's worth making the distinction crystal clear before going further.
- Software installed on your computer
- Works 100% offline — no internet needed
- Free and open-source (MIT-licensed)
- Manages version history locally
- No account or login required
- Command-line tool (no website)
- Created by Linus Torvalds, 2005
- A website and cloud service
- Requires internet access
- Free for public repos (paid plans available)
- Hosts Git repositories online
- Requires a free account to use
- Has a full web interface + features
- Founded 2008; acquired by Microsoft 2018
| Aspect | Git | GitHub |
|---|---|---|
| Type | Software (CLI tool) | Web platform / service |
| Internet required? | No | Yes |
| Main purpose | Track changes locally | Share, collaborate, backup |
| Collaboration | Not built-in | Core feature (PRs, Issues, Forks) |
| Storage location | Your machine | The cloud |
| Learning curve | Steeper (command-line) | Gentler (visual UI + CLI) |
| Can exist without the other? | Yes — Git works standalone | No — GitHub requires Git repos |
Essential Commands
You can control Git from a terminal (PowerShell, Terminal, Git Bash, or another shell) or through VS Code. Learning the small command-line vocabulary below makes every visual tool easier to understand.
Install and Set Up Git Once
Install Git from git-scm.com, then open a terminal and tell Git who you are. This identity is attached to each commit.
noreply address before committing.
Starting a Repository
# OR clone an existing repo from GitHub git clone https://github.com/username/repo-name.git
The Daily Loop — Add, Commit, Push
After you edit files, this three-step cycle is how you save your work and share it. Memorize this loop; you'll use it thousands of times.
# Step 1: Stage the files you want to commit git add main.py # Or stage everything at once: git add .
# Step 2: Commit with a clear, descriptive message git commit -m "Add user input validation to main.py" [main 3f4a1c2] Add user input validation to main.py 1 file changed, 12 insertions(+), 2 deletions(-)
# Step 3: Push to GitHub (sync to remote) git push origin main Enumerating objects: 5, done. To https://github.com/username/my-project.git
Viewing History & Differences
# See what changed in your files (not yet staged) git diff # See what's staged but not yet committed git diff --staged
Pulling Changes From GitHub
Try It: Animated Demo
Click Run Demo to watch a first project move through the four stages. The highlighted label tells you where the current command fits in both the terminal and VS Code.
Ready: create a file, stage it, commit it, then push it to GitHub.
git add, the Commit button performs git commit, and Publish Branch or Sync Changes connects to and updates a remote such as GitHub.
Command Reference
| Command | What It Does |
|---|---|
git init | Initialize a new Git repository in the current folder |
git clone <url> | Download a repository from GitHub to your computer |
git status | See which files have changed and what's staged |
git add <file> | Stage a file (or git add . for all changes) |
git commit -m "msg" | Save staged changes as a commit with a message |
git push origin main | Upload your commits to GitHub |
git pull origin main | Download and merge remote changes into your branch |
git log --oneline | View the compact commit history |
git diff | Show line-by-line changes in modified files |
git restore <file> | Discard local changes (undo edits to a file) |
VS Code Source Control: A Visual Way to Use Git
VS Code includes Git tools in its Source Control view. You are still using Git: VS Code turns the same commands into buttons, change lists, branch controls, and side-by-side differences. Open this view with Ctrl+Shift+G.
Your First Commit in VS Code
VS Code Buttons and Their Git Meaning
| VS Code Action | Git Equivalent | Purpose |
|---|---|---|
| Initialize Repository | git init | Begin tracking this folder. |
| + beside a changed file | git add filename | Select that change for the next checkpoint. |
| Commit | git commit -m "message" | Save staged changes locally. |
| Publish Branch / Push | git push | Upload local commits to the remote repository. |
| Pull / Sync Changes | git pull and git push | Bring in remote work and share yours. |
| Branch indicator | git branch / git switch | See or change your current line of work. |
Publish a New Folder to GitHub
- Make one local commit first so the repository has something meaningful to publish.
- Select Publish Branch or Publish to GitHub in VS Code and sign in when asked.
- Choose visibility deliberately: keep private work private unless you intend to share it publicly.
- Open the new repository on GitHub and check that your files and commit history are present.
Real-World Workflow
Knowing individual commands is one thing. Understanding how they fit into a coherent workflow is what separates someone who "knows Git" from someone who can actually use it productively on a team.
Your Personal Project Workflow
For an assignment, portfolio project, experiment, or learning exercise, this sequence covers the daily essentials:
git clone https://github.com/you/repo.git — this downloads the repo and automatically sets up the remote connection ("origin").git push origin main after each commit session. This is your backup. If your laptop dies, your work is still on GitHub.When Other People Contribute
For team projects, work in a branch, push that branch, and use a GitHub pull request to discuss and review the change before it joins main. Pull current changes before beginning new work or before pushing an updated branch.
Writing Good Commit Messages
Your commit message is a note to your future self (and your teammates). Here's how to write ones that actually help:
✅ Good commit messages — tells a story git commit -m "Add input validation for user age field" git commit -m "Fix index out of bounds in search function" git commit -m "Refactor printReceipt to reduce code duplication"
Branching & Merging
Branches are one of Git's most powerful features. A branch is an independent line of development — a parallel copy of your code where you can experiment, fix bugs, or build features without touching the working version of your project.
Every repository starts with a default branch called main (older projects may call it master). As a beginner, think of main as your "official, working" version. You create new branches to work on something, then merge that branch back into main when it's ready.
Branch Commands
# Create and immediately switch to a new branch git switch -c feature/add-login Switched to a new branch 'feature/add-login'
# Make commits on this branch... git add login.py git commit -m "Implement basic login function"
# Switch back to main git switch main
# Merge the feature branch into main git merge feature/add-login Merge made by the 'recursive' strategy.
# Clean up — delete the branch after merging git branch -d feature/add-login
HEAD is a pointer that tells Git "this is where you are right now." When you switch branches, HEAD moves with you. When you make a commit, HEAD advances to point at the new commit. You'll see it in git log output — it shows your current position in history.
When a Merge Conflict Happens
If two branches change the same lines differently, Git pauses instead of guessing which work to keep. VS Code marks the conflicting file and offers actions to accept either side or combine both. Read the intended result, remove all conflict markers, then commit the resolved version.
# After editing the file to the correct final text: git add index.html git commit -m "Resolve homepage heading conflict"
Protect Your Project with .gitignore
A .gitignore file lists files and folders that Git should leave out of ordinary staging. Create it near the beginning of a project and commit the .gitignore file itself so everyone working on the repository follows the same safety rules.
.env file. A public repository can be copied quickly, and deleting a secret later does not make an exposed credential safe again.
What .gitignore Does and Does Not Do
| It Helps With | It Does Not Do |
|---|---|
| Preventing new matching files from being staged accidentally. | Removing a file already committed or pushed to GitHub. |
| Keeping dependencies, generated builds, and local settings out of history. | Encrypting files or making the folder private on your computer. |
Sharing a repository rule with teammates through a committed .gitignore. |
Guaranteeing that editors, extensions, or AI tools cannot read ignored files. |
A Beginner-Friendly Starter File
Use patterns appropriate to your project. Keep a safe example configuration file, such as .env.example, with placeholder values so other people know what settings they need.
# Dependencies, virtual environments, and generated output node_modules/ .venv/ __pycache__/ dist/ build/
# Local operating system clutter .DS_Store Thumbs.db *.ini
Check Before Every First Push
.gitignore alone is not a fix.
For the official procedures, read GitHub's Ignoring files guide and Removing sensitive data from a repository guide.
Safe AI-Assisted Coding Workflow
AI tools can explain code, suggest tests, and help debug, but they also process the files or text you allow them to see. Use AI as a coding partner only after you have decided which information is safe to share.
.gitignore tells Git what not to commit. It is not a universal privacy wall for AI tools. Some assistants use ignored files as an exclusion signal, while others can read them when asked or when broader workspace access is enabled. Check the settings and documentation for the AI tool you use.
Make AI Honor Your Safety Rules
- Create
.gitignorebefore asking an assistant to build or publish a project. - Keep real keys in ignored local files or a secret manager; give the assistant a placeholder-only
.env.example. - Use your AI tool's exclude, ignore, or privacy controls to block secrets and private data from context or indexing.
- State the rule directly in your request: do not open, quote, edit, stage, or commit secret-bearing files.
- Before committing AI-generated changes, review the diff yourself and run the Git privacy checks from the previous section.
When You Intentionally Need an Ignored File
An ignored file is not automatically unsafe. Generated logs, test output, or large local data may be ignored simply because they do not belong in Git history. If an AI tool needs information from one of these files, provide a small sanitized excerpt or explicitly allow only the non-sensitive path. Do not tell an assistant to ignore every .gitignore rule across the workspace, and never override ignore rules for a secret just to make an AI workflow easier.
Fix Common Beginner Problems
When Git reports a problem, do not delete the repository and start over. Read git status first: it usually names the state you need to fix.
| What You See | What It Means | First Safe Step |
|---|---|---|
fatal: not a git repository |
The terminal is in the wrong folder, or Git was never initialized there. | Open the correct project folder; use git init only for a new repository. |
nothing to commit |
No saved changes are staged for a new commit. | Save the file, run git status, then stage the intended file. |
| Push is rejected | The remote repository contains commits your branch does not yet have. | Run git pull, resolve any conflict, then push again. |
| Wrong file is staged | The file is selected for the next commit, but no work is lost. | Run git restore --staged filename or unstage it in VS Code. |
| Secret or generated file appears in Changes | The file should probably not be recorded in history. | Add its pattern to .gitignore before committing it. |
.gitignore file prevents untracked files such as .env and build output from being added accidentally; it cannot erase a secret already committed and shared.
# Review what Git will include before committing git status git diff --staged
Practice Lab: Publish Your First Repository
Build a small repository with four meaningful commits, starting with an ignore rule that protects local secrets. Complete it with the terminal, with VS Code Source Control, or by switching between both views so you see that they describe the same Git history.
git-practice-lab, initialize Git, and add a .gitignore before making project files.README.md, add learning notes, then update the README with what you practiced.echo "Things I learned about Git" > notes.txt git add notes.txt git commit -m "Add learning notes" echo "## What I Practiced" >> README.md git add README.md git commit -m "Document practice steps" git log --oneline
Knowledge Check
Answer these 14 questions to test your understanding. Click any option to see whether you got it right and why.
Official Resources
This tutorial covers the essentials, but mastery takes practice and deeper reading. Continue with the extended ebook below, then use the official resources for reference and further practice.
Keep This Guide Handy
Save or Install the Tutorial
Keep this one-page guide easy to reopen while you practice. Installation opens it like an app on supported devices; a bookmark works in every browser. After one connected visit, supported browsers can reopen the installed guide offline.
Select the button for the installation steps supported by your browser.
Save it on your device:
- Windows / Linux: press
Ctrl+Dto bookmark it. - Mac: press
Command+Dto bookmark it. - iPhone / iPad Safari: select Share, then Add to Home Screen.
- Android or desktop browsers: use Install or Add to Home screen from the browser menu when available.