Top Git Commands I Use Every Day - Most Used Git Commands for Beginners

What Is git config and Why It Comes First

Let’s start right at the beginning. After you install Git on your machine, the first thing I do is tell Git who I am.

The git config command lets you set configuration values so Git knows your identity and can personalize your workflow. That way, anytime you make a commit, your name and email are attached to it and you actually get credit for your work.

Here’s what I type to set my username and email:

git config --global user.name "Lady Kerr" git config --global user.email "ladycurmail.com"

Those two lines connect your work with your identity. If you ever wonder what you’ve set so far, run:

git config --list

That prints out all your current Git configuration values so you can verify everything is correct.

Now let’s go a little further. I like creating aliases - little shortcuts - for commands I use a lot. It saves keystrokes and time.

For example, if I want a shorthand for git init, I can set an alias named i like this:

git config --global alias.i init

Now every time I type git i, Git runs git init for me. It feels tiny, but honestly, these small wins add up when you’re moving fast.

Starting Fresh: git init, git status, and Your First Files

Imagine you just created a new folder for a project. Right now it’s just a normal folder - not a Git repository yet.

I’ll create one and step inside it:

mkdir project1 cd project1

At this moment, project1 isn’t tracked by Git. To turn on Git inside this folder, I run my alias for init:

git i

That’s the same as git init. Think of git init like flipping on a switch - you’re telling this folder, hey, we’re tracking changes now.

Curious what’s going on at any time? Run:

git status

Right now Git says there’s nothing to commit - because we haven’t added any files yet. So let’s create a file:

touch hello.md

Run git status again and you’ll see hello.md listed as an untracked file. That word matters. Untracked means Git sees the file, but it’s not being watched yet.

To get a file into the Git pipeline, you add it to the staging area. That’s your “set these aside for the next snapshot” zone. We’ll talk about that next.

The Staging Area Explained: git add For Single Files and All Changes

When you add files to the staging area, you’re basically telling Git: please keep this version safe for the next commit. It’s like placing items in a basket before you check out.

There are a few ways to add files. You can add everything at once:

git add .

Or you can be precise and add a specific file:

git add hello.md

Let’s make this realistic with a few files:

touch learning.py touch waiting.py

Now I’ll stage only one of them:

git add learning.py

If I run git status now, I’ll see that learning.py is staged, while waiting.py is still untracked in the working directory. That’s your quick snapshot of what’s prepared and what isn’t.

Here’s the part people miss. If you edit a file after you’ve staged it, those new edits are not automatically included. You have to add it again to stage the newer changes.

I’ll add some code to make this clear. In learning.py I type:

print("I'm learning git")

Then I run git status. Git now tells me that learning.py has been modified and has changes not staged for commit. To capture that new line of code, I run:

git add learning.py

In a normal day, you work inside your file until you’re happy, then use git add to set those changes aside. When everything in your basket looks right, you commit it. That’s the next step.

Commit With Confidence: git commit, Messages, and Tracking Versions

Committing is how you store a version of your project in Git history. It’s like saving a restore point with a short note to your future self.

Right now, learning.py and hello.md are staged, while waiting.py is untracked. I’ll commit what’s staged using a message:

git commit -m "initial commit"

When I run git status after this, Git tells me two files changed with one insertion. That makes sense. We added two files, and one of them has one line of code. It also reminds me that waiting.py is still untracked because we never staged it.

If I add more code to learning.py, and I’m ready to include everything - including waiting.py - I can stage all changes at once and commit with a clear message:

git add . git commit -m "add waiting file and new function"

That’s the rhythm you’ll use over and over: code, add, commit. It’s simple and powerful. Your history grows as a series of thoughtful snapshots - each one with a short message explaining the why.

When you write your commit message, aim for quick and clear. Think: what did I change and why does it matter? Future you - or your teammate - will thank you.

Collaborating The Right Way: git clone, Branches, git switch, and Live Edits in VS Code

Now let’s talk teamwork. If you’re handed a link to a remote repository and you need it on your laptop, you clone it. Cloning is just making a local copy of a remote repo.

On GitHub, go to the repository, click the green Code button, choose HTTPS, and click the copy icon to grab the URL. Then in your terminal:

git clone <paste-the-repo-url>

Once you see “done”, you’ve got a complete local copy you can work in. Change into the folder:

cd <repo-folder>

When working with a team, don’t commit directly to the main branch. Make a branch. It’s like making a copy of a document so you don’t mess up the original while you experiment.

Create and switch to a new branch in one step:

git checkout -b update-name

Want to see what branches exist?

git branch

Git shows something like: main, a branch named init, and your new update-name branch. If the output is long, press q to exit the view.

Need to go back to main? Use git switch:

git switch main

And to return to your branch:

git switch update-name

Now let’s open the project in VS Code and make a change you can actually see. Inside VS Code, open index.html. Right click on the file and choose Open Preview to see a live side-by-side preview of your edits.

