Track a first change

What you will be able to do

Save your work as small, named steps, and see exactly what changed in each step. This is the main thing that you do with Git every day.

Before you startWhat to know and to have readyAbout 30 minutes

What you need to know

• What a repository is, from Set up Git: A repository is a folder with a history.
• What git status shows, from Set up Git: Step 3: make a repository.

What you need on your computer

• Git, with your name and email address. You set them in Set up Git: Step 2: tell Git who you are. To check them, run git config --global --list.

• The empty repository ~/projects/ticket-notes. You made it in Set up Git: Step 3: make a repository. In it, git status shows No commits yet. If the folder is missing, do that step again.

• If the repository is missing or broken, a script can make the start state of this lesson again. In ~/projects, run:

  git clone https://github.com/Nextia-Intelligence/nextia-learning-labs.git
  sh nextia-learning-labs/C14/setup.sh m01-l03 --reset

  Run the git clone command only once. If you already have the nextia-learning-labs folder, run git -C nextia-learning-labs pull instead. Pull-request sequence: Set up the practice lab explains the script in full. The script makes ~/projects/c14-lab/ticket-notes: an empty repository on main, with no commits and no remote. Then use ~/projects/c14-lab in place of ~/projects in this lesson. --reset deletes an older c14-lab folder first, but your ~/projects/ticket-notes does not change.

• A text editor, for example Visual Studio Code. Any editor that saves plain text works. To open a terminal in your editor, see Terminal bridge: Open a terminal from your editor.

Three places for your changes

Git does not save every edit automatically. You choose what to save, and when. To do this, Git keeps your changes in three places:

1. The working tree is the files in your project folder, as you see them in your editor. When you edit a file, you change the working tree.
2. The staging area is a list of the changes that go into your next save. You put a change there with git add.
3. The commit history is the list of saved steps. You save the staging area as a new step with git commit.

A commit is one saved step. It is a snapshot of the project, with a message that says why you made the change. Git also records the author, the date, and an ID for the commit.

A change moves from the working tree to the staging area with git add, then into the history with git commit.

Why have a staging area? It lets you choose. You can edit five files, then save two of them as one commit and three as another. Each commit then contains one clear change, which is easier to review and to undo.

Worked example: Amira’s first commit

Amira is in ~/projects/ticket-notes. She makes a file called README.md in her editor, with this text:

README.md

# Ticket notes

Notes about support tickets.

She saves the file, and asks Git for the state of the repository:

Terminal

git status

Output

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
  README.md

nothing added to commit but untracked files present (use "git add" to track)

README.md is untracked: it is in the working tree, but Git does not track it yet. She adds it to the staging area, and checks again:

Terminal

git add README.md
git status

Output

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
  new file:   README.md

The file is now under “Changes to be committed”. This is the staging area. Next, she saves it as a commit. The -m option gives the message:

Terminal

git commit -m "Add README"

Output

[main (root-commit) 763ec59] Add README
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

The output shows the branch (main), a short ID (763ec59) and the message. root-commit means that this is the first commit in the repository. To see the history, she runs git log:

Terminal

git log

Output

commit 763ec59e42a90d5d11f064bc677d31b91bfc4e39 (HEAD -> main)
Author: Amira Khan <amira@example.com>
Date:   Mon Oct 5 20:31:22 2026 -0400

    Add README

The long text after commit is the commit hash: an ID that Git calculates from the contents of the commit. No two commits have the same hash. Git usually shows only the first seven characters, for example 763ec59. Your hash is different, because your commit has a different author and time.

Worked example: see a change before you save it

Amira changes the last line of README.md to Notes about support tickets for the help desk. She also makes a new file, tickets.txt:

tickets.txt

Ticket 101: printer offline. Restarted the spooler.

Now she has two changes. To see a short summary, she uses git status --short:

Terminal

git status --short

Output

 M README.md
?? tickets.txt

To see the exact change in README.md, she uses git diff. A diff shows the lines that changed:

Terminal

git diff

Output

diff --git a/README.md b/README.md
index 8f872d3..a30ec45 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
 # Ticket notes

-Notes about support tickets.
+Notes about support tickets for the help desk.

Read a diff like this:

• A line that starts with - was removed. A line that starts with + was added. A changed line shows as one of each.
• Lines with no sign did not change. Git shows them so that you can see where the change is.
• @@ -1,3 +1,3 @@ gives the line numbers: lines 1 to 3 in the old file, and lines 1 to 3 in the new file.

git diff does not show tickets.txt, because Git does not track that file yet. git diff only compares tracked files.

Amira wants two commits: one for the README change and one for the ticket. She stages only the README:

Terminal

git add README.md
git status --short

Output

M  README.md
?? tickets.txt

The M moved from the second column to the first column. The two columns are the most useful part of git status --short:

