The lifecycle of a change

Beginner Core Git Git CLI ≈ 10 min

Before this lesson

The four areas

What you will learn

The order of the everyday commands and why the order matters
Which steps only look and which steps change something
Where fetch and pull fit, and why pulling before pushing avoids most rejected pushes

After this lesson you can

I can run the whole loop from memory on the playground
I know which command to run when something looks wrong at each step

Why this matters

There are more than a hundred Git commands. The everyday loop uses eight, always in the same order. Learn the loop as one movement, and Git becomes a routine rather than a puzzle; the rest of the course adds branches and teamwork on top of it.

The loop

The eight steps of the everyday loop, and the areas each one reads or changes.

git clone (once) or git init (once). Get a repository onto your computer: cloning copies an existing one from the remote; init starts a new one from a folder. From then on you never do this step again for that project.
Edit. Change files in your editor. Only the working tree changes. This is the step Git is not involved in at all.
git status. Look. Which files changed, which are staged, which are untracked, is the branch ahead or behind. Free, always safe, run it constantly.
git diff. Read the actual lines you changed. Catch the typo, the debug print, the accidental edit in the wrong file. Also free and safe.
git add <file>. Choose what goes into the next commit. Repeat for each file, or git add . for everything after reading the status.
git diff --staged. Read exactly what the commit will contain. The last chance before it exists.
git commit -m "…". Record the snapshot in the local repository with a message.
git fetch or git pull. Bring in what the team pushed since your last sync. Pull merges it into your branch; fetch only downloads so you can look first (lesson 7.5).
git push. Send your commits to the remote. Now the team and the pipeline see them.

Then back to step 2. A working day is this loop repeated: edit, look, stage, commit, and sync at the natural pauses.

What happens inside at each step

Step	Inside Git
clone	Downloads every commit into `.git`, creates the working tree from the newest one, sets `origin`
edit	Nothing; the file on disk now differs from the staging area
status	Compares last commit, staging area and working tree; prints the differences
diff	Prints the line differences between working tree and staging area (or, with `--staged`, staging area and last commit)
add	Copies the file's current content into the staging area (`.git/index`)
commit	Writes a snapshot of the staging area plus author, date, message and parent into `.git/objects`; moves the current branch label to it
fetch	Downloads new commits and updates `origin/main`; touches no files of yours
pull	fetch, then merges `origin/main` into `main`, updating the working tree
push	Uploads commits the remote does not have; moves the remote's branch label

Where things go wrong, and which step fixes them

Symptom	Step that answers it
"Did I change anything?"	3, `git status`
"What exactly did I change?"	4, `git diff`
"The commit contains the wrong files"	6, `git diff --staged` before committing
"`git commit` says nothing to commit"	5, you skipped `git add`
"Push was rejected (non-fast-forward)"	8 before 9: pull first, then push
"My colleague's change is missing"	8, fetch or pull
"The pipeline did not run"	9, push

Two rhythms

While learning: run every step, every time, and read every output. Status and diff cost seconds and teach you what the other commands did.
Once comfortable: status → add → commit becomes one gesture; diff --staged stays for anything non-trivial; pull before you start work and before you push; push at every natural pause.

Common mistakes

Committing without looking. git add . followed immediately by git commit is how secrets and generated files enter history. Status first.
Pushing without pulling. Works while you are the only one pushing; fails as soon as a colleague pushed. Pull first is a habit worth building on day one.
Pulling with a dirty working tree. If the incoming changes touch files you edited, Git stops. Commit or stash first, or accept the merge conflict lesson early.
Treating fetch and pull as the same. Fetch looks; pull changes your files.

Try it yourself

Goal: run the whole loop once, in order, on the playground (steps 1 and 8–9 need the remote from Lab 2; skip them if you have none yet).

Edit docs/faq.md: change one word in an existing answer.
git status, then git diff.
git add docs/faq.md, then git diff --staged.
git commit -m "docs: reword an FAQ answer".
If you have a remote: git pull, then git push, then git status.

Expected result: git diff shows one - line and one + line; after staging, git diff --staged shows the same; the commit reports 1 file changed, 1 insertion(+), 1 deletion(-); after pushing, status says up to date.

Show solution

Changing one word shows as one removed line and one added line, because Git compares whole lines. 1 insertion(+), 1 deletion(-) in the commit summary confirms it. If git push is rejected, someone (or an earlier you, on another clone) pushed first: git pull, then push again.

Check yourself

1. Which of these steps can you repeat as often as you like without changing anything? git add and git commit git status and git diff git pull and git push

2. git commit answers no changes added to commit. Which step did you skip? git diff git push git add

3. Why pull before pushing? If a colleague pushed first, your push is rejected until you integrate their commits Pushing deletes local changes otherwise Pull is required by GitLab

Key terms

Clone Commit Fetch Pull Push Diff