Git Tutorial: A Beginners Guide To Git And GitHub

Git is an important concept in software development. In this git tutorial we will guide you how to use Git and GitHub.

Imagine a developer has a folder on their computer that looks exactly like this:

• app-layout-v1
• app-layout-v2
• app-layout-v2-final
• app-layout-v2-final-REALLY-FINAL
• app-layout-v2-final-bugfix-oops

They do this because they are terrified of breaking things. When you have a working piece of code, the last thing you want to do is change it, break it, and realize you can’t remember how to get back to the working version.

Git was built to solve this exact problem. It is a version control system. You can think of it as a time machine, a highly organized save-game system, and a collaboration tool all rolled into one.

Git vs. GitHub: Clearing the Confusion

Before we write a single command, we need to clear up the most common point of confusion for beginners. Git and GitHub are not the same thing.

• Git is the actual software running on your local computer. It is the engine that tracks your file changes. It doesn’t need the internet to work.
• GitHub (and alternatives like GitLab or Bitbucket) is a website that hosts Git repositories in the cloud. It’s essentially a social network and backup server for your Git projects.

You use Git locally to track your work, and you push your Git history to GitHub so others can see it, or so you have a backup if your laptop dies.

Step 1: Getting Set Up

If you are on a Mac, you probably already have Git installed. Open your terminal and type:

$ git --version

If it prints a version number (like git version 2.39.2), you are good to go. If not, it will usually prompt you to install it. Windows users can download and install “Git for Windows” (which includes Git Bash, a highly recommended terminal).

Once installed, you need to introduce yourself to Git. Every time you save a version of your code, Git attaches a name and email to it so everyone knows who made the change. Run these two commands in your terminal, using your own information:

$ git config --global user.name "Jane Doe"
$ git config --global user.email "jane@example.com"

Step 2: The Core Mental Model

To use Git effectively, you have to understand how it views your files. Git moves your files through three distinct “zones” or “states.” If you understand this diagram, you understand 80% of Git.

+-------------------+       +-------------------+       +-------------------+
|                   |       |                   |       |                   |
|  1. Working       |       |  2. Staging       |       |  3. Local         |
|     Directory     | ----> |     Area          | ----> |     Repository    |
|                   | git   |                   | git   |                   |
| (Your active      | add   | (The loading dock)| commit| (The permanent    |
|  files/editor)    |       |                   |       |  record)          |
+-------------------+       +-------------------+       +-------------------+

1. The Working Directory: This is just your project folder. You open files in your code editor, write Javascript, save files, and delete things here. Git is watching this folder, but it isn’t permanently recording anything yet.
2. The Staging Area: Think of this as a loading dock or a photographer’s stage. When you are happy with a file, you use git add to place it on the stage. You can put just one file on the stage, or ten.
3. The Local Repository: Once you have arranged the stage exactly how you want it, you take a snapshot using git commit. This permanently saves the state of those staged files into Git’s database (your timeline).

Step 3: Starting a Project

Let’s build a simple web application. Open your terminal and create a new folder:

$ mkdir my-web-app
$ cd my-web-app

Right now, this is just a normal folder. To tell Git to start watching it, we initialize a new repository:

$ git init
Initialized empty Git repository in /Users/janedoe/my-web-app/.git/

Git just created a hidden folder inside your project called .git. You never need to touch this folder yourself—it is Git’s secret database where it will store all your snapshots.

Let’s check what Git sees right now using the most important command you will ever learn: git status.

$ git status
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)

It tells us our working directory is totally clean. Let’s change that by creating a couple of files. Imagine you are starting a React or Node project, and you create an index.js and a styles.css.

$ touch index.js
$ touch styles.css

If we run git status again, Git notices the new files:

$ git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	index.js
	styles.css

Git marks them as “Untracked.” This means Git sees them in your Working Directory, but they have never been saved to the timeline.

Step 4: Staging and Committing

Let’s say we wrote some initial setup code in index.js and we want to save this progress. We need to move it to the Staging Area.

$ git add index.js

Now, what does git status say?

$ git status
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   index.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	styles.css

