Skip to content
GitTree

Video: Predict what your next commit will contain

The video plays in YouTube’s player, in privacy-enhanced mode.

Separate the files you are editing from the snapshot prepared for a commit and from recorded history. Use the future GitTree Features hero to explain why one file can be both staged and modified.

Read the full lesson

The article has every step and command from the video, the practice exercise and the questions.

Go to the lesson

Video transcript

The narration of the video, cue by cue.

  1. Predict the commit by separating working files, the index and history.
  2. This is a future project preview. Your own repository is not created yet.
  3. Use three labeled snapshots, not a file moving between boxes.
  4. The working tree contains the files you edit and save on disk.
  5. The index describes the snapshot you are preparing for a commit.
  6. A commit records a snapshot, metadata and its relationship to earlier history.
  7. Before the first commit, the branch has a name but no recorded tip yet.
  8. Staging selects current contents, not later edits, without moving the file.
  9. Our future hero begins with this supporting line.
  10. At A, the file exists only in the working tree and is untracked.
  11. Stage the demo files. The index now holds the original hero.
  12. Edit after staging. The working file changes, but the index stays earlier.
  13. Without staging again, which supporting line would a normal commit record?
  14. It records the prepared line, not the later working edit.
  15. Short status shows two different comparisons for the same path.
  16. Here, A is the staged addition; M is the later working modification.
  17. Read the prepared file directly from the index.
  18. The index still contains the earlier supporting line.
  19. The ordinary diff compares the working file with its prepared version.
  20. Before the first commit, the cached summary describes the staged new file.
  21. Now inspect the same state in a real GitTree recording.
  22. Open Show Working Changes through the command palette.
  23. The unstaged row shows the newer working edit against the index.
  24. The staged row shows the earlier file prepared for the first commit.
  25. One path can appear in both lists without creating two physical files.
  26. Reading either comparison does not stage, unstage or discard content.
  27. A normal commit records the index and advances the local branch.
  28. The recorded subject confirms the first hero commit exists.
  29. The leading space matters: only the working comparison still differs.
  30. An empty cached diff means the index matches history for this path.
  31. The working diff still contains the newer edit. Nothing was lost.
  32. History now has a commit, while the deliberate working edit remains.
  33. Change the sequence: stage the edited file before committing.
  34. Now the newer line is recorded, and this path has no remaining difference.
  35. None of these local steps uploads anything to a provider.
  36. Your own lesson still ends without a repository; initialization comes next.
  37. Do not discard files or reset history just to make an example match.
  38. Working files, prepared content and recorded history can differ.
  39. Check both sequences and explain the two status columns.
  40. Next, create GitTree Features inside GitTree, then test this model yourself.

All tutorials