Skip to content
GitTree

Video: Stage the intended snapshot and make your first commit

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

Create the project's README and hero page inside GitTree, select what belongs in the first commit, and deliberately leave a later edit uncommitted. Prove what was recorded instead of judging success by a notification alone.

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. Create the hero, prepare one edition, and prove what your first commit saved.
  2. Start in the original repository from L004, not its supplemental clone.
  3. Saving, staging and committing change different snapshots.
  4. Create the first file through GitTree's New File command.
  5. Name it README dot em dee, at the project root.
  6. Save the complete fictional-project README, not the Markdown fences.
  7. Create index dot H T M L in the same repository.
  8. Save the original hero with this supporting line.
  9. Open working changes to see both new, untracked files.
  10. With nothing staged, this button stages all changes first.
  11. The terminal confirms two untracked files, not two commits.
  12. A normal commit cannot record these files before you select their contents.
  13. Stage only the README first.
  14. Unstage it again. Its saved working text stays intact.
  15. Unstage changes the selection; Discard can remove working content.
  16. Now stage both intended files, one by one.
  17. The S and U shortcuts work in their focused lists, not inside text fields.
  18. Review the staged content, not just the file count.
  19. The summary counts lines; it does not prove those lines are correct.
  20. The prepared edition is still the original hero.
  21. Reopen the working file, not the staged comparison.
  22. Save the later supporting line without staging it.
  23. The same path now appears in both comparisons.
  24. The unstaged comparison shows the later edit against the index.
  25. The staged addition still contains the earlier line.
  26. Read the index directly to prove what is prepared.
  27. Without staging again, which supporting line will the first commit contain?
  28. Write a summary that describes the hero you actually added.
  29. Keep amend and all optional behaviors off for this first local commit.
  30. Commit the two staged paths, not every visible row.
  31. Wait for Git to confirm creation before treating the operation as complete.
  32. Main now points to its first local commit.
  33. The later working edit remains outside the commit on purpose.
  34. Verify the subject, author and committer independently.
  35. There is one commit containing exactly these two paths.
  36. An empty cached diff can coexist with a working modification.
  37. The recorded file is earlier; the working file still has the newer line.
  38. Nothing was uploaded. This repository still has no remote.
  39. If you stage the later edit first, the prepared edition changes.
  40. That alternative commit records the newer line and leaves a clean result.
  41. The commit shortcut is an alternative submission, not a second finishing step.
  42. If Git refuses, inspect its output and the staged content before retrying.
  43. Do not discard the remaining edit or assume Undo covers every buffer.
  44. Your checkpoint is one exact commit plus one deliberate working edit.
  45. Check the recorded contents, identity and leftover work separately.
  46. Saving writes the working file; staging selects; committing records.
  47. Keep the later edit. Next, inspect diffs and add the project's tools.
  48. Continue from this verified state, not from a guessed clean folder.

All tutorials