The complete guide for college students — from zero to professional developer workflow.
Imagine you and three college friends are building a final-year project together:
Rahul finishes the login page on Day 1. On Day 2 he adds changes with a bug. The original working version is gone forever.
To avoid losing work, the team starts creating files like:
project.zip → project_v2.zip → project_FINAL.zip → project_FINAL_use_THIS_one.zip
All four email their app.py. Anaya now has four files with the same name. Who has what? Who overwrote whose work?
A feature breaks two weeks later. Who broke it? When? Why? No way to find out.
Arjun's laptop crashes. All his database code is gone. The project is stuck for days.
A VCS automatically tracks every change made to every file — who changed it, when, why — and lets you go back to any earlier version without ever renaming a file. It also enables seamless team collaboration.
A VCS is software that records every change made to a set of files over time so you can recall specific versions later. Think of it as a time machine for your code.
See every change, who made it, and why.
Try new ideas without breaking working code.
Multiple people work simultaneously without conflicts.
Roll back any change in seconds.
Code is safe even if your laptop crashes.
Every tech company expects you to know VCS.
Tracks changes on your computer only. Example: RCS (1980s).
📖 Like a personal diary that only you can read — and only if your house doesn't burn down.
Problem: If your hard drive fails, everything is lost.
One server holds all versions. Teams check out files from it. Examples: CVS, SVN.
📖 Like one library book the whole class shares — if the library closes, nobody can work.
Problem: Single point of failure. Server down = everyone stuck.
Every developer has a complete copy of the entire project history on their own machine. Examples: Git, Mercurial.
📖 Like everyone having their own full photocopy of the entire book — if one person loses theirs, 9 others still have it.
Benefit: Works offline, no single point of failure, fast, collaborative.
| Tool | Creator | Best Known For | Still Used? |
|---|---|---|---|
| Git | Linus Torvalds (2005) | Linux kernel; now universal | ✓ Dominant |
| Mercurial (Hg) | Matt Mackall | Simpler syntax than Git | Rare |
| Fossil | D. Richard Hipp | Built-in bug tracker + wiki | Niche |
| Bazaar | Canonical (Ubuntu) | Beginner-friendly design | Mostly gone |
| Perforce | Perforce Software | Large binaries, game dev | Enterprise |
| BitKeeper | BitMover Inc. | Used for Linux before Git | Replaced |
| Darcs | David Roundy | Unique patch-based model | Very rare |
| Azure Git | Microsoft | Git + Azure DevOps pipelines | Enterprise |
Git is a version control software that lives on your laptop. It tracks every change to your files locally — completely offline.
📖 Like your personal notebook: you write drafts, keep every version, and can flip back to any page.
GitHub (github.com) is an online platform where you store your Git projects. It's like Google Drive, but built specifically for code and team collaboration.
📖 Like a cloud locker where your team can all read, comment on, and contribute to the same notebook.
You can use Git without GitHub (just tracking files locally). But you cannot use GitHub without Git — GitHub runs on top of Git. They are complementary tools.
A local repository (local repo) is the .git folder Git creates inside your project on your own laptop. It stores your entire commit history, branches, and snapshots — all on your machine.
Your local repo is like your personal diary with every draft you ever wrote — stored in your room, accessible anytime even without internet.
A remote repository (remote repo) is a copy of your project stored on a server — like GitHub, GitLab, or Bitbucket. It's the shared "source of truth" your team all syncs with.
The remote repo is like a shared Google Doc that everyone on the team can view, contribute to, and sync from — but it only shows what you've explicitly uploaded (git push).
| Feature | Local Repository | Remote Repository (GitHub) |
|---|---|---|
| Where it lives | Your laptop (.git folder) | GitHub's servers (cloud) |
| Internet needed? | No — works offline | Yes |
| Who can see it? | Only you | Public or private (you choose) |
| If laptop crashes… | Code is gone | Safe in the cloud |
| Team collaboration? | No | Yes — everyone syncs here |
| How to sync | git push to send up | git pull / clone to get |
Rahul's Laptop GitHub.com (Remote) Priya's Laptop
(Local Git Repo) (Shared Cloud Repo) (Local Git Repo)
| | |
|──── git push ───────────►| |
| |◄──── git push ────────────|
|◄─── git pull ────────────| |
| |────── git clone ─────────►|
| | |
[Commits on your [Everyone's commits [Full copy of
machine only] sync here] project here]
When you run git init, Git creates a hidden .git folder. Never edit this manually — Git manages it automatically.
your-project/
├── src/
│ └── main.py ← Your actual code
├── README.md
└── .git/ ← Git's database (hands off! 🚫)
├── objects/ ← Every version of every file (as snapshots)
├── refs/ ← Pointers to branches and tags
├── HEAD ← Which branch you're on right now
├── config ← Local repository settings
├── COMMIT_EDITMSG ← Your last commit message
└── hooks/ ← Optional scripts that run on Git events
| ✅ Include in Git | ❌ Never Include |
|---|---|
| Source code (.py, .js, .java, .html) | Passwords, API keys, .env files |
| README.md and documentation | node_modules/, venv/, .vscode/ |
| Configuration files (non-secret) | Compiled/built files (__pycache__, .o, dist/) |
| Database schemas (structure, not data) | Large binary files (videos, raw datasets) |
| Tests and test data | IDE-specific settings (.idea/) |
git --versionbrew install gitsudo apt install gitsudo dnf install gitsudo pacman -S gitWhen you create a GitHub account, use the exact same email you set here. This is how GitHub links your commits to your profile and shows green contribution dots on your profile page.
Click "Sign up" — it's free.
Use your real name if possible: rahul-kumar or rahulkumar. Recruiters will see this in your portfolio URL: github.com/rahul-kumar
GitHub sends a confirmation email — click the link inside it.
Add a photo, bio, and your college. A complete profile looks professional to recruiters.
GitHub has a special secret repo: create a repo with your exact username as the repo name. The README.md inside it shows up on your GitHub profile page for everyone to see!
Go to GitHub → New Repository → Name it rahul-kumar (your username) → Check ✅ "Add a README file" → Create.
Write about yourself: your skills, projects, college, and contact. This is shown on your public profile!
Click "Commit changes" on GitHub. Visit your profile — your README is live! 🎉
There are two main approaches to get your code onto GitHub — choose based on whether you start on GitHub or on your local machine.
When to use: You're starting a brand-new project. Most beginner-friendly.
Flow: Create repo on GitHub → Copy the URL → Clone it to your laptop → Start coding.
When to use: You already have a folder with code on your laptop and want to put it on GitHub.
Flow: git init locally → Create empty repo on GitHub → Connect them → Push.
Go to GitHub → click + → New Repository → give it a name → check ✅ "Add a README file" → click Create Repository.
Click the green Code button → Copy the HTTPS or SSH URL.
This downloads the entire repo to your machine, already connected to GitHub.
The repo is automatically connected to GitHub — no need to run git remote add origin. Just clone and start coding!
mkdir my-project then cd my-project
git init — Git now tracks this folder.
Add a file, stage it, commit it.
Go to GitHub → New Repository → do NOT check README → Create.
Run the commands GitHub shows you on screen.
You type Git commands in a terminal (Git Bash on Windows, Terminal on Mac/Linux). Full control, works anywhere, essential skill for all developers.
Best for: All developers — must learn this.
VS Code has a built-in Source Control panel (the branch icon on the left sidebar). You can stage, commit, and push with mouse clicks — no terminal needed.
Best for: Beginners who want a visual approach alongside learning CLI.
1. Open your project folder in VS Code.
2. Click the Source Control icon (branch icon) in the left sidebar.
3. Make changes to files — they appear in the "Changes" list automatically.
4. Click + next to a file to stage it (same as git add).
5. Type a message in the box at the top and click ✓ Commit.
6. Click the ⋯ menu → Push (same as git push).
| Command | What it Does | Example |
|---|---|---|
pwd | Print Working Directory — shows your current location | pwd → /home/rahul/Desktop |
ls | List files and folders in current directory | ls |
ls -la | List all files including hidden ones (like .git) | ls -la |
cd | Change Directory — navigate into a folder | cd Desktop |
cd .. | Go up one level (parent folder) | cd .. |
mkdir | Make a new directory/folder | mkdir my-project |
echo | Print text or write text to a file | echo "Hello" > hello.txt |
sudo | Run a command with admin/superuser privileges | sudo apt install git |
touch | Create an empty file | touch .gitkeep |
cat | Show contents of a file in the terminal | cat README.md |
┌──────────────────┐ git add ┌──────────────────┐ git commit ┌──────────────────┐
│ Working Directory│ ─────────────► │ Staging Area │ ──────────────►│ Repository (.git)│
│ (Your files) │ │ (Prepared zone) │ │ (Permanent save) │
│ │ │ │ │ │
│ You freely edit │ │ You choose which │ │ Git saves snapshot│
│ files here │ │ changes to save │ │ forever here │
└──────────────────┘ └──────────────────┘ └──────────────────┘
↑ │
└──────────────────────── git restore ←────────────────────────────────┘
(undo changes)
Working Directory = Your desk where you write letters.
Staging Area = The envelope — you choose which letters to put inside.
Commit (Repository) = Sealing and posting the envelope — it's sent and saved permanently.
.gitignore — Tell Git What to SkipYou're packing for a trip. You want your clothes — but NOT your household trash or private diary. .gitignore is a checklist you give Git that says: "Do NOT pack these items."
Create a file called .gitignore in your project root:
Go to gitignore.io — type your language/framework (e.g. "Python", "Node", "React") and it generates the perfect .gitignore for you automatically!
.gitattributes — Consistent Formatting Across MachinesImagine two people writing a book together — one uses Windows (which adds a special invisible character at the end of every line) and one uses Mac. The code looks different even when it's the same. .gitattributes is a rule book that forces every computer to format files the same way.
# .gitattributes — Place in your project root # Auto-detect text files and handle line endings * text=auto # Force all code files to use Linux/Mac line endings (LF) *.js text eol=lf *.html text eol=lf *.css text eol=lf *.py text eol=lf *.json text eol=lf # Tell Git these are binary — don't try to merge them as text *.png binary *.jpg binary *.gif binary *.zip binary *.pdf binary
.gitkeep — Keep Empty Folders in GitGit is like a mail carrier that only delivers boxes with something inside. If you give Git an empty folder, it ignores it. .gitkeep is a tiny empty file (a "rock") you put inside an empty folder so Git will track and carry it.
my-project/ ├── public/ │ └── uploads/ │ └── .gitkeep ← This tiny blank file forces Git to track the folder ├── src/ │ └── main.py └── README.md
The main branch should always be working, tested code. Always create a feature branch, work there, and only merge after review.
Run git pull origin main every morning before writing a single line. This prevents conflicts with your teammates' work.
Commit every 30–60 minutes. Don't wait until the end of the day. More commits = finer history = easier debugging.
❌ Bad: "fixed stuff" ✅ Good: "Fix null pointer when login form is submitted with empty password"
Keep each branch focused. Don't mix login changes and dashboard changes in the same branch. Small, focused branches are easier to review and merge.
A branch is a parallel version of your project. Think of it like a parallel universe — you can experiment in your universe without affecting the main one. When your experiment works, you merge it back.
📖 Like a book draft — you write a new chapter on separate paper. If you like it, you paste it in. If you hate it, you throw the paper away — the original book is untouched.
main: A ──── B ──── C ──────────────── G (merge)
\ /
feature-login: D ──── E ──── F
(Rahul works here safely)
| Command | What It Does | When to Use |
|---|---|---|
git checkout branch-name | Switch to an existing branch (old syntax) | Works in all Git versions |
git checkout -b new-branch | Create AND switch to new branch (old syntax) | Very common in tutorials |
git switch branch-name | Switch to existing branch (new, cleaner syntax) | Git 2.23+ preferred |
git switch -c new-branch | Create AND switch to new branch (new syntax) | Modern way — recommended |
Both git checkout and git switch work. Many online tutorials still use checkout — learn both but prefer switch for new projects as it's clearer and less confusing.
git pull does TWO things in one command: (1) fetch — downloads new commits from GitHub, and (2) merge — integrates those commits into your current branch. It's the shortcut you use every morning.
git fetch downloads new commits from GitHub but does NOT merge them into your code. It lets you see what changed before you decide to integrate it. Think of it as "look before you leap".
📖 fetch = downloading a package at your door. pull = opening it and unpacking immediately.
When two people edit the same line, Git shows both versions and asks you to decide:
<<<<<<< HEAD (your version) DATABASE_HOST = "localhost" ======= DATABASE_HOST = "production-server" >>>>>>> feature-api (their version)
Delete the conflict markers (<<<, ===, >>>) and keep the correct line. Then git add and git commit.
You're coding a new feature when your team lead says "critical bug — fix it NOW!" Your code is half-done — not ready to commit. git stash saves your work-in-progress in a temporary drawer so you can switch tasks immediately, then come back and pick up exactly where you left off.
| Command | What It Does | Safe to Use After Pushing? | Use Case |
|---|---|---|---|
git revert <id> |
Creates a new commit that undoes the changes of a previous commit. History stays intact. | ✅ Yes — Safe | Undo something that's already on GitHub/in production |
git reset HEAD~1 |
Moves the branch pointer back, erasing commits from history. | ⚠️ No — Dangerous | Undo commits that are only on your local machine |
git checkout <file> |
Discards unsaved changes in a file, restoring it to the last commit. | ✅ Always safe | Oops — throw away edits you haven't committed yet |
If the commit is only on your laptop (not pushed) → use git reset.
If the commit is already on GitHub → use git revert (it's safe, doesn't break teammates' history).
Like bookmarking a project you find useful. Stars show appreciation to creators and let you find repos later. A repo with many stars = popular & trusted.
How: Open any repo → click the ⭐ Star button in the top right.
Creates your own personal copy of someone else's project. You can freely change your fork without touching the original. Essential for contributing to open source.
How: Open repo → click Fork button → it appears under your account.
Report a bug, suggest a feature, or ask a question about a project. Issues are public discussions tied to the repository.
How: Repo → Issues tab → New Issue → describe the problem clearly.
A request to merge your branch (or fork) into the main codebase. The team reviews your changes, leaves comments, requests edits, and eventually approves + merges.
How: Push your branch → GitHub shows "Compare & pull request" → fill details → submit.
The standard open-source flow: Fork → Clone your fork → Create a branch → Make changes → Push → Open a PR to the original repo.
Most repos have a CONTRIBUTING.md file explaining how to contribute.
As a reviewer: read the code, leave inline comments, request changes, or approve. As the author: respond to comments, push updates, and the PR auto-updates.
Merge options: Merge commit / Squash & merge / Rebase & merge.
Click Fork on GitHub → creates your-username/project as your own copy.
git clone https://github.com/YOUR-USERNAME/project.git
git remote add upstream https://github.com/ORIGINAL-AUTHOR/project.git
This lets you pull future updates from the original.
git checkout -b fix-typo-in-readme
Edit files → git add . → git commit -m "Fix typo in README"
git push origin fix-typo-in-readme
Go to the original repo on GitHub → GitHub detects your push → click "Compare & pull request" → describe your changes → submit!
Pros: Zero setup, works everywhere out of the box.
Cons: GitHub asks for credentials every time (unless you use a credential manager).
Best for: One-time cloning or unfamiliar computers.
Pros: Set up once → never type a password again. Faster and more secure.
Cons: Needs 5-minute setup (generate key, add to GitHub).
Best for: Your own laptop — the professional way.
More features than GitHub, generous free tier, can self-host on your own server. Great for teams wanting full control.
Integrates deeply with Jira and the Atlassian suite. Free for small teams. Used heavily in enterprise software companies.
Ultra-lightweight, self-hosted only. Perfect for companies wanting a private internal Git server with minimal resources.
Every tech company — from startups to Google — uses Git. Most use GitHub. Learning Git and GitHub makes you instantly employable. If a company uses GitLab or Bitbucket instead, you'll transfer your Git knowledge in minutes since the commands are identical. The platform changes, the tool (Git) stays the same.