Git hands-on: status, staging, commits and history
Every Git change follows the same loop: change files, look at git status and git diff, stage exactly what belongs to the change with git add, record it with git commit, and read the history with git log. A .gitignore file keeps compiler listings and build output out of the repository.
Getting a repository
git init creates a new, empty repository: a .git folder that will hold the history. On a team you usually start with git clone instead: it copies an existing repository with its whole history into a new folder, names the source origin, creates remote-tracking branches such as origin/main, and checks out the default branch.
The loop, on a real change
$ git status On branch main nothing to commit, working tree clean (edit src/PAYCALC.cbl in VS Code) $ git status -s M src/PAYCALC.cbl ?? src/PAYCALC.lst $ git diff ... shows the changed lines with - and + ... $ git add src/PAYCALC.cbl $ git diff --staged $ git commit -m "Pay overtime after 40 hours, not 38 (PAY-2231)" [main 3c1e9a0] Pay overtime after 40 hours, not 38 (PAY-2231) 1 file changed, 1 insertion(+), 1 deletion(-)
git status names the branch and lists three kinds of path: staged for the next commit, changed but not staged, and untracked (??). Staging is a deliberate step: the staging area (the index) holds exactly what the next commit will contain, so you can commit the COBOL change without the stray listing.
Two kinds of difference
| Command | Compares | Use it to |
|---|---|---|
| git diff | your files with the staging area | see what you have not staged yet |
| git diff --staged (same as --cached) | the staging area with the last commit | check what you are about to commit |
| git diff main feature/x | two commits or branches | see what a branch changes |
Commits and history
git commit -m "..."records the staged content with your message.git commit -aalso stages files Git already tracks that you changed or deleted, but never new files.- Write the message as a short summary of what and why, and include the ticket number your team uses.
git log --onelineshows one line per commit, newest first; add-n 5to limit it,--allto include every branch, or a range such asmain..feature/xfor the commits on feature/x that main does not have.git show <commit>shows one commit and its changes.git restore <file>throws away an unstaged change;git restore --staged <file>unstages a file and keeps your edit.
Keeping generated files out: .gitignore
A .gitignore file lists files that should never be tracked: one pattern per line, # for comments, * matching anything except a slash, and a trailing / matching only folders. Ignore rules do not affect files Git already tracks: if a listing was committed by mistake, untrack it with git rm --cached and then rely on the ignore rule.
# compiler listings and local build output *.lst build/ # editor backups *.bak
Which command shows the changes you have already staged for the next commit?
Show a hint
git diff with an option.
Show the solution
git diff --staged (or --cached).
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
It stages listings and stray files too. Run git status first and add files by name, or keep a good .gitignore.
Ignore rules only apply to untracked files. Use git rm --cached on the file, then commit.
Say what changed and why, with the ticket: the history is how the next person understands the code.
What you will see at work
- Teams often refuse commits without a ticket number; some pipelines check the message.
- Before every commit, experienced developers read git diff --staged once more. It catches debug DISPLAY statements and wrong files.
- When an incident starts, git log on the failing program is one of the first things people look at: what changed, when, and by whom.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.