Git Bash & GitHub for Beginners.

When I first started using Git, it felt like dealing with that one friend who texts only in short, confusing replies, and then gets annoyed when you don’t immediately understand them. Every command felt like a guessing game, and Git was always ready to hit me with a “that’s not what I meant.”

But after a while, I realized Git isn’t actually complicated, it’s just picky. Kind of like a receptionist who won’t let you in until every form is filled out exactly right.

So let’s talk more about it …

Git Bash — Your Friendly Text-Based Sidekick

Before we go any further, let’s clear up something that confuses almost everyone at first.

Git vs Git Bash — What’s the actual difference?

A lot of beginners mix these two up, so here’s the simplest way to understand it:

• Git is the tool: It’s the actual version control system doing the real work - tracking changes, creating commits, managing branches, all that good stuff.

• Git Bash is just the place where you talk to Git: It’s the terminal (command line) that lets you type commands so Git can do its thing.

Think of it like this:

• Git = the chef

• Git Bash = the waiter taking your order

The chef does the cooking; the waiter just takes your order. Same idea here — Git does the work, Git Bash is how you tell it what work to do.

Git Bash is basically:

• the terminal people on Linux and macOS already have

• given to Windows users so we don’t feel left out

• and so we can type commands like hackers in movies

You’ll use it to navigate files and talk to Git. Think of it like the remote control for Git: you push the buttons, and Git does all the behind-the-scenes magic. Or, if you prefer, the ATM for Git: you punch in a few commands, and it gives you exactly what you asked for (as long as you typed it right).

When to Use git init (and when to back slowly away from it)

Many beginners think:

“New project? I’ll just git init everything!”

Not so fast, Chief Trigger-Finger.

Run git init ONLY if:

• you're starting a project locally first

• and the repo does not already exist anywhere else

Example:

git init

What this actually means:

Dear computer: I want this folder to be a git project. Please start tracking my files.

When NOT to use it

• when you cloned a repo (it’s already initialized)

• when GitHub CLI already set things up for you

• when you’re inside a random folder for no reason

I’ve had mentees accidentally run git init inside:

• Downloads

• Desktop

• C: drive
  … resulting in pure chaos.

Don’t be that person. 😅

If things go bad, don’t panic, we can always fix it.

Creating GitHub Repositories (3 Ways)

Way #1 — Using GitHub CLI (The Cool Kid Approach)

Once you’ve logged in (Download and install the GitHub CLI tool if not yet installed):

gh auth login

Then make a repo like a boss:

gh repo create my-project --public --source=. --remote=origin

Benefits:

• no clicking around on GitHub

• no manual remote setup

• feels extremely professional

Your coworkers/mates will assume you know things 😎.

Way #2 — Create on GitHub, then clone

This is the “traditional web dev ritual”:

1. Go to GitHub

2. Click New repository

3. Type a name

4. Optionally add README

5. Click Create

Then clone:

git clone https://github.com/username/my-project.git
cd my-project

Notice:
No git init
No drama
No stress

Way #3 — Start locally → then push to GitHub

This is what I personally do when tinkering: create my project folder, move into it, and create whatever files I need, initialise Git to start tracking changes, then stage (git add .) and commit them.

mkdir my-project
cd my-project
touch index.js
git init
git add .
git commit -m "initial commit"

Then create an EMPTY repo on GitHub
(no README, no license, no gitignore) and copy the repo url.

Then:
I update the local repo (the project directory I created earlier) with a remote url.

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

If you mess up the remote URL — happens all the time:
Don’t panic, just set the url again.

git remote set-url origin <new-url>

Think of this as:

“Hey git, I gave you the wrong address. Use this one instead.”

Common Beginner Errors (and how to stay sane)

❗ remote origin already exists

Someone already set a remote.

Fix:
Remove already existing origin and add a new one

git remote remove origin
git remote add origin <url>

❗ non-fast-forward error

Translation:

“Buddy, someone pushed code before you. Pull first.”

git pull --rebase origin main
git push

❗ repository not found

Probably not authenticated:

gh auth login

Don’t worry — we've all screamed at Git at least once.

Navigating Files Like a Terminal Ninja

Here’s what you’ll use daily:
mkdir - creates a new folder (make directory )
cd - move in and out of folders (change directory)
touch - create files (don’t forget the file extension)
ls - list everything in your current folder
pwd - show the full path of where you currently are

mkdir my-folder
cd my-folder
touch index.html
ls
pwd
cd ..

You will feel like a hacker.
You won’t be one.
But it feels nice (just the feeling is enough for now).

The Holy Trinity: add → commit → push

Stage your files:

git add .

This is like telling Git:

"Track these changes, please."

Commit your changes

git commit -m "Added authentication logic"

This is you journaling for future-you:

“I did this thing. Here’s why.”

Push to GitHub

git push -u origin main

This is you uploading your work so GitHub sees it.

Branching (a.k.a. Parallel Universes for Your Code)

Imagine:

• main is your clean, stable code.

• branches are chaotic experiments.

Create a branch:

git checkout -b feature/login

Push the branch:

git push -u origin feature/login

Then merge when ready.

Avoiding Conflicts Like a Mature Adult

Tips from experience (and tears):

✔ ALWAYS pull first when starting work

git pull

✔ Commit in small chunks
✔ Don’t work long on giant branches
✔ Communicate with teammates
✔ Don’t edit the same file as someone else at the same time
✔ Seriously — pull first

If a conflict happens, don’t panic — it’s normal.

Even senior devs get conflicts.
We just don’t scream anymore — we sigh deeply (sometimes it’s my reminder for a brief walk around break 😃).

And once you get the hang of the basics, everything else gets way less scary.

Parting Advice from Someone Who Learned the Hard Way

• Git is not scary — just formal.

• Don’t memorize commands — understand intention.

• Your future self will thank you for good commit messages.

• You WILL make mistakes — and that’s okay.

• Git was made so mistakes don’t destroy projects.