Learn the everyday Git loop with init, clone, status, add, commit, log and diff, understand the staging area and build checks to run before every commit.
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:
Tip: Git becomes much easier when you think in stages: working directory, staging area, and commit history.
Use git init when you want to begin tracking a folder that is not yet a repository.
This creates a hidden .git directory that stores repository metadata and history.
Check Git’s view of the folder:
Git will tell you that README.md is untracked, which means Git sees the file but is not yet including it in history.
mkdir notes-app
cd notes-app
git initUse git clone when a repository already exists somewhere else, such as GitHub.
A clone downloads the full repository history, not just the latest files. That is one of the strengths of Git’s distributed model.
git clone https://github.com/example/devops-notes.git
cd devops-notesgit status is one of the most useful commands for beginners because it tells you what is happening right now.
Run it often. It reduces mistakes because you see exactly what Git is about to include or ignore.
git statusThe staging area lets you choose what goes into the next commit.
Stage multiple files:
Stage everything changed in the current directory:
You should now see those files listed under “Changes to be committed.”
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.
git add README.mdA commit records a snapshot of staged changes.
Later, after editing app.js:
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.
git commit -m "Add project README"Use git log to inspect commit history.
A shorter, more readable version is often:
This helps you quickly scan commit IDs and messages, especially in small projects.
A history might look like this:
That tells you the order of changes and gives you commit IDs you can use in other commands.
git loggit diff shows what changed.
To compare unstaged changes in your working directory:
To compare staged changes that are ready to commit:
This is important because it lets you review your work before creating a commit.
Edit README.md, then run:
Now check the staged version:
This helps confirm that the exact changes you want are going into history.
git diffHere is a full beginner-friendly workflow:
This sequence covers the core loop you will use every day.
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 --onelineIf you skip git status, you may commit extra files or miss important ones.
Messages like update stuff are not helpful later. Prefer messages such as Add health check endpoint or Fix typo in deployment guide.
git add . is convenient, but be careful. Always review with git status or git diff --staged.
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.
Scenario: You created a new notes-app folder and want Git to begin tracking it.
Question: What does git init do in that situation?
Identify what git init creates when you start tracking a folder.
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?
Choose the command that stages only the file you want in the next commit.
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?
Pick the command that compares staged changes before the commit is created.
Learn what a Git branch really is, git switch versus checkout, how HEAD and detached HEAD work, and how to delete, rename and name branches well.
Learn git merge: fast-forward versus three-way merges, resolving conflict markers step by step, --no-ff and squash merges, and aborting a bad merge.
Use git rebase for a linear history: basic and interactive rebase, squashing, recovering with --abort and reflog, force-with-lease, and when to merge instead.