Git Basics

The Everyday Git Workflow

Most Git work follows a simple loop: create or update files, inspect changes, stage what you want, commit it, and review history. If you understand that cycle, you can already be productive.

The most common commands are:

• git init
• git clone
• git status
• git add
• git commit
• git log
• git diff

Tip: Git becomes much easier when you think in stages: working directory, staging area, and commit history.

Starting a Repository with git init

Use git init when you want to begin tracking a folder that is not yet a repository.

mkdir notes-app
cd notes-app
git init

This creates a hidden .git directory that stores repository metadata and history.

Now create a file:

echo "# Notes App" > README.md

Check Git’s view of the folder:

git status

Git will tell you that README.md is untracked, which means Git sees the file but is not yet including it in history.

Copying an Existing Repository with git clone

Use git clone when a repository already exists somewhere else, such as GitHub.

git clone https://github.com/example/devops-notes.git
cd devops-notes

A clone downloads the full repository history, not just the latest files. That is one of the strengths of Git’s distributed model.

Checking State with git status

git status is one of the most useful commands for beginners because it tells you what is happening right now.

git status

It can show:

• untracked files
• modified files
• staged files ready to commit
• which branch you are on

Run it often. It reduces mistakes because you see exactly what Git is about to include or ignore.

Staging Changes with git add

The staging area lets you choose what goes into the next commit.

Stage one file:

git add README.md

Stage multiple files:

git add app.js package.json

Stage everything changed in the current directory:

git add .

After staging, run:

git status

You should now see those files listed under “Changes to be committed.”

Why Staging Is Useful

Suppose you updated README.md and also changed app.js, but only the documentation is ready. Staging lets you commit the README change alone instead of mixing unrelated work into one commit.

Saving Work with git commit

A commit records a snapshot of staged changes.

git commit -m "Add project README"

Later, after editing app.js:

git add app.js
git commit -m "Add startup message to app"

Good commit messages are short but meaningful. They should explain what changed in a way future teammates can understand.

Note: A commit only includes staged files. If you forget to stage something, it will not be part of that commit.

Seeing History with git log

Use git log to inspect commit history.

git log

A shorter, more readable version is often:

git log --oneline --decorate

This helps you quickly scan commit IDs and messages, especially in small projects.

Real Example

A history might look like this:

c92f31a Add startup message to app
7ab13b2 Add project README

That tells you the order of changes and gives you commit IDs you can use in other commands.

Comparing Changes with git diff

git diff shows what changed.

To compare unstaged changes in your working directory:

git diff

To compare staged changes that are ready to commit:

git diff --staged

This is important because it lets you review your work before creating a commit.

Example Workflow

Edit README.md, then run:

git diff

Stage it:

git add README.md

Now check the staged version:

git diff --staged

This helps confirm that the exact changes you want are going into history.

Putting It All Together

Here is a full beginner-friendly workflow:

mkdir hello-git
cd hello-git
git init
echo "console.log('Hello, Git')" > app.js
git status
git add app.js
git commit -m "Create initial app file"
echo "console.log('Version 2')" >> app.js
git diff
git add app.js
git commit -m "Update app output"
git log --oneline

This sequence covers the core loop you will use every day.

Common Beginner Mistakes

Committing Without Checking Status

If you skip git status, you may commit extra files or miss important ones.

Using Vague Commit Messages

Messages like update stuff are not helpful later. Prefer messages such as Add health check endpoint or Fix typo in deployment guide.

Staging Everything Automatically

git add . is convenient, but be careful. Always review with git status or git diff --staged.

What You Should Remember

Git basics revolve around a small set of commands. git init or git clone gets you started. git status shows the current state. git add prepares changes. git commit saves them. git log reviews history. git diff shows what changed.

If you build the habit of checking status and reviewing diffs before committing, you will avoid many beginner mistakes.

Test Your Understanding

Exercise 1: Starting a repository

Scenario: You created a new notes-app folder and want Git to begin tracking it.

Question: What does git init do in that situation?

Exercise 2: Selective staging

Scenario: You changed both README.md and app.js, but only the documentation is ready to commit.

Question: Which command best matches the staging workflow described in the lesson?

Exercise 3: Reviewing the staged version

Scenario: You ran git add README.md and want to confirm the exact staged content before committing.

Question: Which command from the tutorial shows that staged diff?

---

Frequently Asked Questions

What is the difference between git add and git commit?

git add moves changes into the staging area, which is a draft of your next commit. git commit records whatever is staged as a permanent snapshot in history. The two-step design is the point: you can edit ten files and commit them as three logical commits by staging selectively, which makes history readable and reverting precise. git add -p takes this further, letting you stage individual chunks within a single file.

What is the difference between git init and git clone?

git init turns an existing directory into a new repository with no history and no remote. You use it once, when starting something from scratch. git clone <url> copies an existing remote repository, bringing its full history and automatically configuring origin so git push and git pull work immediately. If you init when you meant to clone, you end up with an empty repository and have to add the remote by hand with git remote add origin <url>.

How do I see what changed before committing?

git diff shows changes you have not staged, and git diff --staged shows what you have staged, that second one is the real pre-commit review, because it is exactly what the commit will contain. git status gives the file-level overview of both. A useful habit is git diff --staged immediately before every commit; it catches stray debug statements and accidentally staged files more reliably than any hook.

How do I unstage a file I added by mistake?

git restore --staged <file> removes it from the staging area while keeping your edits in the working directory. The older equivalent is git reset HEAD <file>, which you will still see in documentation and which does the same thing. If you want to discard the edits as well, git restore <file> does that, and it is not recoverable, since those changes were never recorded anywhere, so check git diff first.

What does git log show and how do I make it readable?

By default it prints every commit with full hash, author, date and message, which is a lot of screen for little information. git log --oneline gives one commit per line, and git log --oneline --graph --all --decorate adds the branch structure, which is the single most useful way to understand what state a repository is in. git log -p <file> shows the actual changes to one file over time, and git log --since="2 weeks ago" narrows the range.

Why does git commit open an editor, and how do I avoid it?

Because no message was supplied, so Git asks for one. Passing -m "your message" writes it inline and skips the editor, which is what most people use day to day. If the editor opens and you are stuck in Vim, :wq saves and :q! aborts the commit. Set something you know with git config --global core.editor "code --wait" for VS Code or "nano" for nano. Reserve the editor for commits that deserve a body explaining why, which -m makes awkward.