Say your task is to change the app title to “git going”. Update the title in the HTML. Then in your terminal, check what changed:

git status

Git shows the file as modified. Perfect. Stage and commit those changes:

git add . git commit -m "update App name"

You just captured that update on your branch without touching main. Clean and safe.

Ship It and Stay In Sync: git push, Pull Requests, git pull, git show, and Cleaning Up Branches

You’ve got local commits and you’re ready to share. To upload your commits from your laptop to GitHub, you push them.

Here’s how I think about git push: thanks, Git, for tracking my changes locally - now please send these commits to the main project on GitHub so others can see them.

Use this format:

git push <remote> <branch>

For most repos, the remote is called origin, so on my update-name branch I run:

git push origin update-name

Head back to GitHub in the browser and you’ll see a new branch available. That’s why we call it push - you pushed your branch up.

Now open a pull request. A pull request is a proposal to merge your set of changes from one branch into another. In our case, merge update-name into main.

Click the green button to open a PR, add a short description of what you changed, and then click the merge button when it’s approved. In a real team, a coworker would review your work before you merge. For this walkthrough, we’ll go ahead and merge.

So now main is updated on the remote repository. But what about your local main?

Switch to your local main branch and open the same file in VS Code. You might notice the app title still says “todo”. Wait - what?

Here’s why. You updated the remote main branch, but your local main hasn’t been updated to match the remote version yet. Each branch has its own history in each place - local and remote. They aren’t automatically synced.

To bring your local main up to date with the remote main, run:

git pull

On your main branch, this fetches new commits from the remote and merges them into your local copy. You’ll see output like “1 file changed, 1 insertion, 1 deletion” which lines up with your title change.

At this point, you might want to quickly see exactly what changed in the last commit. My favorite command for that is git show. It prints details about the commit you’re on - author, date, commit ID (the SHA), the message, and the diff of the changes.

git show

This is a fast way to review history right in your terminal without clicking around. When I’m double checking what shipped, I run git show as a quick sanity check.

The GitHub Flow - Start to Finish

Everything we just did is what we call the GitHub Flow. It’s a branch based workflow for everyone, and you go through it anytime you work in a repository.

Here’s what we did, step by step:

• Cloned the repository to get a local copy.
• Created a new branch to safely make changes.
• Made changes on that branch and committed them.
• Pushed the branch to GitHub.
• Opened a pull request to merge into main.
• Reviewed and merged the PR.
• Pulled the latest changes into local main to stay in sync.

There’s one last clean up step. After you merge the PR, delete the branch so the repo stays tidy.

Delete the branch locally with:

git branch -d update-name

And delete it remotely with:

git push --delete origin update-name

That’s the finish line for this round of work. Clean, clear, and ready for the next task.

Putting It All Together: Your Everyday Git Commands, In Order

Let’s stitch the flow together so it becomes muscle memory. This is exactly how I work, from a fresh machine to collaborating with a team.

Set yourself up once

• Identify yourself so you get credit for your work:

git config --global user.name "Lady Kerr" git config --global user.email "ladycurmail.com" git config --global alias.i init

Start a brand new project

• Create a folder, initialize Git, and check your status:

mkdir project1 cd project1 git i git status

Add files and stage your work

• Create files and decide what to stage now vs later:

touch hello.md touch learning.py touch waiting.py git add learning.py git status

Edit learning.py, then stage the new edits:

# inside learning.py print("I'm learning git") git add learning.py

Commit clearly

• Commit what’s staged with a simple, helpful message:

git commit -m "initial commit" git add . git commit -m "add waiting file and new function"

Clone and branch when collaborating

• Copy a remote repo and work on a branch, not main:

git clone <repo-url> cd <repo-folder> git checkout -b update-name git branch # press q to exit if needed git switch main git switch update-name

Open the project in VS Code, preview index.html, and update the title to “git going”.

git status git add . git commit -m "update App name"

Sync your work

• Push your branch, open a PR, merge when approved:

git push origin update-name

After merging on GitHub, update your local main to match:

git switch main git pull git show

Clean up

• Delete merged branches locally and remotely:

git branch -d update-name git push --delete origin update-name

That’s the everyday rhythm. The more you practice it, the faster and smoother it feels.

Final Takeaways You Can Use Right Now

Git isn’t about memorizing a hundred commands. It’s about learning the handful you’ll use every day and understanding how they fit together.

Start by identifying yourself with git config. Initialize with git init. See what changed with git status. Stage work with git add. Lock it in with git commit. Collaborate using git clone, branches, and git switch. Share with git push, merge through pull requests, then stay synced with git pull and confirm with git show. When you’re done, clean up branches locally and on the remote.

You just walked through the full GitHub Flow - cloning a repo, creating a branch, making changes, pushing, opening a pull request, merging, pulling updates, and deleting the branch.

Practice these commands and you’ll feel fully equipped to work with Git like a professional. Happy coding.