Code	First column: staging area	Second column: working tree
M	The change is staged. It goes into the next commit.	No other changes.
M	Nothing is staged.	The file changed, and the change is not staged.
MM	A change is staged.	The file changed again after you staged it.
??	The file is untracked.	The file is untracked.
A	A new file is staged.	No other changes.

git diff shows unstaged changes only. Now that the README change is staged, she uses git diff --staged to see what the next commit will contain. The output is the same diff as before. Then she makes two commits:

Terminal

git commit -m "Describe who the notes are for"
git add tickets.txt
git commit -m "Add first ticket note"
git log --oneline

Output

d8ae027 (HEAD -> main) Add first ticket note
49397ba Describe who the notes are for
763ec59 Add README

git log --oneline shows one commit on each line, newest first. (HEAD -> main) marks the commit that you are on now. You learn what this means in the next module.

Note

A commit message is not the change. The message is what the author says about a change. The hash identifies the change itself. Before you trust a message, look at the change: git show 49397ba shows the message and the full diff of that commit.

Guided practice: make your first commits

Do the worked example in your own ticket-notes repository. After each command, compare your output with Amira’s.

1. Check that you are in the repository:

   cd ~/projects/ticket-notes
   git status

   The output shows No commits yet.

2. In your editor, make README.md with the three lines from the first worked example. Save the file.

3. Run git status. README.md is under “Untracked files”.

4. Stage the file:

   git add README.md

5. Run git status. README.md is under “Changes to be committed”.

6. Commit it:

   git commit -m "Add README"

   The output starts with [main (root-commit).

7. Run git log --oneline. The output shows one commit.

8. Change the last line of README.md, and make tickets.txt with one ticket note. Save both files.

9. Run git status --short. The output shows M README.md and ?? tickets.txt.

10. Run git diff. The output shows one - line and one + line.

11. Stage and commit the README change:

    git add README.md
    git commit -m "Describe who the notes are for"

12. Stage and commit the ticket note:

    git add tickets.txt
    git commit -m "Add first ticket note"

13. Run git log --oneline. The output shows three commits. Run git status. The output says nothing to commit, working tree clean.

Your turn: two commits, then inspect them

Make two more commits in ticket-notes, one for each change:

1. Add a second ticket note to tickets.txt.
2. Add a new file, contacts.txt, with the name of a help desk team.

Then, for each of your two new commits, use git show --stat to see which files it changed. Get the short hashes from git log --oneline, and use yours instead of d8ae027:

git show --stat d8ae027

Output (end)

 tickets.txt | 1 +
 1 file changed, 1 insertion(+)

Each of your commits must change only one file. If a commit changed both files, you staged both before you committed. You learn to undo a commit in Module 4. For now, make one more change to each file, and commit them separately.

Common mistake

Git opens a strange editor

Symptom: you run git commit without -m. The terminal fills with a text screen, and the keys do not act as you expect. The bottom line can show ~ characters, or the name of an editor such as Vim or nano.

Cause: Git needs a commit message. When you do not give one with -m, Git opens a text editor so that you can type it. The default editor on many systems is Vim, which works differently from other editors.

Fix: leave the editor without saving. Git then cancels the commit.

1. In Vim: press Esc, type :q!, then press Enter.
2. In nano: press Ctrl+X. If nano asks to save, press N.

Git shows Aborting commit due to empty commit message. Your staged changes stay staged. Run the commit again with -m "your message".

Common mistake

Nothing added to commit

Symptom: you run git commit -m "Add ticket", and Git shows nothing added to commit but untracked files present, or no changes added to commit.

Cause: the staging area is empty. You edited files, but you did not run git add, so Git has nothing to save.

Fix: run git status to see your changes. Run git add for each file that you want in the commit. Then commit again.

Check your understanding

Predict: Amira stages tickets.txt with git add. Then she adds one more line to tickets.txt and saves it. What does git status --short show? What goes into her next commit?

Show the answer

It shows MM tickets.txt. The first M is the staged change. The second M is the newer change in the working tree, which is not staged. The next commit contains only the staged version: the file as it was when she ran git add. To include the new line, she must run git add tickets.txt again.

Check your understanding

Practical check: for each file in this git status --short output, say if its change is unstaged, staged, or untracked: 'M README.md', ' M contacts.txt', '?? notes.txt'.

Show the answer

• README.md: staged. The M is in the first column. It goes into the next commit.
• contacts.txt: unstaged. The M is in the second column. Git tracks the file, but this change is not in the staging area.
• notes.txt: untracked. Git does not track this file yet.

A change that is already committed does not appear in git status. You see it with git log and git show.

Recap

• Changes move from the working tree to the staging area with git add, then into the commit history with git commit.
• git status and git status --short show where each change is. git diff shows unstaged changes, and git diff --staged shows staged changes.
• A commit hash identifies a commit. git show <hash> shows what the commit really changed.
• Stage only the changes that belong together, so each commit is one clear step.

This is the end of Module 1. In Module 2, you work on a separate line of changes with branches, and share your work with a remote.