Look at how clear that is. index.js is on the stage (Changes to be committed). styles.css is still sitting in the working directory, untracked.

Let’s go ahead and take our snapshot. We use the commit command and attach a message using the -m flag. The message should clearly describe what you just did.

$ git commit -m "Add initial index.js file"
[main (root-commit) 8f3c1a2] Add initial index.js file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.js

Congratulations, you just saved your first point in time. index.js is now safely stored in the Local Repository.

If you want to stage everything in your project folder at once (which you will do often), you can use a period . instead of a file name:

$ git add .
$ git commit -m "Add empty styles file"

Step 5: Viewing the Timeline

As you work, you will make dozens of commits. You can view your history using the git log command.

$ git log
commit a1b2c3d4e5f67890 (HEAD -> main)
Author: Jane Doe <jane@example.com>
Date:   Wed May 15 10:30:00 2026 -0400

    Add empty styles file

commit 8f3c1a2b3c4d5e6f
Author: Jane Doe <jane@example.com>
Date:   Wed May 15 10:25:00 2026 -0400

    Add initial index.js file

Every commit gets a unique ID (that long string of letters and numbers called a hash). This hash is your exact coordinates in the time machine. If you ever break your project completely, you can always tell Git to return your files to exactly how they looked at 8f3c1a2b3c4d5e6f.

Step 6: Branching

Branching is Git’s most powerful feature.

Imagine you have a working website. You want to build a brand new user authentication feature. If you start changing the working code, your site might be broken for days while you figure it out.

Instead, you create a branch. A branch is an alternate reality. It’s an exact copy of your code at that moment in time, where you can experiment safely. If the experiment fails, you can delete the branch and your main code is untouched.

Let’s create a branch for our new feature:

$ git branch feature-login

This creates the branch, but we are still standing in the main branch. To switch our environment to the new branch, we use the switch (or checkout) command:

$ git switch feature-login
Switched to branch 'feature-login'

Now, let’s create a new file specifically for this feature.

$ touch login.js
$ git add login.js
$ git commit -m "Build login logic"

Right now, your repository looks like a fork in the road.

          (main)
            v
Commit 1 -> Commit 2 
                   \
                    -> Commit 3
                          ^
                    (feature-login)

To prove how this works, switch back to your main branch:

$ git switch main

If you look at your project folder right now, login.js has vanished. Your files have physically reverted to the state they were in before you created the branch. Your main branch is safe and stable. Switch back to feature-login, and login.js reappears.

Step 7: Bringing it Together (Merging)

Let’s assume your new login feature works perfectly, and you want to apply it to your main codebase. You need to merge the feature branch into the main branch.

First, always make sure you are standing on the branch you want to receive the changes. We want main to receive the updates, so we switch to it:

$ git switch main

Now, tell Git to grab the changes from your feature branch and pull them into main:

$ git merge feature-login
Updating 8f3c1a2..d9e4f5a
Fast-forward
 login.js | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 login.js

Git successfully combined the timelines. The main branch now includes login.js. Since the feature is complete and merged, you can clean up by deleting the experimental branch:

$ git branch -d feature-login

A Note on Merge Conflicts

Sometimes, things don’t go perfectly. If you edited line 10 of index.js on the main branch, and you also edited line 10 of index.js on your feature-login branch, Git won’t know which version to keep when you merge them.

This is called a Merge Conflict.

Git will pause the merge, and if you open index.js in your code editor, you will see something like this:

<<<<<<< HEAD
const userStatus = "active";
=======
const userStatus = "disabled";
>>>>>>> feature-login

Don’t panic. Git is simply showing you both versions and asking you to choose. All you have to do is delete the markers (<<<<<<<, =======, >>>>>>>), keep the code you want, save the file, and then run git add index.js and git commit to finalize the merge.

Step 8: The Outside World (GitHub & Remotes)

Up until now, everything has happened entirely on your own laptop. If your hard drive crashes, your project and all its history are gone. This is where GitHub comes in.

