Predict what your next commit will contain

• Distinguish the working tree, index and last recorded commit.
• Predict what staging, editing and a normal commit change.
• Read both columns of short status without assuming that staged means saved forever.
• Use separate comparisons for unstaged and staged changes.

Read lesson 1 first; lesson 2 prepares Git and your commit identity. You start with no course repository and you finish without one: this is a concept lesson. The first hands-on initialization is lesson 4, inside GitTree.

This lesson previews four states you will create yourself in lesson 5. The terminal outputs below, and the GitTree screens in the video, come from a disposable copy of the future project: the commands and screens were recorded with Git 2.52.0 and GitTree 2.0 on Ubuntu 24.04. They were not run on macOS. Every such scene in the video is labelled “Future lesson 5 preview”. Do not run the future-state commands in an unrelated work repository or initialize an extra practice repository now; watch and read the preview, then repeat the queries when lesson 5 reaches those states.

GitTree's inspected minimum is Git 2.39.0. On macOS, press Command where Windows and Linux use Ctrl. The commands were not run on Windows. No provider, account, Pro or trial is needed for the local model.

Your working tree is the project files on disk. Editing and saving a file changes those bytes. Git has not necessarily selected them for a commit.

The index, also called the staging area, describes the next snapshot you are preparing. Staging a file updates its index entry from its current contents. It is not a permanent subscription to later edits.

A commit records a tree plus metadata and parent relationships. HEAD identifies your current position, usually through the checked-out branch. Before the first commit, HEAD can name an unborn branch even though no branch commit exists.

A useful analogy is a working draft, a prepared edition, and a recorded edition. Do not take the analogy literally: staging does not move or delete the working file. In a normal tracked path, the three versions can agree or differ independently.

We use a normal commit of the prepared index, without -a, explicit path arguments, automatic staging or amend. Other commit modes are not interchangeable with this example. Git's add reference explains the snapshot-at-staging behavior; the diff reference distinguishes the comparisons.

The exact future example

The file is index.html. Its title stays Understand every change. Its supporting line has two versions:

<p id="hero-copy">A clear view of Git history.</p>

Later working edit:

<p id="hero-copy">Choose one change, then check what Git saved.</p>

These are line excerpts from the full original page and the full edited page of the project, not replacement files to paste over the full page.

The full project also contains a README. Both files are staged before the first commit; status examples are restricted to index.html. In D, the README is clean and index.html keeps its deliberate unstaged edit.

For the normal non-conflict rows here, short status's first column compares index against HEAD; the second compares working tree against index. ?? is the special untracked marker, not two ordinary modification columns. A leading space in M matters.

What changes

• Stage: updates index content; no commit or branch movement, no working-file rewrite.
• Edit after staging: updates working bytes only; the prepared index remains the earlier version.
• Normal commit: records the prepared snapshot and updates the current local branch. The index remains that snapshot; unrelated later working edits remain.
• Remote: none of these local steps pushes, fetches or creates a remote-tracking ref. This example has no remote.

The index is more than a list of names. Advanced conflicts can hold multiple index stages; we are modeling ordinary stage-zero file entries here, not unresolved merges.

Do not execute these in the still-uninitialized learner project. They were run in a disposable copy that held the full README and both versions of the page. Lesson 5 supplies the real creation and staging steps.

At future state C, inspect the two versions

git status --short -- index.html

Observed:

AM index.html

Read the prepared file directly:

git show :index.html

Observed full output:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">A clear view of Git history.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

Compare working tree against index:

git diff -- index.html

Observed:

diff --git a/index.html b/index.html
index 5470374..27f8718 100644
--- a/index.html
+++ b/index.html
@@ -13,7 +13,7 @@
     <section class="hero" aria-labelledby="hero-title">
       <p class="eyebrow">GitTree Learn demo project</p>
       <h1 id="hero-title">Understand every change.</h1>
-      <p id="hero-copy">A clear view of Git history.</p>
+      <p id="hero-copy">Choose one change, then check what Git saved.</p>
     </section>
   </main>
   <footer><p>Built by a fictional team for GitTree Learn.</p></footer>

The object abbreviations above are actual file-blob IDs from these exact LF file bodies, not invented commit SHAs. Your abbreviation length/output can differ with configuration.

Inspect the staged addition, relative to the empty history before the first commit:

git diff --cached --stat -- index.html

Observed:

 index.html | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

--stat summarizes; it is not a content review. The full staged snapshot is the earlier file shown by git show :index.html.

At future state D, check what was recorded

After lesson 5's normal commit of the prepared index:

git log -1 --format=%s
git status --short -- index.html
git diff --cached -- index.html

Observed first two outputs, in order:

feat: add the GitTree Features hero
 M index.html

The third command prints no output and exits successfully: index and HEAD agree for this path. It does not mean the working tree is clean. The working diff still shows the supporting-line edit above. This is a common reason “the commit missed my latest edit” is actually correct Git behavior.

In your current no-repository context

