Git Basic Commands Step-By-Step Guide - A Complete Breakdown With Real Commands and Output

What We Are Doing Right Now

I am on a Mac and I am going to open up a Terminal window. If you are on Windows, you can open up Command Prompt or PowerShell - both will work for what we are doing. The plan is simple and very real world. I am going to go to my Desktop, create a brand new folder called fruit, and we are going to store our code in there while we learn Git.

I am going to cd into that fruit directory. I am also going to open it up in a Finder window so we can keep an eye on what we are doing visually. When I say I am keeping an eye on it, imagine Finder sitting next to Terminal, and every time I create or change a file, you will see it appear or change in Finder. That way you can connect what Git is saying in the terminal with what is actually happening on your file system.

The Overlooked Setup Step - git config

One of the most often overlooked setup steps in Git is the Git config file. Basically, when you make commits to a Git repository, we want to know who made that commit - that it is you and not somebody else. Git records the author on each commit, and if you do not tell Git who you are, it will ask, or worse, you will end up with commits with missing or incorrect identity.

The easiest way to do this is to tell Git your name and your email address. This is a once and done setup type of thing. You do it one time and you will never have to worry about it again unless you change your name - but you are probably not going to do that. Your email can be any email you want associated with your code history. If you are pairing this with GitHub later, you can use the same email you use on GitHub so commits line up with your account.

Commands to set your identity

git config --global user.name "tony teaches tech" git config --global user.email "Tony teaches tech"

All this really does is create or update a hidden file in your home directory called .gitconfig with that same exact information. If you were to open it, you would see a [user] section with name and email values. You do not need to manage that file by hand. We are done with that and we do not have to worry about it again.

Two Ways To Start Working With Git - init or clone

There are basically two different ways you can interact with a Git repository:

• Create a brand new Git repository in a folder with git init.
• Clone an existing repository from somewhere like GitHub with git clone.

In this session, we are going to use git init because we are working locally and learning core commands. We will do the GitHub side of things - clone, push, pull - in another video. This one is just local Git commands, local repo, no remotes yet.

Initialize a repository

cd ~/Desktop mkdir fruit cd fruit git init

Git tells you it initialized a Git repository in the fruit directory. Inside fruit, there is now a hidden folder named .git. You do not see anything happen in Finder because this is a hidden folder. On macOS and Linux, files or folders that start with a dot are hidden by default.

Show hidden files to confirm .git is there

ls -la

You will see the .git folder listed. If you peek inside it, you will see a whole bunch of stuff - HEAD, refs, objects, config - that we do not need to concern ourselves with for now. That is where all your branches are tracked, your commits are stored, and all the guts of Git live. I just want you to know that this exists so you are not surprised by the hidden folder. That is all we are going to look at in there.

Start Working With Files - Create Orange py and Make Your First Commit

Let us start working with files. You can write any type of code you want. I am going to make a Python file called Orange py and I am going to use the Vim text editor. You can use Nano or any other editor you are more comfortable with. For the sake of this demonstration, I am just going to edit my files with Vim.

Create the file and add simple content

vim Orange.py

Inside that file, I am going to write a super simple Python program:

print("I like Orange")

I will save that file. If you are watching in Finder, that file has now been created and appears in the fruit folder. This is the visual confirmation that the file exists on disk.

Ask Git what it thinks - git status

git status

Git says we are on the main branch, we do not have any commits yet, and there is one untracked file. Git is really helpful here - it even tells you what to do next. It says: use git add followed by the name of the file to include it in what will be committed.

Understand the three stages in the Git workflow

Think about it this way. There are basically three stages to the workflow when you are adding files to a Git repository:

• Files on your file system - that is just normal files like Orange py sitting in your folder.
• The staging area - also called the index - where you prepare which changes you want included in the next commit. You put files here with git add.
• The commit - a permanent snapshot in the repository history that you create with git commit when you are ready.

We are going to do that exact workflow a couple times in this session so it sticks.

Stage the new file

git add Orange.py

Check status again to see what changed:

git status

Now Git shows changes to be committed, including a new file called Orange py. This means the file is in the index - the staging area. If you want to revert out of that and unstage it, Git gives you a very helpful hint. It will say something like: use git rm --cached followed by the file name to unstage. That is how you move a change out of the staging area without deleting your working file.