Once you create a free account and click “New Repository” on GitHub, it will give you a web URL for your project (e.g., [https://github.com/janedoe/my-web-app.git](https://github.com/janedoe/my-web-app.git)).

You need to connect your local folder to this remote URL. In Git terminology, a remote repository is usually referred to as origin.

$ git remote add origin https://github.com/janedoe/my-web-app.git

This command doesn’t upload anything. It simply teaches your local Git folder the address of the GitHub server.

To actually send your history, your branches, and your code up to the server, you push it.

$ git push -u origin main

Note: The -u flag is only needed the very first time, to tell Git to link your local main branch with the remote main branch. After that, you can just type git push.

If you go look at your GitHub page in your browser, all your files will be sitting there.

Collaborating with Pulls

If you are working with a partner, they might push their own changes to the GitHub repository while you are asleep. Before you start working the next day, you need to download their changes into your local laptop. You do this by pulling.

$ git pull origin main

This grabs any new commits from GitHub and seamlessly merges them into your local folder.

Starting from Scratch (Clone)

What if you get a new laptop, or you want to download an open-source project? You don’t use git init. Instead, you copy the entire repository from GitHub down to your machine using clone.

$ git clone https://github.com/janedoe/some-other-project.git

This downloads the project, the entire history, the .git folder, and automatically sets up the remote connection.

3 Rules to Live By

If you are just starting out, memorize these three habits. They will save you from 99% of Git headaches.

1. Commit Often, but Commit Logical Chunks. Don’t work for 8 hours and make one massive commit called “did work.” If you build a navbar, commit. If you fix a bug on the login page, commit. If you break something later, it is much easier to revert one small, specific commit than an entire day’s work.
2. Never work directly on the main branch. Treat main as the sacred, working version of your software. If you want to try an idea, fix a bug, or add a feature, immediately create a branch (git switch -c new-feature-name). Merge it into main only when you know it works.
3. Always git status before you git commit. Make it a muscle memory. Always check what is on the stage before you take the photo. It prevents you from accidentally committing API keys, massive log files, or code you didn’t mean to include.

The moment you start using Git for real-world projects, the “happy path” of simply adding and committing files disappears. You will eventually commit to the wrong branch, misspell a commit message, realize a feature is entirely broken, or need to pause mid-thought to fix a critical bug. So, let’s try to learn how to deal with such issues.

Stashing In Git

Imagine you are deep into building a complex new data visualization component. Your files are a mess of half-written code. Suddenly, your team lead messages you: “There is a critical typo on the live homepage, we need you to fix it right now.”

You cannot switch to the main branch to fix the typo because your working directory is full of half-finished, broken code. Git will block you from switching branches to prevent overwriting your unsaved work. You also do not want to commit this broken code just to save it.

This is the exact scenario git stash was built for.

How Stashing Works

The stash is a temporary drawer outside of your working directory and outside of your commit history. It takes all your modified, uncommitted files and shoves them in this drawer, returning your working directory to a completely clean state.

$ git stash
Saved working directory and index state WIP on feature-branch: 9f8a7b6 Add base chart layout

Your working directory is now identical to your last commit. You are free to switch to main, fix the typo, commit the hotfix, and push it.

Once the emergency is over, you switch back to your feature branch. To pull your half-finished work out of the drawer and put it back into your working directory, you use “pop”:

$ git stash pop

This restores your messy files exactly as you left them and deletes that specific stash from the drawer.

Advanced Stashing

• Stashing Untracked Files: By default, git stash only hides files Git is already tracking. If you created a brand new file (like ChartHelper.js) that has never been committed, Git will leave it in your working directory. To stash everything, including new files, use: git stash -u (the -u stands for include untracked).
• Multiple Stashes: You can stash multiple times. Git keeps a stack of them. You can view your drawer by typing git stash list, which will output something like stash@{0}: WIP on..., stash@{1}: WIP on....
• Applying vs. Popping: If you want to apply a stash to your current branch but keep a backup of it in the drawer, use git stash apply instead of git stash pop.

Fixing Local Mistakes

Before we look at changing the permanent timeline, let’s look at the daily micro-mistakes you make before a commit is pushed to the public.

“I made a typo in my last commit message!”

You type git commit -m "Fix login bu", hit enter, and immediately realize you missed the ‘g’. As long as you haven’t pushed this to GitHub yet, you can rewrite the very last commit using --amend.

$ git commit --amend -m "Fix login bug"

This entirely replaces the previous commit with the new message.

“I forgot to include a file in the last commit!”

You commit your changes, but then realize you forgot to save and stage the CSS file that goes with them. You don’t want a second commit that just says “forgot the css”. You can use amend to bundle it into the previous commit.

$ git add styles.css
$ git commit --amend --no-edit

The --no-edit flag tells Git to add the staged CSS file to the last commit without changing the commit message.

“I staged a file I didn’t mean to!”

You run git add . but realize it grabbed a massive .log file or a password file you do not want to commit. You need to pull it off the staging area, but you do NOT want to delete the file from your computer.

$ git restore --staged passwords.txt

This moves the file backward from the Staging Area to the Working Directory. Your file is safe on your hard drive, but it will no longer be included in the next commit.

“I ruined this file, take me back to the last save!”

You spend an hour refactoring a function, and it is a disaster. You just want to throw away all the changes you made to that specific file since your last commit.

$ git restore database.js

Warning: This is destructive. Git will overwrite your current file with the version from your last commit. Your messy hour of work is gone forever.

Revert vs. Reset

When you need to undo a commit that has already been made, you have two choices. Understanding the difference between revert and reset is the dividing line between junior and senior Git users.

git revert: The Safe, Forward-Moving Undo

Imagine your timeline looks like this: Commit A -> Commit B -> Commit C (The Mistake)

You pushed Commit C to GitHub, and it immediately breaks the production server. You need to undo it.

If you use git revert, Git does not delete Commit C. Instead, Git figures out exactly what changes were made in Commit C, generates the exact opposite of those changes, and bundles them into a brand new commit.

$ git revert <hash-of-commit-C>

Your timeline now looks like this: Commit A -> Commit B -> Commit C -> Commit D (Reverts C)

Why this is safe: You never altered history. You moved forward to fix a problem. Because the history remains perfectly intact, your teammates’ local repositories won’t break when they pull your updates. Rule of thumb: If a commit has already been pushed to a shared remote (like GitHub), always use revert to undo i

git reset: The Destructive Rewind

If revert is adding an anti-venom to the timeline, reset is literally turning back the clock and erasing the future.

If you have Commit A -> Commit B -> Commit C (The Mistake) and you use reset, you force Git’s timeline pointer back to Commit B. As far as Git is concerned, Commit C never happened.

Because reset alters history, you should never use reset on a branch that other people are working on. It is strictly for cleaning up your own local, unpushed branches.

Reset comes in three “flavors” (levels of destructiveness) based on how it handles the files from the erased future.

1. git reset --soft <hash> Moves the timeline back, but takes all the work from the erased commits and places it neatly in your Staging Area. Use case: You made three tiny commits locally, and you want to squash them into one big, clean commit before pushing. You --soft reset back three steps, and commit everything once.

2. git reset --mixed <hash> (The Default) Moves the timeline back, but takes all the work from the erased commits and places it in your Working Directory (unstaged). Use case: You went down the wrong path, but you want to keep the code you wrote to reference or copy-paste from as you build a different solution.

3. git reset --hard <hash> Moves the timeline back and literally destroys all the files and changes from the erased commits. Your working directory is forced to look exactly like the target commit. Use case: You completely broke your local branch, the code is useless, and you want to nuke it and start over from a clean slate.

The Ultimate Safety Net: The Reflog

What happens if you run git reset --hard and immediately realize you just permanently deleted the wrong branch or erased an entire day of good work?

Git actually has a secret, hidden diary called the Reference Log (Reflog).

Git quietly records every single time the tip of your branch moves, even if you deleted the commit. If you commit, it logs it. If you switch branches, it logs it. If you perform a destructive hard reset, it logs the fact that you did it, and it remembers the hash of the commit you just orphaned.

To view this secret diary, type:

$ git reflog

You will see an output like this:

8a9b0c1 HEAD@{0}: reset: moving to HEAD~1
f3d4e5a HEAD@{1}: commit: Build the perfect feature that I just accidentally deleted
d2c3b4a HEAD@{2}: checkout: moving from main to feature-branch

Look at HEAD@{1}. Git remembers the hash (f3d4e5a) of the commit you just destroyed. To get it back, you simply reset forward to that orphaned hash:

$ git reset --hard f3d4e5a

Your deleted work is instantly resurrected. The reflog is local to your machine and is usually cleaned out every 30 to 90 days.

Integrating Timelines: Merge vs. Rebase

When a feature branch is finished, it needs to be integrated into the main branch. Up to now, you likely learned git merge. But advanced teams often require git rebase. Understanding the geometric difference between them is crucial.

The Anatomy of a Merge

When you use git merge feature-branch, Git looks at the timeline of main and the timeline of your feature, and it ties them together in a knot. This knot is a brand new commit called a “Merge Commit.”

      (Commit A) ---> (Commit B) ---> (Merge Commit)  <-- main
          \                             /
           \                           /
            (Feat 1) ---> (Feat 2) ----

Pros: It is 100% historically accurate. It shows exactly when the branch was created and when it was merged. It is entirely safe. Cons: If a team of ten developers are constantly merging branches, the commit history begins to look like a chaotic web of train tracks. It becomes very difficult to read the history and figure out when specific bugs were introduced.

The Anatomy of a Rebase

Rebase is designed to keep your project’s history looking like a single, perfectly straight line, no matter how many branches were used.

Instead of tying a knot, git rebase actually unplugs your feature branch from the past, carries it forward, and plugs it into the very front of the main branch.

To do this, you switch to your feature branch and run:

$ git rebase main

Behind the scenes, Git does something highly destructive and magical. It takes your feature branch commits, deletes them, and re-writes them completely, applying them one by one onto the tip of main.

BEFORE REBASE:
(Commit A) ---> (Commit B) <-- main
      \
       (Feat 1) ---> (Feat 2) <-- feature-branch

AFTER REBASE:
(Commit A) ---> (Commit B) <-- main
                      \
                       (Feat 1 NEW) ---> (Feat 2 NEW) <-- feature-branch

Once rebased, you can switch to main and do a standard merge, which will now just slide forward in a straight line (a “fast-forward” merge) without creating a knot.

Pros: A perfectly clean, linear, easy-to-read commit history. Cons: Because rebase rewrites the commits (giving them completely new hash IDs), it is rewriting history.

The Golden Rule of Rebasing

Never rebase a public branch.

If you push your feature-branch to GitHub, and another developer downloads it to help you, your branch is now public. If you then run git rebase on your machine, Git deletes your old commits and creates new ones. When you try to push your rebased branch back to GitHub, the server will reject it because your local history no longer matches the server’s history.

If you force the push (git push --force), your teammate’s local repository will instantly break because the commits they based their work on literally no longer exist.

You should only ever rebase branches that exist entirely on your own local laptop, before you push them to the rest of the team.

Very Important: .gitignore

Git is incredibly obedient. If you tell it to track a folder, it will track every single file inside that folder.

If you are building a modern web application, you will inevitably download external libraries (like when you run npm install). This creates a folder usually called node_modules that contains tens of thousands of files. If you accidentally run git add . and commit that folder, your Git repository will become bloated, painfully slow, and nearly impossible to upload to GitHub.

Worse, you might have a file named .env that contains your secret database passwords or API keys. Committing that file to a public GitHub repository means bots will steal your credentials within seconds.

To prevent this, you create a plain text file in the root of your project called exactly .gitignore.

Inside this file, you simply list the names of the files or folders you want Git to pretend do not exist:

node_modules/
.env
*.log

Git will now actively ignore those files. Even if you run git add ., they will never be placed on the Staging Area.

Look, Don’t Touch: git fetch

Earlier, we covered git pull as the way to download updates from GitHub and merge them into your local files.

What most people don’t realize is that git pull is actually a combination of two different commands chained together: git fetch followed immediately by git merge.

Sometimes, you want to see what your team has been working on without actually changing your local files yet. You just want to update your local Git database so it knows about the new branches and commits on the server.

$ git fetch origin

This reaches out to GitHub and downloads all the new history, but it stops there. It does not touch your Working Directory. It does not merge anything. It is the equivalent of looking through a window at the new code before deciding if you want to open the door and let it in.

The Sniper: git cherry-pick

Imagine you have a massive feature-branch that has been in development for a month. It has 50 commits on it. It is nowhere near ready to be merged into main.

However, commit #12 on that branch was a brilliant fix for a critical bug. You need that specific bug fix on main right now, but you do not want the other 49 experimental commits.

You cannot use merge or rebase because those bring the entire branch. Instead, you switch to main and use the sniper approach:

$ git cherry-pick <hash-of-commit-12>

Git will grab a copy of that single commit, apply the exact changes from it onto your current branch, and leave the rest of the feature branch alone

The Complete Git Command Reference

Here is the reference table of every command we have covered, categorized by workflow, with their exact arguments and real-world uses.

1. Setup & Configuration

Command	Arguments / Flags	What it does
git config	--global user.name "Name"	Sets the author name attached to all your commits.
git config	--global user.email "Email"	Sets the author email attached to all your commits.
git init	(none)	Creates a brand new, empty Git repository in your current folder.
git clone	<url>	Downloads an existing project and its entire history from the internet.

2. The Core Daily Workflow

Command	Arguments / Flags	What it does
git status	(none)	Shows which files are modified, staged, or untracked. Use constantly.
git add	<file>	Moves a specific file to the Staging Area.
git add	.	Moves all modified and untracked files to the Staging Area.
git commit	-m "Message"	Takes a permanent snapshot of the Staging Area with a descriptive note.
git log	(none)	Displays the timeline history of commits for the current branch.

3. Branching & Integrating

Command	Arguments / Flags	What it does
git branch	<branch-name>	Creates a new parallel timeline (branch), but does not switch you to it.
git branch	-d <branch-name>	Safely deletes a branch (only if its changes are already merged).
git switch	<branch-name>	Changes your working directory to match the specified branch.
git switch	-c <branch-name>	Creates a new branch and immediately switches you to it.
git merge	<branch-name>	Combines the specified branch into the branch you are currently standing on.
git rebase	<branch-name>	Rewrites the current branch’s commits so they start at the tip of the target branch.

4. Undoing & Fixing Mistakes

Command	Arguments / Flags	What it does
git restore	--staged <file>	Removes a file from the Staging Area without deleting your code changes.
git restore	<file>	Destructive: Overwrites the file with the version from the last commit.
git commit	--amend -m "Msg"	Replaces the very last commit with new staged files or a new message.
git revert	<hash>	Creates a brand new commit that does the exact opposite of the target commit.
git reset	--soft <hash>	Rewinds the timeline; leaves all undone work in the Staging Area.
git reset	--mixed <hash>	Rewinds the timeline; leaves all undone work in the Working Directory.
git reset	--hard <hash>	Destructive: Rewinds the timeline and completely destroys the undone work.
git reflog	(none)	Shows the secret history of every timeline movement. Used to recover lost commits.

5. Pausing Work

Command	Arguments / Flags	What it does
git stash	(none)	Hides all tracked, modified files in a temporary drawer. Cleans directory.
git stash	-u	Hides all files, including brand new untracked files.
git stash pop	(none)	Takes the most recently stashed files out of the drawer and applies them.
git stash list	(none)	Shows all the different stashes you currently have saved.

6. Working with GitHub (Remotes)

Command	Arguments / Flags	What it does
git remote	add origin <url>	Teaches your local folder the web address of your GitHub repository.
git fetch	origin	Downloads new remote history to your local database without altering your files.
git pull	origin <branch>	Downloads new remote history AND immediately merges it into your active files.
git push	origin <branch>	Uploads your local commits and history to the GitHub server.
git push	-u origin <branch>	Uploads and links the local branch to the remote branch for future tracking.

That is all you need to understand git. Apart from above concepts there are many commands but you don’t need to know all of them in one go. Try to practice these first and then you can search for new commands if needed. These concepts will help you more than anything.