Ever heard someone say, “Just push it to GitHub” and nodded like you understood, then Googled it in a panic? Yeah, been there, Rookie, I got you today!

First, you gotta know what a version control system is.

It’s a system that records every change to your files over time, so you can recall and restore any version later. Imagine you and your teammate are building a website together. You both edit the same files, sometimes at the same time. Without version control, you’d overwrite each other’s work or lose important changes. Git tracks who changed what, when, and lets you merge your work smoothly, so no more accidental “Wait, where did my code go?!” moments. In short, it’s like a save button for your code: if you accidentally delete an entire feature or break everything, you can just roll back to a working snapshot (instead of throwing your computer out the window).

Why it matters: You get full history (who changed which line and why), easy “time travel” to previous states, collaboration without overwriting each other’s work, and a safety net when things go wrong. Even graphic or web designers use it to keep every version of their images or layouts.

Basic git branching workflow (GitLab).png - Wikimedia Commons

File: Basic git branching workflow (GitLab).png - Wikimedia Commons

Enter Git, the superstar of version control.

Git is a distributed version control system (DVCS) – meaning every developer gets a full copy of the entire project history on their own computer. Unlike older systems that depend on a central server, Git lets you work offline because your local copy is a full backup. Branches in Git are lightweight pointers to commits, and it includes a staging area to help manage changes efficiently.

Git is especially useful when multiple people are working on the same project. You can create branches to try new ideas, temporarily save unfinished work with stash, and merge changes smoothly. Every git clone is a backup, and no central outage can stop your workflow.

Getting Started: Your First Git Repo

Before you can time-travel with Git, you need a repository – the container for your project’s files and history. To make one locally, run:

$ git init my-cool-project
$ cd my-cool-project

This git init command creates a hidden .git/ folder where Git will track changes. Now, any files you add under my-cool-project/ can be versioned. Git won’t track them automatically, but you can stage changes with git add and then commit them with git commit. For example:

$ echo "# My Cool Project" > README.md
$ git add README.md
$ git commit -m "Initial commit: Add README"

Each commit is like a snapshot of your files. The commit message (here, Initial commit) should explain why you made the change. Treat it as if future-you will laugh at you if it says “stuff” or “updates” – clarity saves headaches later!

Clone, Fetch, Pull, Push, Oh My!

In Git lingo, a remote repository is typically on a server (like GitHub). To start collaborating, you often clone an existing repo:

$ git clone https://github.com/username/repo.git

This command makes a copy of the remote repo on your computer. After cloning, you can run git fetch to update all remote branches, or git pull to fetch and merge them into your current branch. In practice, git pull is just a shortcut for git fetch + git merge.

To send your own commits up to GitHub, use git push. Push uploads local commits to the remote repo basically the opposite of fetch/pull.

$ git remote add origin git@github.com:username/my-cool-project.git
$ git push -u origin main

This sets origin as the GitHub address and pushes your main branch there. Warning: Push can overwrite remote history if you force it, so use git push --force only if you know what you’re doing.

Tip: Run git status often to see what’s going on. It tells you which branch you’re on, what’s staged, and if you’re ahead/behind the remote.

Stashing: Your Work-In-Progress Hideaway

Ever been in the middle of a change and suddenly need to switch gears? Git has you covered with git stash. This nifty command saves your changes and resets your working directory to clean. In practice:

$ git status
On branch main
Changes to be committed:
    (new file: feature.js)
Changes not staged for commit:
    (modified: index.html)
$ git stash save "WIP: adding feature"
Saved working directory and index state WIP on main: 0123abc adding feature
$ git status
On branch main
nothing to commit, working tree clean

Now your working directory is clean, and you can pull, switch branches, or do anything. Later, git stash pop will reapply those hidden changes so you can resume.

🧯 In case of fire: 1. git commit 2. git push 3. Leave the building.
Seriously – don’t lose work. Commit early, commit often.

Branching and Merging in Git

A branch is a movable pointer to a sequence of commits. When you spawn a new branch, it starts as a copy of the main branch, but then each line of development moves on its own track. This keeps experimental code off the main branch until it's ready to merge.

Here’s how it usually goes:

$ git branch new-feature         # Create a branch
$ git checkout new-feature       # Switch to it
# OR shortcut: git checkout -b new-feature

You make commits on new-feature, and then later:

$ git checkout main
$ git merge new-feature

This merges changes into main. If two branches modified the same lines, Git will prompt you to resolve the conflict.

To delete the merged branch:

$ git branch -d new-feature

Diving into GitHub

GitHub is a code hosting platform that makes Git visual and collaborative. It adds features like issues, pull requests, wikis, stars, and actions.

Code: Main repo view. Lists files and lets you copy the clone URL.
README: Write instructions or descriptions here. Appears on the home tab.
Pull Requests (PRs): Open one when merging changes from one branch to another. You get discussion threads, code reviews, and merge buttons.
Issues: Used to track bugs, features, or general todos. Tag people, add labels, and track progress.
Forks: Clone someone else’s repo under your GitHub account. Ideal for open source contributions.
Stars: Bookmark projects you like. Also works like an upvote.
Actions: Automate your workflow. Run tests, deploy on push, etc.

The Workflow:

Here’s how most real-world projects flow:

Create a GitHub repo.

Clone it locally:

 git clone https://github.com/yourname/project.git

Create a branch:
```
 git checkout -b feature-login
```

Work, commit, and push:

 git add .
 git commit -m "Add login form"
 git push -u origin feature-login

Open a PR on GitHub.
Get reviewed & merged.
Pull the latest main:
```
 git checkout main
 git pull
```
Rinse and repeat.

Git Started: The Only GitHub Guide You’ll Actually Need