When I first started learning version control, I kept seeing four things mentioned everywhere: Git, GitHub, Git Bash, and different terminals like Anaconda Prompt or the CMD
And honestly, I was confused.
Not the kind of confusion where you do not understand a command. The kind where you do not even understand where you are supposed to type the command in the first place.
Where the Confusion Started
Let me share what actually happened.
When I first started learning Git, I expected it to be straightforward.
- Install Git.
- Open Git Bash.
- Run the commands.
- Done
Except Git Bash was not working properly on my machine.
I would open it and immediately get a red error message. Something about a child process and DLL rebasing. I had no idea what any of that meant. I tried running it as Administrator. Still broken. I searched online. Got more confused. Closed the terminal. Opened it again. Same error.
I spent more time trying to fix Git Bash than I spent actually learning Git. That felt wrong, but I did not know what else to do.
And here is what made it worse: Every single tutorial I found started with the same two words.
"Open Git Bash."
So in my mind, the entire relationship looked like this: Git - Git Bash - GitHub
Git Bash felt like the place where Git lived. Without it, I assumed I could not use Git at all.
My Workaround — And Why It Was a Problem
Around the same time I was struggling with Git Bash, I had just started learning Python and had installed Anaconda. I was using Anaconda Prompt every day for my Python work, so it was already open on my machine.
Since Git Bash was not cooperating, I took what felt like the easiest path at the time. I started uploading my work directly to GitHub.
No commits. No Git commands. No terminal at all. Just dragging files onto the GitHub website and clicking upload.
At the time, it seemed fine. The code was online, after all. My work was saved. What was the problem?
The problem was that this is not how developers actually work. And the more tutorials I watched, the more obvious that became.
Everyone was using commands like git add, git commit, and git push. They had a history of changes. They could go back to previous versions. They could work in teams without overwriting each other's work.
I was just throwing files at a website and hoping for the best.
Direct uploading skips the entire point of Git. You get no version history, no commit messages, no record of what changed or why.
The Realization That Changed Everything
Since Git Bash was broken, my first question was a practical one: is Git even installed properly on this machine? I needed to check. So, I opened CMD first, the basic Windows terminal that has always been there and typed:
git --version
It worked. Git version 2.52.0. No errors. No red text.
Then I tried the same thing in Anaconda Prompt, which I already had open for my Python work:
git --version
That one moment changed how I understood everything.
Git commands do not belong to Git Bash. They belong to Git itself. Git Bash is just one of many places where those commands can run.
Once Git is installed on your computer, any terminal can use it. Not just Git Bash. CMD works. PowerShell works. Anaconda Prompt works. The terminal inside Visual Studio Code works.
The terminal is just the interface. Git is the actual tool doing the work.
That small realization made everything less intimidating. I stopped worrying about which terminal to use and started focusing on learning Git itself.
Understanding the Terms
1. What is Git?
Git is a version control system. It keeps a record of every change you make to your files so you can go back to any previous version at any time.
For example:
You are working on an assignment, everything is going well. Then you try something new and suddenly everything breaks. You wish you could go back to the version that was working. But you cannot, because you saved over it.
We've all done something like this:
myassignment.py
myassignment_v2.py
myassignment_FINAL.py
myassignment_FINAL_v2.py
myassignment_FINAL_ACTUALLY_FINAL.py
Git solves this problem elegantly.
Key Benefits of Git
| Benefit | What It Means For You |
|---|---|
| Version History | Every change is recorded. Go back anytime. |
| Safety Net | Restore the working version instantly. |
| Teamwork | Multiple people can work on the same project seamlessly. |
| Accountability | See what changed, when, and who did it. |
| Professional Standard | Every tech company in the world uses Git. |
2. What is GitHub?
This was my biggest confusion for the longest time. I kept hearing Git and GitHub used together and assumed they were the same thing.
They are not.
Git tracks changes on your computer. GitHub stores your code online. Git was created in 2005. GitHub was built later in 2008 as a platform for hosting Git repositories.
When I uploaded files directly to GitHub without Git, I had storage without version control—like backing up a Word document without using track changes.
Git vs GitHub
| Feature | Git | GitHub |
|---|---|---|
| What it is | Software on your computer | A website on the internet |
| Where it lives | Your local machine | Online cloud storage |
| Main purpose | Track code changes | Store and share code |
| Needs internet | No | Yes |
| Free to use | Yes | Yes (with limits) |
Why GitHub Matters
Your GitHub profile is your professional portfolio. Employers often look at GitHub before your CV. Every commit tells a story of your progress. Treat it like your digital CV from day one. It shows them real work, real code, and real progress over time.
Every assignment you push is proof of your skills. Every commit tells a story of how you improved. Start treating your GitHub like your digital CV from day one.
3. What is Git Bash?
Git Bash is simply a terminal, a window where you type commands, that comes bundled with Git when you install it on Windows.
Windows already has terminals like CMD and PowerShell. Git Bash exists because Windows doesn’t natively support Linux-style commands, which are standard in most professional environments.
What Makes Git Bash Useful
| Feature | Git Bash | Regular CMD |
|---|---|---|
| Shows current branch name | Yes — in the prompt itself | No |
| Coloured output | Yes — green, red, yellow | Plain white text only |
| Linux commands (ls, rm, touch) | Yes | No — uses dir, del instead |
| Tab auto-complete | Yes | Limited |
| Optimised for Git | Yes | Works but basic |
Getting Git Bash
Git Bash is not a separate download. It comes automatically when you install Git:
- Go to git-scm.com
- Download Git for Windows
- Install using the default settings
- Git Bash appears in your Start Menu automatically
The Part Nobody Told Me: Any Terminal Works!
This is the core insight of this entire article.
Once Git is installed on your computer, you can run Git commands from any terminal. Not just Git Bash.
git init
git add .
git commit -m "first commit"
git push
These commands work in Git Bash. They work in CMD. They work in PowerShell. They work in Anaconda Prompt. They work in the terminal inside Visual Studio Code.
Using Anaconda Prompt for Git
This is the option that saved me when Git Bash was broken, and it is what I genuinely recommend for data science beginners like me.
If you already have Anaconda installed for Python and Jupyter, you already have a terminal that works perfectly for Git. You do not need to install or fix anything extra.
You can manage Python, run Jupyter notebooks, and push to GitHub all from the same Anaconda Prompt window. One tool. Less confusion.
Terminal Comparison
| Terminal | Git Support | Best For | Recommended? |
|---|---|---|---|
| Git Bash | Full + extra features | Git-focused work | Yes, once working correctly |
| Anaconda Prompt | Full support | Data science + Git | Yes — great for beginners |
| CMD | Full support | Basic Git operations | Yes — works fine |
| PowerShell | Full support | Advanced Windows tasks | Yes — works fine |
| VS Code Terminal | Full support | All-in-one development | Yes — very powerful |
The Git Commands You Actually Need
Git has many commands, but you only need around ten for everyday work. Here they are in plain English.
First-Time Setup — Do This Once Per Computer
Before using Git, tell it who you are:
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
git config --list
Press Enter with each command even if you see nothing showing. This means it is working
The last command confirms it worked. You should see your name and email displayed.
The Essential Commands
| Command | What It Does | Real Life Equivalent |
|---|---|---|
| git init | Starts Git tracking in a folder | Hiring a security camera for your folder |
| git status | Shows what changed | Checking your to-do list |
| git add . | Prepares all files for saving | Putting everything in an envelope |
| git commit -m "msg" | Saves a version with a label | Sealing the envelope and labelling it |
| git push | Sends code to GitHub | Handing the envelope to a courier |
| git pull | Gets latest code from GitHub | Receiving a delivery |
| git clone | Downloads a full project | Borrowing a book from a library |
| git log | Shows history of all commits | Reading your diary from the beginning |
The Complete Step-by-Step Workflow: First-Time Push to GitHub
Open your terminal (Git Bash, Anaconda Prompt, VS Code Terminal, etc.) and navigate to your project folder:
**Step 1 — Navigate to your project folder
cd "C:\Users\YourName\Documents\your_project"
The cd command means Change Directory. If your folder name has spaces, wrap the path in quotes.
Step 2 — Start Git tracking
git init
You will see: Initialized empty Git repository.
This creates a local Git repository in your folder, allowing Git to track changes.
Git is now watching/tracking this folder.
Step 3 — Add your files
git add .
The dot means add everything.
To add one specific file, replace the dot with the filename.
Step 4 — Commit your changes
git commit -m "first trial"
This is the actual save. The message in quotes describes what you did. Make it meaningful.
Step 5 — Create a repository on GitHub
Note: Do not initialize it with a README — this avoids merge conflicts.
- Go to github.com and log in
- Click the + button in the top right corner
- Click New Repository
- Give it a name with no spaces — use hyphens instead
- Click Create Repository
Step 6 — Connect your computer to GitHub.
git branch -M main
Click Enter
Many tutorials and GitHub now use main as the default branch name.
git remote add origin https://USERNAME:TOKEN@github.com/USERNAME/reponame.git
Click enter
Replace:
USERNAME → your GitHub username
TOKEN → your personal access token
reponame → your repository name
For example:
git remote add origin https://Isika01:hgwghpskskjAKJYVE31t7Ia@github.com/Isika-01/Revision_Assignment.git
_Note: _GitHub no longer allows passwords for authentication. You must use a personal access token.
Step 7 — Push your code to GitHub
git push -u origin main
If it works, you will see objects being written and a success message.
Then check GitHub — your files will be there.
Every Update After That — Just Three Commands
After the first-time setup, every future update is only three commands. That is all.
git add .
git commit -m "describe what you changed"
git push
GitHub Personal Access Tokens — The Part Nobody Explains Well
I want to be upfront about this one too. When I first tried to push to GitHub and it asked for a password, I typed my regular GitHub password and got an error. Then I spent an hour confused before discovering that GitHub had changed how authentication works.
GitHub no longer accepts your regular account password for Git operations. Instead, you need a Personal Access Token. Think of it as a special password created specifically for Git.
Creating Your Token
- Go to github.com and log in
- Click your profile picture in the top right corner
- Click Settings
- Scroll all the way down and click Developer Settings
- Click Personal Access Tokens then Tokens classic
- Click Generate new token classic
- Set the expiration to No expiration
- Check the repo, workflow and read:org boxes
- Click Generate Token
- COPY IT IMMEDIATELY — GitHub will never show it again
- Save it in a Notepad file somewhere private on your computer
Token Safety Rules
- Save token privately in Notepad. Do not share it with anyone
- It acts as your Git password so do not post it online
- If lost, delete and regenerate it
Common Git Errors and What They Actually Mean
Errors in Git are normal. Even experienced developers get them regularly. Here are the ones you are most likely to see:
| Error | What It Means | How to Fix It |
|---|---|---|
| remote origin already exists | You already connected to GitHub | Run git remote remove origin then add it again |
| fatal: not a git repository | Git is not tracking this folder | Run git init first |
| Authentication failed | Wrong username or token | Check your token is correct |
| Could not read from remote | Using SSH format instead of HTTPS | Use the https:// URL format |
| nothing to commit | No files have been changed | Edit your files first then add and commit |
Best Practices for Professional Git Use
- Write Meaningful Commit Messages
- Your commit messages are a permanent record of your work. Future employers will read them. Make them count.
| Good Messages | Bad Messages |
|---|---|
| Completed SQL assignment with JOIN queries | stuff |
| Fixed error in data cleaning function | changes |
| Added visualisation charts for sales report | update |
| Updated README with setup instructions | aaa |
| Resolved login bug reported in code review | final |
Repository Naming Rules
- Use hyphens or underscores instead of spaces
- Be descriptive so you remember what the project is
- Use lowercase letters for consistency
| Good Repository Names | Bad Repository Names |
|---|---|
| sql-assignment-week1 | Python Data Analysis |
| powerbi-sales-dashboard | (See above: spaces make it bad) |
Keep Your GitHub Active
Your GitHub profile shows your commit activity over time. Even small daily commits build a strong profile. Treat every assignment as an opportunity to add to your portfolio.
Employers look at how consistently you push code.
Sometimes the broken path teaches you more than the smooth one.
Top comments (0)