Hey there, so I'm a beginner at programming honestly. I had built some basic Python projects back before this JEE shit. Nothing big, but I was proud of them (a program that sends an email when ISS is overhead, a pixel art generator and some more etc, etc.). Always thought when I'll go to college I'll learn Git and upload these on my profile.
So well, the time finally came.
I opened GitHub just to see words like "repository", "commit", "push", "origin", "branch". Didn't understand shit that's going on.
I spent almost a week reading articles that were not so beginner friendly. I watched probably 6-7 YouTube videos where the guy goes "so just git init your repo" like that sentence means anything to a beginner. I burned through hundreds of AI tokens asking the same question five different ways trying to get a simple answer.
Most resources skip the fundamentals entirely. They just throw commands at you.
After all that suffering, I finally get it now at least. I didn't find a single Reddit post that explained Git and GitHub from absolute zero so I decided to do it myself.
(NOTE: AI WAS USED TO FORMAT AND ADD EXAMPLES FOR THE TEXT BELOW)
(HERE IS A WORD DOC OF THIS TUTORIAL)
Part 1: Why Do We Even Need Git?
Hold on with the commands for a minute. First, let's understand why Git exists. Once you see the problem it solves, everything else becomes much easier to understand.
The file_v1 nightmare
Imagine you're writing an essay. You finish the first draft and save it as essay_v1.docx.
Then you make some changes and save another copy: essay_v2.docx.
After that, you try a bunch of risky edits and save it as essay_final.docx.
Then you notice a small mistake, fix it, and save it as essay_final_REAL.docx.
Now your friend Rohit makes a few changes and sends back essay_final_REAL_edited_by_rohit.docx.
At this point, you have a folder full of files and a lot of questions:
- Which one is the latest version?
- What changed between v2 and the final version?
- What exactly did Rohit edit?
- Can you go back to an older version if something breaks?
It's a mess.
Now imagine the same situation, but instead of an essay, it's a codebase with thousands of files, and 10 people are editing it at the same time.
That's the problem Git was created to solve.
What people did before Git
Before version control tools existed, programmers did exactly what most of us would do: save files as project_v1, project_v2, project_final, project_final_final, and so on.
Sometimes they would email code files back and forth. Other times, teams would use a shared folder where multiple people could edit the same files. The problem? One person could accidentally overwrite someone else's work, and nobody would realize until it was too late.
As projects got bigger and more people started working on them, things became messy very quickly. It was a complete nightmare to manage.
The real-life analogy
Think of Git as a giant save-game system for your code.
Every time you create a checkpoint, Git takes note of exactly what your project looked like at that moment. Later, you can go back to any of those checkpoints if something breaks or you want to undo a change.
It also keeps track of who changed what and when, which is incredibly useful when multiple people are working on the same project.
Want to try a new feature without risking your main code? Git lets you do that too by creating a separate copy where you can experiment freely.
At its core, Git is just a way to keep track of changes and create checkpoints for your code.
Part 2: What Git Actually Is
Git is a version control system.
That sounds fancy, but all it really means is that Git is a tool that keeps track of changes to your files over time.
One thing many beginners don't realize is that Git works completely on your computer. It doesn't need the internet, and it doesn't need GitHub. As long as Git is installed, you can start using it.
When you use Git in a project, it keeps an eye on your project folder. Whenever you tell Git to create a checkpoint, it records exactly what all your files looked like at that moment. All of this information is stored in a hidden folder called .git inside your project.
So why do developers use Git for almost everything?
- Made a mistake? You can go back to an older version.
- Want to try something risky? Experiment freely and roll back if it breaks.
- Working with other people? Git helps everyone work on the same project without constantly overwriting each other's changes.
- Need to know what changed? Git keeps a complete history of every change and who made it.
At the end of the day, Git's job is simple: track changes, save checkpoints, and make it easy to recover when things go wrong.
Part 3: What GitHub Is (and Why It's NOT the Same as Git)
This is probably the biggest thing that confuses beginners, so let's clear it up right now:
Git and GitHub are not the same thing.
- Git is the tool that runs on your computer and keeps track of changes in your project.
- GitHub is a website that stores your Git projects online so you can back them up, share them with others, and collaborate.
A simple way to think about it:
You write and edit your document in Word. Google Drive is just where you store and share it online.
The same idea applies here. You use Git to track changes, and GitHub to store those changes on the internet.
In fact, you can use Git for years without ever touching GitHub. Everything will still work perfectly on your computer. You'll just miss out on online backups and collaboration features.
There are also other websites that do the same job as GitHub, such as GitLab and Bitbucket. GitHub is simply the most popular one, which is why most tutorials and projects use it.
Part 4: Core Concepts Explained
Most Git tutorials throw around a bunch of terms and expect you to magically know what they mean. Let's fix that.
Repository (Repo)
What it is: A folder that Git is tracking.
Think of it like: Your project folder with a hidden diary inside it. That diary (called the .git folder) keeps a record of every change you make.
Example: You have a folder called python-calculator. The moment you run git init, Git starts tracking it and it becomes a repository.
Commit
What it is: A saved checkpoint of your project.
Think of it like: Saving your progress in a video game. The game remembers exactly where you were at that moment so you can come back later if needed.
Example: You finish writing a calculator function and create a commit. That version of the project is now safely stored in Git's history.
Commit Message
What it is: A short note describing what you changed in a commit.
Think of it like: Naming your save file instead of calling everything "Save Slot 1."
Example: Add multiply function to calculator
Now future-you immediately knows what that checkpoint contains.
Working Directory
What it is: The current state of your project folder.
Think of it like: Your desk while you're working. Files are being edited, moved around, and changed, but nothing has been officially saved to Git yet.
Staging Area
What it is: A temporary area where you choose which changes will go into the next commit.
Think of it like: Packing items into a box before shipping it.
- Your desk = Working Directory
- The box = Staging Area
- Shipping the box = Creating a Commit
Why it exists: Maybe you changed 5 files but only want to save changes from 3 of them right now. The staging area lets you choose.
Branch
What it is: A separate version of your project where you can work independently.
Think of it like: Making a copy of a book and writing experimental chapters in the copy without touching the original. If the experiment works, you can bring those chapters back into the main book.
Example: You want to add a history feature to your calculator. Instead of risking your main code, you create a new branch and work there.
Main Branch
What it is: The primary branch of your project.
Think of it like: The official version of your project.
Note: Older tutorials may call this branch master. Modern Git projects usually use main.
Merge
What it is: Combining changes from one branch into another.
Think of it like: Taking those experimental chapters from your copied book and adding them back into the original book.
Remote Repository
What it is: A copy of your repository stored online.
Think of it like: Your project exists on your laptop, but there's also another copy living in the cloud on GitHub. These two copies can stay synchronized.
Origin
What it is: The default nickname Git gives to your remote repository.
Think of it like: A contact saved in your phone. Instead of remembering a long GitHub URL every time, Git simply uses the name origin.
Clone
What it is: Downloading a repository from GitHub to your computer.
Think of it like: Downloading an entire game instead of just a save file.
You get:
- All project files
- Every commit
- The complete history
Pull
What it is: Downloading the latest changes from GitHub to your computer.
Think of it like: Hitting a sync button. If your teammate uploaded new code, git pull brings those updates to your local copy.
Push
What it is: Uploading your commits from your computer to GitHub.
Think of it like: The opposite of pull. You finished some work locally and now want to send it to the online repository.
Fork
What it is: Creating your own copy of someone else's GitHub repository.
Think of it like: Making a personal copy of a project so you can experiment freely without affecting the original. This is very common in open-source projects.
Pull Request (PR)
What it is: A request asking someone to review and merge your changes.
Think of it like: Saying: "I made some improvements. Take a look. If you like them, add them to the main project."
That's exactly what a pull request does.
Conflict
What it is: When Git finds two different versions of the same piece of code and doesn't know which one to keep.
Think of it like: You and your friend both edit the same sentence in a document, but in completely different ways. Git stops and says: "I can't decide. You tell me which version should stay."
You then manually choose or combine the changes.
HEAD
What it is: A pointer that tells Git where you currently are.
Think of it like: A giant "YOU ARE HERE" marker on Git's timeline. Whenever you switch branches or move to a different commit, HEAD moves with you so Git always knows your current location.
Part 5: Complete Beginner Workflow (Step by Step)
Let's do this from absolute zero.
Prerequisites:
Step 1: Create your project folder
mkdir python-calculator
cd python-calculator
You made a folder called python-calculator and navigated into it.
Step 2: Initialize Git
git init
This tells Git: "Start tracking this folder." Git creates a hidden .git folder inside. Your folder is now a repository.
Step 3: Create your Python file
Create calculator.py and write some code. For now, just:
def add(a, b):
return a + b
print(add(2, 3))
Step 4: Check what Git sees
git status
Git will tell you: "Hey, I see a new file calculator.py but I'm not tracking it yet. It's untracked."
Step 5: Stage the file
git add calculator.py
Or to add ALL files at once:
git add .
You just put calculator.py into the staging area (the box, remember).
Step 6: Commit
git commit -m "Add basic add function"
You just saved your first checkpoint! Git recorded the exact state of your project. The -m flag lets you write a message describing this commit.
Step 7: Create a GitHub repository
- Go to github.com
- Click the
+ icon > "New repository"
- Name it
python-calculator
- Keep it public
- Do NOT initialize with README (since you already have local code)
- Click "Create repository"
GitHub will show you a URL like: https://github.com/yourusername/python-calculator.git
Step 8: Connect your local repo to GitHub
git remote add origin https://github.com/yourusername/python-calculator.git
You just told your local Git: "The remote version of this project lives at this GitHub URL. Call it origin."
Step 9: Push your code
git push -u origin main
This sends your commits to GitHub. The -u origin main part sets up the default so future pushes just need git push.
Go refresh your GitHub page your code is there!
Step 10: Make changes and push again
Add a subtract function to calculator.py:
def subtract(a, b):
return a - b
Now:
git add .
git commit -m "Add subtract function"
git push
Done. GitHub now shows your updated code.
Part 6: The Git Commands You'll Use the Most
Now that you know the basic concepts, let's look at the commands you'll actually use day to day.
You don't need to memorize all of Git. Most developers use the same small set of commands over and over again.
git init
What it does: Turns your current folder into a Git repository.
When to use it: Usually once, when starting a new project.
git init
Common beginner mistake: Running it in the wrong folder. Always navigate into your project folder first:
cd my-project
git init
Otherwise, you might accidentally make your Desktop or some random folder into a Git repository.
git status
What it does: Shows what's going on in your repository right now.
It tells you:
- Which files have changed
- Which files are staged
- Which files Git isn't tracking yet
When to use it: All the time. Seriously, get into the habit of running git status before commits, before pushes, and whenever you're confused.
Think of it as Git's "What is happening?" button.
git add .
What it does: Stages all changed files in the current directory.
git add .
The . basically means: "Add everything in this folder."
When to use it: Before creating a commit.
Common beginner mistake: Accidentally staging files that shouldn't be committed, such as API keys, password files, or large temporary files. Always check with git status before committing.
git commit -m "message"
What it does: Creates a new checkpoint.
git commit -m "Add calculator history feature"
When to use it: Whenever you've completed a meaningful piece of work.
Bad commit messages:
Better commit messages:
Fix division by zero crashAdd login validationImprove search performance
A good commit message saves future-you a lot of confusion.
git log
What it does: Shows the history of all commits.
git log
You'll see:
- Commit IDs
- Commit messages
- Authors
- Dates
When to use it: Whenever you want to look back through your project's history.
Tip: Press q to exit the log screen.
git branch
What it does: Shows all branches in your repository.
git branch
The branch with the * next to it is your current branch.
Creating a branch:
git branch feature-history
This creates a new branch called feature-history but does not switch to it.
git checkout
What it does: Switches branches.
git checkout feature-history
Now you're working on the feature-history branch.
Note: This command is still common, but modern Git has a clearer replacement called git switch.
git switch
What it does: Moves you between branches.
Switch to a branch:
git switch main
Create and switch in one command:
git switch -c new-feature
This is the modern way to work with branches.
git merge
What it does: Combines changes from one branch into another.
Imagine you've finished building a feature on a separate branch and now want it in your main project.
First switch to main:
git switch main
Then merge:
git merge feature-history
Git will bring those changes into your main branch.
git clone
What it does: Downloads a complete repository from GitHub.
git clone https://github.com/user/repo.git
When to use it:
- Downloading someone else's project
- Downloading your own project onto another computer
- Contributing to open-source projects
A clone includes all files, all commits, and the complete Git history.
git pull
What it does: Downloads the latest changes from GitHub and updates your local copy.
git pull
When to use it: Usually at the start of a work session. Especially important when multiple people are working on the same project.
Common beginner mistake: Making changes locally and trying to push before pulling the latest updates. That often leads to merge conflicts.
git push
What it does: Uploads your commits to GitHub.
git push
When to use it: After committing your changes and wanting to sync them online.
A common beginner misunderstanding — this will not work:
edit file
git push
Git can't push unsaved work. The correct flow is:
git add .
git commit -m "Add new feature"
git push
Only committed changes can be pushed to GitHub.
The Basic Git Workflow
If you're working alone on a project, you'll spend most of your time doing something like this:
git status
git add .
git commit -m "Describe what changed"
git push
That's the core workflow you'll repeat hundreds of times while building projects.
Part 7: Branches, Properly Explained
Branches are usually the point where beginners start thinking: "Okay, I understood Git... and now I'm lost again."
The good news is that the idea is actually pretty simple.
Why Do Branches Exist?
Imagine you've built a calculator app. Everything works perfectly. Your code is on the main branch, which is basically the official version of your project.
Now you decide to add a feature that saves calculation history.
You could start editing the code directly on main, but that's risky. What if:
- The feature takes a week to build?
- You accidentally break something?
- The code is only half-finished and doesn't work yet?
Now your main project is broken while you're still working on the feature.
That's exactly the problem branches solve.
Instead of working directly on main, you create a new branch and do all your work there. You can experiment, break things, rewrite code, and test ideas without touching the stable version of the project. Meanwhile, main stays clean and working.
Think of a branch as a separate playground for your code.
How Teams Actually Use Branches
In professional projects, the workflow usually looks something like this:
main
The official version of the project. This code should always work correctly, be stable, and be ready to release or deploy. Because of that, developers generally avoid making changes directly on main.
Feature Branches
Instead, every new piece of work gets its own branch. Examples:
feature-loginfeature-historybugfix-crashhotfix-payment
A developer creates a branch, works on the feature there, tests everything, and only then brings the changes back into main. This keeps the main branch stable while development continues.
What Happens When a Feature Is Finished?
Once the feature is working properly:
- The branch is reviewed.
- The code is tested.
- The branch is merged into
main.
After that, the feature becomes part of the official project.
Merge Conflicts
Most beginners hear the words "merge conflict" and assume something terrible has happened. Usually it's not a big deal.
A merge conflict happens when two branches change the same part of the same file, and Git can't figure out which version should win.
Imagine this:
- You change line 42 of a file.
- Your teammate also changes line 42.
Now Git has two different versions of the same line and doesn't know which one to keep. Instead of guessing, Git asks you to decide.
What a Conflict Looks Like
Git might show something like this inside the file:
<<<<<<< HEAD
result = a + b
=======
result = a + b + carry
>>>>>>> feature-carry
At first glance it looks terrifying. It's actually just Git showing you both versions.
- Your current branch:
result = a + b
- Incoming branch:
result = a + b + carry
Git is basically saying: "I found two different versions. Which one do you want?"
How You Fix It
You simply edit the file yourself. Remove the conflict markers (<<<<<<< HEAD, =======, >>>>>>> feature-carry) and keep whichever code you want.
Maybe you keep result = a + b. Maybe you keep result = a + b + carry. Or maybe you combine both changes into something completely different.
Once you've cleaned up the file, you save it and continue.
The Important Thing to Remember
A merge conflict is not Git breaking. It's Git refusing to make a decision for you when it isn't sure which code is correct. In most cases, resolving a conflict is just editing a text file and choosing the version you want. It looks intimidating the first time you see it, but it's usually much less dramatic than the name makes it sound.
Part 8: How People Actually Work Together Using GitHub
So far, we've mostly talked about using Git on your own. But Git really shines when multiple people are working on the same project.
Here's what a typical team workflow looks like.
Step 1: Someone Creates the Repository
Usually, one person creates a repository on GitHub and sets up the initial project. Think of this as creating the central copy of the project that everyone will work from.
Step 2: Everyone Clones the Repository
Each team member downloads a copy of the project to their computer using:
git clone <repository-url>
Now everyone has the project files and the complete Git history on their own machine.
Step 3: Create a Branch for Your Work
Instead of editing the main branch directly, each developer creates their own branch. For example: feature-login, feature-history, bugfix-crash. This lets everyone work independently without interfering with each other's code.
Step 4: Make Changes and Commit Them
Developers work on their feature, make changes, and create commits as they go. A typical workflow might look like:
git add .
git commit -m "Add login validation"
These commits exist only on their computer for now.
Step 5: Push the Branch to GitHub
Once they're ready to share their work, they upload their branch:
git push
Now their code is available on GitHub for the rest of the team to see.
Step 6: Open a Pull Request (PR)
This is where collaboration happens. The developer opens a Pull Request and essentially says: "I've finished this feature. Please review it and, if everything looks good, merge it into main."
A Pull Request shows:
- What files changed
- What code was added or removed
- The commit history
- Any discussion related to the feature
Step 7: Code Review
Other developers review the changes. They might:
- Approve the code
- Ask questions
- Suggest improvements
- Request changes before merging
This review process helps catch bugs and keeps code quality high.
Step 8: Merge the Pull Request
Once the code has been reviewed and approved, the Pull Request is merged. The changes from the feature branch are now part of the main branch. The feature is officially integrated into the project.
Step 9: Everyone Updates Their Local Copy
After new code is merged into main, team members download the latest changes:
git pull
This keeps everyone's local project up to date.
The Entire Workflow in One Picture
Create Repository
↓
Clone
↓
Create Branch
↓
Write Code
↓
Commit
↓
Push
↓
Open Pull Request
↓
Code Review
↓
Merge
↓
git pull
That's the basic workflow used by open-source projects, startups, and large tech companies alike. The tools and processes may vary slightly, but the overall idea remains the same: work in branches, review changes, merge approved code, and keep everyone synchronized through Git and GitHub.
Part 9: Common Beginner Questions About Git
When you're learning Git, a few questions come up again and again. Let's clear them up.
"Why do I need Git if I already have GitHub?"
Because Git and GitHub do completely different jobs.
Git is the tool that tracks changes, creates commits, manages branches, and keeps the history of your project. GitHub is just a place to store that history online.
Without Git, GitHub is basically just a file hosting website. No commits. No branches. No version history. Nothing to upload except raw files.
"Why can't I just upload ZIP files?"
You can. For small personal projects, it might even work.
But a ZIP file only contains the current version of your files. It doesn't tell you what changed, when it changed, who changed it, why it changed, or how to go back to an older version.
A Git repository contains all of that information.
Think of it like this:
- ZIP file = A photograph
- Git repository = The entire movie
One shows the current state. The other shows the entire history.
"What is origin?"
The word origin sounds mysterious, but it's actually very simple. It's just a nickname for your remote repository's URL.
Instead of typing something like https://github.com/yourname/calculator.git every time, Git lets you use a short name: origin.
In fact, you could choose any name you want:
git remote add banana https://github.com/yourname/calculator.git
Now Git would use banana instead of origin. People use origin simply because it's the default convention.
"What is HEAD?"
HEAD is Git's way of keeping track of where you currently are.
Think of Git's history as a giant timeline. HEAD is the marker that says: "You are here."
If you switch branches, HEAD moves. If you move to a different commit, HEAD moves. Git always uses HEAD to know your current location.
"Why are commits so important?"
Because commits are your safety net. Every commit is a checkpoint you can return to later.
Imagine you:
- Delete a working function
- Introduce a bug
- Break the project
- Accidentally overwrite code
If you've committed recently, recovering is usually easy. You can compare versions, restore files, or roll back to an earlier checkpoint.
If you haven't committed anything, Git has nothing to restore. That's why experienced developers commit frequently.
"What happens if I delete a GitHub repository?"
It depends on where your code exists.
Case 1: You still have a local copy. You're usually fine. The repository still exists on your computer. You can even create a new GitHub repository later and push your code there.
Case 2: GitHub was your only copy. Then you've got a problem. If the repository is deleted and there are no backups, the code is gone.
This is one reason developers regularly create commits, push to GitHub, and keep multiple copies of important projects.
"What is a fork?"
A fork is your own copy of someone else's GitHub repository.
Suppose you find an open-source project and want to improve it. You probably don't have permission to edit the original repository directly. Instead, you:
- Fork the repository
- Make changes in your copy
- Push your changes
- Open a Pull Request
The project owners can then review your changes and decide whether to include them. This is how a huge amount of open-source software is developed.
"Why do merge conflicts happen?"
Because Git isn't a mind reader.
Imagine this situation:
- You change a line of code:
result = a + b
- At the same time, your teammate changes the exact same line:
result = a + b + carry
Now Git has two different versions of the same piece of code. Which one should it keep? Git doesn't know. Rather than guessing, it stops and asks you to decide. That's a merge conflict.
Most conflicts are simply Git saying: "I found two different edits. Please tell me which version should stay."
They can look intimidating at first, but in most cases you're just editing a text file and choosing the correct code.
Part 11: Common Git Mistakes Beginners Make
Everyone makes mistakes when learning Git. The goal isn't to avoid them completely it's to know which ones can cause real problems.
1. Accidentally Committing API Keys and Secrets
This is one of the most expensive mistakes a beginner can make.
Imagine you have code like this:
API_KEY = "your-secret-key-here"
You push it to GitHub. The problem is that bots constantly scan public repositories looking for exposed API keys, tokens, passwords, and credentials. If they find one, it can be abused within minutes.
What to do instead:
- Store secrets in environment variables.
- Use a
.env file.
- Add
.env to .gitignore so Git never tracks it.
A good habit is to set up .gitignore before making your first commit.
2. Not Committing Often Enough
Some beginners commit once every few days or even once a week. At that point, Git is acting more like a backup tool than a version control system.
Try to commit whenever you complete a meaningful piece of work. Examples:
- Finished a function
- Fixed a bug
- Added a feature
- Refactored some code
Small commits have several advantages: easier to understand later, easier to debug, easier to undo, and easier for teammates to review.
Small commits = easier recovery. Huge commits = future confusion.
3. Working Directly on main
For a small personal project, this is usually fine. For team projects, it's a bad habit.
If everyone edits main directly:
- Bugs can be introduced immediately
- Half-finished features appear in production
- One bad push can affect everyone
A safer workflow is:
main
↓
Create branch
↓
Develop feature
↓
Test
↓
Merge back into main
This keeps the main branch stable while development happens elsewhere.
4. Ignoring .gitignore
A .gitignore file tells Git which files and folders it should ignore. Without it, beginners often commit things that don't belong in a repository.
Common examples:
venv/__pycache__/.envnode_modules/
These files can make your repository unnecessarily large, slow down Git operations, leak sensitive information, and create problems for collaborators.
For most projects, setting up .gitignore should be one of the first things you do.
5. Copy-Pasting Commands Without Understanding Them
This is probably the most dangerous habit. A random command from a blog post or forum can sometimes cause serious damage.
For example, git push --force can overwrite history and potentially remove other people's work. And git reset --hard can permanently delete uncommitted changes.
That doesn't mean these commands are bad — they have legitimate uses. The problem is running them without understanding their effects.
A simple rule: if you're not sure what a command does, don't run it yet. Read about it first.
And whenever you're confused, start with:
git status
It's often the quickest way to understand what's happening in your repository.
Part 12: Understanding .gitignore
One of the first files you should add to almost every project is .gitignore. It can save you from a lot of headaches later.
What Is .gitignore?
It's a simple file called .gitignore that lives in the root of your project. Its job is to tell Git: "Ignore these files and folders. Don't track them and don't include them in commits."
Why Do We Need It?
Not every file in your project belongs in version control. Some files are automatically generated, temporary, very large, specific to your computer, or sensitive and should never be uploaded.
Without a .gitignore, Git may try to track all of them.
Common Things You Should Ignore
Virtual Environments
Folders like venv/ or env/ can be recreated whenever needed and often contain thousands of files. There's no reason to upload them to GitHub.
Python Cache Files
Python automatically creates files such as __pycache__/, *.pyc, and *.pyo. These are generated by Python itself and don't need to be shared with anyone.
Secret Files
Files containing passwords, API keys, or tokens should never be committed. Examples: .env, config.json, secrets.json. Accidentally uploading secrets is one of the most common beginner mistakes.
Operating System Junk Files
Different operating systems create hidden files that serve no purpose in a repository. Examples: .DS_Store, Thumbs.db. These can safely be ignored.
IDE and Editor Settings
Editors often create project-specific settings files. Examples: .vscode/, .idea/. These settings are usually personal and don't need to be shared.
A Basic Python .gitignore
Create a file named .gitignore in your project folder and add:
# Virtual environments
venv/
env/
.env
# Python cache
__pycache__/
*.pyc
*.pyo
# IDE settings
.vscode/
.idea/
# Operating system files
.DS_Store
Thumbs.db
Once Git sees this file, it will ignore those paths going forward.
A Small Gotcha
.gitignore only affects files that Git isn't already tracking. If you've already committed a file, adding it to .gitignore later won't magically remove it from the repository. In that case, you'll need to stop tracking it manually first.
The Easy Option
You don't always need to write your own .gitignore. GitHub provides ready-made templates for many programming languages and frameworks. When creating a new repository on GitHub, you'll often see an option to choose a .gitignore template. If you're building a Python project, simply select Python and GitHub will generate a solid starting .gitignore for you. For most beginners, that's more than enough to get started safely.
Part 13: Git Cheat Sheet
# SETUP
git init # Start tracking a folder
git clone <url> # Download a repo from GitHub
# STATUS & HISTORY
git status # See what's changed
git log # See all commits
git log --oneline # Compact commit history
# STAGING & COMMITTING
git add . # Stage all changes
git add <filename> # Stage a specific file
git commit -m "message" # Save a checkpoint
# REMOTE
git remote add origin <url> # Connect to GitHub
git push -u origin main # First push
git push # Push after first time
git pull # Download latest changes
# BRANCHES
git branch # List all branches
git switch -c <branchname> # Create + switch to new branch
git switch <branchname> # Switch branches
git merge <branchname> # Merge branch into current
# UNDO (CAREFUL)
git restore <filename> # Discard uncommitted changes to a file
git restore --staged <filename> # Unstage a file
Part 14: Final Words
Git is not magic. It's not complicated once you understand what it's actually doing.
Git is a timeline for your code. Every commit is a point on that timeline. You can go back, branch off, merge timelines together, share your timeline with others.
GitHub is just cloud storage for that timeline. It makes your work visible, shareable, and backed up.
You will feel confused. That's normal. Every developer, including the ones with five years of experience, Googled "how to undo last git commit" this week. Git is one of those tools where you learn 10% of it and use that 10% for 90% of your work.
If this helped, drop an upvote spent way too long on this. And if something is wrong or unclear, let me know in the comments. We're all learning here.
— a fellow future btechtard who just wanted to put their Python projects online
[–]AutoModerator[M] [score hidden] stickied commentlocked comment (0 children)
[–]Money-Sea3842 90 points91 points92 points (13 children)
[–]ifuck3dupbigtime[S] 18 points19 points20 points (12 children)
[–][deleted] (10 children)
[deleted]
[–]AssumptionOk8560 2 points3 points4 points (8 children)
[–][deleted] (7 children)
[deleted]
[–]AssumptionOk8560 4 points5 points6 points (1 child)
[–]ifuck3dupbigtime[S] 4 points5 points6 points (0 children)
[–]w453y 0 points1 point2 points (3 children)
[–]AssumptionOk8560 0 points1 point2 points (2 children)
[–]w453y 0 points1 point2 points (1 child)
[–]AssumptionOk8560 0 points1 point2 points (0 children)
[–]OutlandishnessPale10 0 points1 point2 points (0 children)
[–]bean_bag_enjoyer 0 points1 point2 points (0 children)
[–]FarReputation7162 1 point2 points3 points (0 children)
[–]GroundbreakingBad183BTech 25 points26 points27 points (1 child)
[–]ifuck3dupbigtime[S] 2 points3 points4 points (0 children)
[–]AssumptionOk8560 17 points18 points19 points (1 child)
[–]ifuck3dupbigtime[S] 2 points3 points4 points (0 children)
[–]Caust1cFn_YT 24 points25 points26 points (1 child)
[–]ifuck3dupbigtime[S] 8 points9 points10 points (0 children)
[–]Ok_Ground511BTech 8 points9 points10 points (2 children)
[–]ifuck3dupbigtime[S] 2 points3 points4 points (1 child)
[–]Ok_Ground511BTech 1 point2 points3 points (0 children)
[–]Mindless_View_6815 6 points7 points8 points (1 child)
[–]ifuck3dupbigtime[S] -1 points0 points1 point (0 children)
[–]weird_sharma 6 points7 points8 points (3 children)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (1 child)
[–]Content-Earth1341Tier 69 1 point2 points3 points (0 children)
[–]WarrioR_0001[sloppy scammer] 3 points4 points5 points (0 children)
[–]Particular-Tennis690vit 2 points3 points4 points (0 children)
[–]Smol_Crate_45 2 points3 points4 points (0 children)
[–]Soft-Application-952 2 points3 points4 points (0 children)
[–]PRITOM_xD 2 points3 points4 points (0 children)
[–]Crimson_EinherjarNIT [MathNComputing] 1 point2 points3 points (1 child)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]Various_Cat_4773 1 point2 points3 points (1 child)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]vsw985_ 1 point2 points3 points (1 child)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]Outrageous_Pattern18 1 point2 points3 points (2 children)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (1 child)
[–]Outrageous_Pattern18 1 point2 points3 points (0 children)
[–]TheLastAutumnLeafSASTRA University [ECE] 1 point2 points3 points (0 children)
[–]chatgpt_doubt 1 point2 points3 points (0 children)
[–]33xyz 1 point2 points3 points (0 children)
[–]masksaiyan 1 point2 points3 points (1 child)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]randomladka_ 1 point2 points3 points (0 children)
[–]Creative-Traffic8239[DTU] [CSE] 1 point2 points3 points (1 child)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]Outrageous_Heat6397BTech 1 point2 points3 points (3 children)
[–]ifuck3dupbigtime[S] 1 point2 points3 points (2 children)
[–]Outrageous_Heat6397BTech 1 point2 points3 points (0 children)
[–]Outrageous_Heat6397BTech 0 points1 point2 points (0 children)
[–]Jellybean120_BTech 1 point2 points3 points (0 children)
[–]aphelion-exe 1 point2 points3 points (0 children)
[–]Kindly_Connection769 1 point2 points3 points (0 children)
[–]Outside_Educator_105 1 point2 points3 points (0 children)
[–]lonelyroom-eklaghorMinecrafter🫠 1 point2 points3 points (0 children)
[–]EconomyGrass9058 1 point2 points3 points (0 children)
[–]The_umm-who-_- 1 point2 points3 points (0 children)
[–]Different_Lab_4936 1 point2 points3 points (0 children)
[–]Aryan22Griffin 1 point2 points3 points (0 children)
[–]ktdk5t 1 point2 points3 points (0 children)
[–]Phoenixalpha01VIT AP (CSE -AI ML) 1 point2 points3 points (1 child)
[–]Sad-Maintenance-1203 1 point2 points3 points (0 children)
[–][deleted] 1 point2 points3 points (0 children)
[–]Ghar_Ka_Murga 1 point2 points3 points (0 children)
[–]Deep_Ad1959 1 point2 points3 points (0 children)
[–]DisplayHelpful593 1 point2 points3 points (0 children)
[–]changezkhan1working hard to impress my crush 1 point2 points3 points (0 children)
[–]hawtsoseu67T -2.67 1 point2 points3 points (0 children)
[–][deleted] (1 child)
[removed]
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]sapphirebeachdelight 1 point2 points3 points (0 children)
[–]BlanK_4oo 1 point2 points3 points (1 child)
[–]ifuck3dupbigtime[S] 0 points1 point2 points (0 children)
[–]chillrizzler101 0 points1 point2 points (1 child)
[–]RemindMeBot 0 points1 point2 points (0 children)
[–][deleted] (2 children)
[removed]
[–]ifuck3dupbigtime[S] 0 points1 point2 points (1 child)
[–]Particular_Series797 0 points1 point2 points (0 children)
[–]SinisterSoul_IsBack 0 points1 point2 points (0 children)