Before we start Most people meet Git the hard way. Someone tells you to “just push it to GitHub,” you paste some commands you do not understand, something breaks, and you quietly decide Git is scary. It is not scary. It is one of the most useful tools you will ever learn, and the whole core of it fits in one sitting. This guide takes you from nothing to your first commit pushed to GitHub, with the reasoning behind each step so the commands stop feeling like magic spells. Follow along on a real folder as you read. By the end you will have done the thing, not just read about it. 1. What is Git? What is GitHub? Git is a version control system. That is a tool living on your own computer that keeps a complete history of every change you make to your files. Think of it as a time machine for your project. Made a mess? Roll back to a working version. Want to try something risky? Branch off safely and throw it away if it fails. GitHub is a website that stores your Git projects online. It backs up your work, lets you collaborate with other people, and lets you share projects with the world. The simplest way to hold the difference: Git is the engine that runs on your machine. GitHub is the garage where you park your work and show it off. You can use Git with no GitHub at all. Most people use both together. A bit of history. Git was created by Linus Torvalds in 2005, the same person who built the Linux kernel, because he needed to manage a project thousands of people were editing at once. GitHub came along in 2008 and was bought by Microsoft in 2018. 2. Installing Git and setting it up once Download Git from git-scm.com for Windows or macOS, or install it through your package manager on Linux. Once it is installed, open your terminal and tell Git who you are. This identity gets stamped on every commit you make, so do it once now. One thing that saves headaches later: use the same email address you sign up to GitHub with. That is what links your commits to your GitHub profile, so your work actually shows up as yours. 3. Your first repository A repository, or “repo,” is nothing more exotic than a folder that Git is watching. You either turn a folder you already have into a repo, or you copy an existing one down from GitHub. Running git init quietly creates a hidden .git folder inside your project. That folder is where Git keeps the entire history. You never need to open it or touch it by hand. Leave it alone and it does its job. 4. The three-stage workflow (this is the part that matters) If you understand one thing about Git, make it this. Every change you make travels through three places before it becomes a permanent part of your history. Almost every beginner who finds Git confusing is confused right here, usually about the middle stage. Here is the honest analogy that makes it click. Imagine packing a box to put in storage. The staging step is the one people skip past, but it is the useful one. It lets you make ten changes and save them as two clean, separate commits, instead of one messy lump. Here is the workflow in commands: Write commit messages as instructions, not diary entries. “Fix login bug,” not “Fixed login bug.” It reads oddly at first, but it is the convention, and future-you skimming the history will find it clearer. 5. Putting your work on GitHub Your commits so far live only on your computer. To back them up and share them, you push them to GitHub. First create a new, empty repository on github.com (the “+” icon, top right), then connect your local project to it. The confusion that catches everyone once: committing and pushing are two different things. A commit saves to your local history. A push sends those commits up to GitHub. You can commit ten times offline on a train, then push all ten at once when you get wifi. If your work is not showing up on GitHub, you almost certainly committed but forgot to push. The -u flag on that first push sets origin main as your default, so from then on a plain git push is enough. 6. Branches: how you work without fear A branch is a separate line of work. You make one whenever you want to build a feature or fix a bug without risking the version that currently works. When the work is good, you merge it back into the main line. Once a branch is on GitHub, you can open a pull request, usually called a PR. A pull request is a tidy way to say “here are my changes, please review them before they go into main.” Your teammates can comment, suggest fixes, and approve. This is the everyday workflow in basically every real project, open-source or professional. A rule worth adopting early: on a team project, never commit straight to main. Always branch, then open a PR for review. And if a command ever behaves strangely, run git status and git branch first. Nine times out of ten you are simply on a different branch than you thought. 7. The commands you will actually use You do not need all of Git to be productive. This small set covers almost everything day to day. The cheat sheet below is built to be saved and pinned somewhere you can see it while you find your feet. Command What it does git init Start tracking a project in this folder git clone <url> Copy a remote repo to your machine git status Show what has changed and what is staged git add . Stage all your changed files git commit -m “msg” Save a snapshot, with a message git push Upload your commits to GitHub git pull Download and merge changes from GitHub git log –oneline View a compact history git

