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

Let's see how well you understood the concepts! These exercises will help reinforce what you just learned.

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?