1. Keep New Tab open, using Command+T / Ctrl+T (tab.new) if needed.
2. Open Feature Guide with Option+H on macOS or Alt+H elsewhere, or open Command Palette… with Command+Shift+P / Ctrl+Shift+P and choose Feature Guide.
3. In Features, type stage into Search features and read Stage and commit. Do not run an initialization action. The card is an orientation, not proof of a staged file.
4. Press Escape to close the guide. Your course repository still does not exist.

The same states in GitTree (shown in the video)

The video opens a disposable copy of the future project in GitTree, labelled “Future lesson 5 preview”. It is not your project and not a recording of your work.

1. At C, open Command Palette…, type Show Working Changes, and choose that exact command (wip.show). There is no default shortcut asserted for this command.
2. Inspect the right-hand panel's Unstaged Files and Staged Files. index.html appears in both because it has two different comparisons; it is not two physical files.
3. Click its row in Unstaged Files. Expect the center diff to show the original page changing to the edited page, including the supporting-line change.
4. Click its row in Staged Files. Expect the staged addition, containing the earlier supporting line. Merely inspecting either row does not stage or unstage anything.
5. At D, after the normal commit, the graph has the first commit; Staged Files says Nothing is staged. A commit contains only staged changes. The working edit remains under Unstaged Files.
6. Do not click Stage File, Unstage File, Stage All Changes or Discard Changes… in this concept preview. Dedicated creation and commit instructions follow in lessons 4 and 5.

You can predict D from C: the first commit records the earlier supporting line, while the later working edit remains. Your own project stays in the no-repository state. The future project's graph is an explicitly labelled preview, not your completed work.

• “Staged means all future edits are included.” It means the index contains a selected version at that point.
• “Empty cached diff means no edits.” It says index and HEAD agree for the selected path; inspect the working diff too.
• “Two lists mean two files.” They are two comparisons for the same path.
• “A staged file is safely committed.” The index is mutable; it is not durable history or a backup.
• “Commit means remote update.” There is no remote in this example and no push occurs.

If you run a repo query now and get “not a git repository,” keep the lesson checkpoint intact and read the preview. Do not create a second repository to make an example command succeed.

If your own project later shows a different status, inspect the selected path before trying to repair it. Did you stage again after the edit? That changes the prepared snapshot and therefore the predicted commit. Did you use an automatic-stage command? That is a different operation from the normal index-only commit here.

At this stage we recover by identifying the right comparison, not destroying content. Lesson 5 shows safe staging decisions, and the recovery path teaches scope-checked Undo and reflog. GitTree trash snapshots are not a promise that every arbitrary editor save is recoverable.

Answer each question, then read why. Questions marked “Required” count toward completing the lesson.

1. Question 1 of 6

   Question 1 of 6

   Which snapshot supplies the normal commit modeled here?

   Choose one answer.

   Always the latest editor buffer

   The remote provider

   The prepared index

   Check answer
2. Question 2 of 6

   Question 2 of 6

   At C, what changed because of the post-staging edit?

   Choose every answer that applies.

   No remote refs change

   Working index.html now has the newer line

   Local main advances to a commit

   Index automatically gains the newer line

   Check answer
3. Question 3 of 6

   Question 3 of 6Required

   At C, commit the index without staging again. Which line is recorded?

   Choose one answer.

   A clear view of Git history.

   Choose one change, then check what Git saved.

   Both lines in two physical files

   Check answer
4. Question 4 of 6

   Question 4 of 6Required

   Start at C, stage the edited version, then commit. What changes?

   Choose one answer.

   A remote push happens automatically

   Old line still records because the first stage is permanent

   Newer line is recorded; no remaining difference for this path

   Check answer
5. Question 5 of 6

   Question 5 of 6

   At D, cached diff is empty but status is space then M. Why?

   Choose one answer.

   Git lost the working edit

   Every file is clean

   HEAD and index agree; working tree differs

   Check answer
6. Question 6 of 6

   Question 6 of 6Required

   follow A → B → C, then make the normal commit of the index. Which observations prove D?

   Choose every answer that applies.

   Commit and index contain the original page

   Short status for the file is space then M

   Working file contains the edited page

   The learner now has a real initialized repository

   Check answer

Before lesson 5, predict on paper: stage a file, edit it after staging, then commit normally. Which supporting line is recorded, and where does the later edit remain? Then change the sequence: stage the edited file again before committing. Now the recorded line should be the newer one, with no remaining working difference. The video shows both routes with real output; you will check both yourself in lesson 5.

• Working files, the index and recorded history are different snapshots.
• Staging captures the chosen contents; later edits do not update it automatically.
• Inspect both comparisons and do not mistake a local commit for a remote action.

• Install Git and preview your commit identity (lesson 2)
• Distinguish Git, GitTree and your hosting provider (lesson 1)
• Download GitTree

Working tree — مجلد العمل; staging area / index — منطقة التجهيز / الفهرس; commit — إيداع; ref — مرجع; untracked — غير مُتتبَّع; staged — مُجهَّز. HEAD remains the literal technical identifier.