The Daily Loop

1The loop itself

Every day with git, on almost any project, is some version of the same five steps. You change a file. You check what changed. You tell git which of those changes to include in the next snapshot. You make the snapshot, with a message. You send it to GitHub.

Steps 1 through 3 can happen as many times as you like before you ever touch GitHub. A real working session might run status, add and commit five separate times, once per small change, before a single push sends all five commits up at once.

2Three states, one file

At any moment, a file git is tracking sits in one of three states, and git status exists to tell you which. The states explain why step 2 exists at all: staging is where you choose, file by file and even line by line, what the next commit is actually going to contain.

3A commit message somebody can use later

Session 01 showed this repository's real history. Two of those five messages, "Create .gitignore" and "Library view on mobile", say in a few words exactly what changed and let a future reader decide whether that commit matters to them without opening it. A message like "fix stuff" or "updates" forces that same reader to open the commit and work it out by hand, every single time, forever.

A good commit message answers one question: what changed, said plainly enough that someone with no memory of today could read it in the log and know whether to look closer. It does not need to be long. It needs to be specific.

4Pull before you push

Push sends your commits to GitHub. It only works cleanly if GitHub's copy of the branch has not moved ahead of yours since you last checked. If someone else pushed a commit you do not have yet, git refuses your push rather than guess how to combine the two histories, and reports something like Updates were rejected because the remote contains work that you do not have locally. That is not an error in what you did. It is git telling you the two histories have diverged and asking you to pull first.

Running git pull brings those other commits onto your laptop and tries to fit yours in after them. Most of the time this finishes with no fuss at all. Session 05 covers the case where it cannot combine them cleanly, which is called a conflict and is far less alarming than it sounds.

5Try it: your first real commit

Do this in the practice folder you created in session 01, not in HN - Training.

1. Create a plain text file, for example notes.txt, and write one true sentence in it. Run git status. Git reports the file as untracked, which is the state of a file git has never seen before.
2. Run git add notes.txt, then git status again. The same file now shows as a change staged for commit.
3. Run git commit -m "Add notes file", then git log --oneline. Your commit is now the top of the history, with its own hash.
4. Add a second sentence to notes.txt. Run git status, then git diff. Diff shows the exact line you added, before it is staged or committed. This is the check mentioned in the aside above, the one that would have caught today's example.
5. Stage and commit that second change with its own message. Run git log --oneline once more and confirm you now have two commits of your own, on top of nothing, since this is a brand new repository.

6Check for understanding

1. A file was edited but never staged with git add. What does git commit do with it?

   A.Includes it automatically, since any changed file is assumed to be ready. B.Leaves it out. The commit includes only what has been staged with git add. C.Refuses to commit anything until every modified file is staged. D.Discards the unstaged edit permanently.
   Answer

   Only staged changes become part of a commit. An edited file that was never staged stays in the modified state, untouched by the commit, and can be staged and committed later on its own.

   Show the answer
2. Why does the lesson call "fix stuff" a weak commit message rather than simply a short one?

   A.Because git truncates any message under a certain length, losing information. B.Because it names no specific change, so a later reader has to open the commit to find out what happened. C.Because a vague message causes git to commit the wrong files. D.Because GitHub rejects any commit message under four words.
   Answer

   The complaint is specificity, not length. "fix stuff" names no actual change, so anyone reading the history later, including the author, has to reopen the commit just to learn what it did. A short, specific message like "Create .gitignore" avoids that entirely.

   Show the answer
3. What does git report when a push is rejected because the remote has commits your laptop does not?

   A.It deletes the newer commits on GitHub automatically to match your laptop. B.It merges the two histories automatically with no further action from you. C.It rejects the push and reports that the remote contains work you do not have locally. D.It asks you to re-enter your GitHub password before trying again.
   Answer

   Git refuses the push outright and reports that the remote contains work you do not have. It will not guess how to combine the two histories on your behalf; running git pull first is what brings the missing commits in so your push can proceed.

   Show the answer
4. In today's real example, why did an unrelated homepage change end up inside a commit about the Library button?

   A.Because git automatically merges the work of anyone with access to the same repository. B.Because both edits were sitting in the same shared working tree with nothing, such as a branch, keeping them apart. C.Because the commit message happened to mention the homepage indirectly. D.Because GitHub bundles all pending commits from every contributor into one on every push.
   Answer

   Both people were editing the same working tree with no branch keeping their work apart, so when one of them committed, git had no way to separate "my change" from "whatever else happens to be sitting here right now." A git status and git diff before committing would have shown both sets of changes staged together. Session 04 covers the tool, branches, that prevents this by design.

   Show the answer
5. What does git diff show, run after an edit but before git add?

   A.The commit messages of the last several commits. B.The exact lines that changed in the working tree since the last commit. C.A comparison between your laptop and whatever is currently on GitHub. D.Nothing, until the change has been staged with git add.
   Answer

   git diff shows the exact lines that changed in the working tree compared with the last commit, before anything is staged. Running it as a habit before git add is the single check that would have caught today's bundled-commit example, since it shows every pending change before it gets locked into the next commit.

   Show the answer

7Before session 04

• Keep your practice folder and its two commits; session 04 branches directly off this history.
• Next time you see a line like "nothing to commit, working tree clean", notice it. It means every change you have made is already committed, which session 04 relies on before switching branches.

8Glossary

Untracked

A file git has never recorded in any commit.

Modified

A tracked file whose contents differ from the last commit.

Staged

A change marked with git add, ready to be included in the next commit.

Staging area

The holding area between a modified file and a committed one, where you choose exactly what the next commit will contain.

Diverged

The state where the remote and your local branch each have commits the other does not.

Fast-forward

The simple case where your branch can move straight up to match the remote with nothing to combine, because no one else's commits conflict with yours.

9Sources

• Scott Chacon and Ben Straub, Pro Git, 2nd edition, chapter 2, "Recording Changes to the Repository."
• Chris Beams, How to Write a Git Commit Message, for the seven rules behind a message worth reading later.
• The commit example in section 3 is this repository's own history, da57a3f, 2026-10-03.