The tool nobody teaches you, that everybody uses If you have ever written code, or watched someone who does, you have probably seen the word Git. It is on GitHub, it is in tutorials, it is the thing senior developers tell you to “just learn.” And yet almost nobody explains what it actually is or why it matters before throwing commands at you. So here is the plain version. Git is a tool that takes snapshots of your work over time, so you can always go back, try things safely, and work with other people without chaos. That is the whole idea. Everything else is detail. It was built in 2005 by Linus Torvalds, the same person who created Linux, because he needed a better way to manage a project that thousands of people were editing at once. Today it sits quietly underneath almost all modern software. Once you understand what it does for you, you stop seeing it as a chore to memorise and start seeing it as a safety net you would never want to work without. Let us walk through the moments where Git earns its keep. 1. It is a perfect undo button for your whole project Normal undo (Ctrl+Z) is fragile. Close the file, and it is gone. Make fifty changes, realise change number three was the mistake, and good luck. Git fixes this by letting you save named snapshots, called commits, whenever you reach a point worth keeping. “Working login page.” Snapshot. “Added search.” Snapshot. Each one is a save point you can return to at any time, even weeks later. Break something badly? Roll back to the last good snapshot and carry on. It is the undo button you always wished you had, for the entire project, forever. 2. It lets you experiment without fear This is the one that changes how you work. In Git you can create a branch, which is a parallel copy of your project where you can try anything, a risky new feature, a wild idea, a big rewrite, without touching the version that currently works. If the experiment works, you merge it back in. If it fails, you throw the branch away and your working version never knew it happened. That safety completely removes the fear of trying things. You are never one bad idea away from breaking everything, so you experiment more, and experimenting more is how you get better. 3. It lets people work together without overwriting each other Picture two people editing the same document by emailing it back and forth. Someone always overwrites someone else’s work. Now picture thirty people on one project. Without a system, it is pure chaos. Git is that system. Each person works on their own branch, and Git intelligently combines everyone’s changes, line by line, flagging the rare spot where two people edited the exact same thing so a human can decide. This is the single reason large software teams can function at all. It is also why open-source projects with thousands of contributors do not collapse into a mess. 4. It remembers who changed what, and why Every commit records who made the change, when, and a note explaining why. Months later, when you find a strange line of code and think “why on earth is this here,” Git can tell you: who wrote it, on what date, and what they said they were doing. That turns a project into something with a memory. Nobody has to remember the reasoning in their head. The history is the record. For a team, it is accountability. For a solo learner, it is a diary of your own thinking that you can read back. 5. It is a backup that lives off your machine When you push your project to a remote service like GitHub, GitLab, or Bitbucket, a full copy lives safely on a server. Your laptop is stolen, your hard drive dies, your phone falls in a river: your work is untouched, sitting in the cloud, complete with its entire history. For a student who has lost an assignment the night before it was due, this alone is reason enough. Push your work, and “the dog ate my project” stops being possible. 6. It lets you juggle several things at once Real work is rarely one task at a time. You are halfway through a feature when an urgent bug appears. Without Git, you are stuck, your half-finished work is in the way. With branches, you simply set the half-done feature aside on its own branch, switch to a clean branch to fix the bug, then switch back exactly where you left off. Nothing is lost, nothing collides. Git lets you hold several unfinished things in motion at once, which is what actual work looks like. 7. It becomes proof of what you can do There is a bonus that students often miss. A public GitHub profile, built up over time, is a visible record of your work, your commits, your projects, your progress. Employers look at it. It shows not just that you can code, but that you work consistently and finish things. This connects to something we have written before, that a portfolio beats a certificate. Your Git history is a portfolio you build automatically, just by working the way professionals work. The habit that protects your project today quietly becomes the evidence that gets you hired tomorrow. Where to actually start You do not need to learn all of Git to get most of its value. A surprisingly small set of commands covers almost everything you will do day to day. Save the cheat sheet below, run through the commands once on a throwaay project, and you will have crossed the line from “Git intimidates me” to “Git has my back.” The one thing to remember Git is not really about commands. It is about working without fear. Fear of losing your work, fear of breaking what works, fear of trying something bold, fear of