The area we are in now is called the staging area or the index. I am calling out both names so you recognize them in documentation and help messages in the future.

Commit the staged change

We are ready. We are happy with our code change, our new file here. Let us commit it.

git commit

Your default text editor - in my case Vim - is going to pop up when you run git commit. You can set which editor Git uses with a git config command, but we will not go over that here. All you have to do in the editor is type a commit message that describes what you did.

What did we do here? I am going to say:

I added a new file about oranges.

Because I am using Vim, I will type Escape, then :wq, and hit Enter to save that message and exit. Git responds by telling you one file was changed and it created this Orange.py file in the repository history.

Confirm with status and log

git status

We are on the main branch, and there is nothing to commit. The working tree is clean. That phrase means your working directory matches the most recent commit and there are no staged or unstaged changes.

git log

Git prints the history of commits. Right now there is one commit. You will see a long commit hash, the author information, the date and time, and the commit message: I added a new file about oranges. That is the complete paper trail for what we just did.

So we just went through the whole flow - from a file on our file system to the staging index area to committing the file into our repository.

Take It A Step Further - Modify The File and Use git diff

Let us take it a step further. Let us modify that file. I am going to open up the Orange py file and change the sentence just a bit.

vim Orange.py

Instead of saying I like Orange, I will make it plural and add some feeling. I will say:

print("I like oranges!")

I will save that file. Now run status again.

git status

Git shows that the file has been modified. Git is smart enough to know the file changed compared to what was previously committed. It compares your working copy to the last snapshot and tags the file as modified.

See exactly what changed with git diff

git diff

The output shows the old content in red and the new content in green. The old content of the file was I like Orange. The new content is I like oranges! This is super helpful when you are trying to review what you did before deciding if you want to commit it.

Add Another File - Apple PI Then Stage Files Individually and All At Once

We are not ready to commit the change yet. Let us say we want to add another file to our repository at the same time. I am going to make a new file called apple.PI. Same idea - a simple Python file that prints something.

vim apple.py

Inside apple.PI I will write:

fruit = "apple" print("I also like to eat 0".format(fruit))

If we were to run this code, it would print to the console: I also like to eat apple. That just proves the string formatting works and the variable is wired up. I will save that. In Finder, you can see the apple file appear next to the orange file in the fruit folder.

Check the state of both files

git status

Now we have two different things going on at once:

• A file on our file system that is untracked - Git does not know anything about apple.PI yet.
• A file that has been committed before but is now modified - Orange py is changed and not staged.

Stage one file at a time

Let us actually add one of those at a time so you can see how the staging area works in practice.

git add Orange.py git status

Now you can clearly see those two separate stages in the output. Orange py is in the staging area - ready to be committed. Apple.PI is still untracked - not staged, not committed.

Stage everything with a shortcut

Let us add them both at the same time. If you do not want to specify a file by name, and you want to add everything in the working directory, use a dot. That tells Git to add all new and changed files from the current folder down.

git add . git status

Now the changes to be committed show both files. Both of those files are in the index - the staging area. They are queued up for the next commit.

Commit with an inline message

Let us do a different type of commit now. Instead of opening an editor, we will provide the message inline using -m for message. This is shorthand and is great for quick, clear commits.

git commit -m "update it Orange add it Apple"

Git responds: two files changed, three insertions, one deletion. That line by line summary means it added three lines and removed one when comparing the new commit to the previous one.

Review Your History With git log

git log

Now we have two commits in our Git repository. The log shows the first one where we added the new file about oranges. The second one is where we updated the Orange file and added the Apple file. You can scroll the log to see details like hashes, author, dates, and messages. This is the running history of your project.

We can keep doing this indefinitely - write code, stage changes, commit snapshots. Along the way you just learned and used the essentials that matter every day:

• git add - put changes in the staging area.
• git commit - create a snapshot with a message.
• git diff - see exactly what changed before you commit.
• git log - review your commit history.
• git status - your real time dashboard of what is happening.

These are all local commands that only interact with your local repository. No servers, no remotes, no network - just you and your code on your machine.

What Is Next

In the next video, I am going to show you how to add this Git repository to GitHub. We are going to be working with commands like git clone, git push, and git pull. That is where you start collaborating and syncing your work online. Subscribe if you liked this video, and I will see you over there.