CS I · Tue Nov 10 · 15.2 · Do Now

Versions and Commits

Open the discussion form on the right and answer Section 1 from your first reading.

Announcements

Versions, Commits and History

This section explains how a builder keeps each version of a program, what a commit records, and how to read a list of commits.

Versions of a Program

A version is the state of a project at one moment. Every time a person changes a program, there is a new version, whether or not anyone kept the old one. Many people keep old versions by copying files into another folder, a habit that the book Pro Git calls common, simple and easy to get wrong. A copy of a file with a new name is a version with no record of what changed or when, because the name is the only label it has.

Version control is a system that records changes to a set of files over time, so that a person can open a specific version later. With a version control system such as Git, a builder can return the whole project to an earlier version, compare changes over time and see who made a change and when.

What a Commit Records

In version control, a commit is a saved snapshot of the whole project at one moment, with a message about the change. The Pro Git authors explain that each time a builder commits, Git takes a picture of what all the files look like at that moment and stores it. If a file did not change, Git links to the copy it already has. For this reason, a commit holds the whole project and not only the lines that changed. Git also records who made the commit and when, and it labels each commit with a code called a hash.

A commit is made on purpose, and typing a change into a file does not add that change to the record. First, the builder chooses which changes go into the next commit, and then the builder commits them and writes a message. A change that was typed and not committed is not in the history, so it cannot be opened later as a version. A Google Doc saves changes on its own as the writer types, while a commit is made on purpose by a person and labeled with a message.

Reading a History

The history is the list of commits in order. When a builder asks Git for the history, Git lists the commits with the newest one first. Any earlier version can be opened from the history, so a change that made a program worse can be undone. A folder full of renamed copies is not a history, because the names do not record the order or the reason for each copy.

The class example is a short Java program named Stops.java, which prints a number of bus stops. Its history has three commits, and Git printed it below, one commit on each line, with the short hash, the date and the message.

77408ab 2026-11-04 Start at 8 stops because the route has 8
ea027f0 2026-11-03 Count down one stop after the first print
d3683b0 2026-11-02 Add Stops.java: print the number of stops

Read from the bottom up, the history runs from oldest to newest. The first commit adds Stops.java, which prints 5. The second commit makes the program count down one stop, so it prints 5 and then 4. The third commit starts the count at 8, so it prints 8 and then 7. Figure 1 shows the same three commits as a timeline from oldest to newest, with what each version prints.

Writing a Commit Message

A commit message says what changed, and a good message also says why. The Git documentation advises starting a message with one short line, no more than 50 characters, and Pro Git adds that the reason for the change belongs in the message. For example, "Start at 8 stops because the route has 8" tells a reader what changed and the reason for it. The message "update" is not an example of a useful message, because it would fit any commit. A longer message is not always a better one, since a long message that never names the change tells a reader nothing more.

The three files in the Board Question show the problem that version control solves, because their names carry no dates, no order and no reasons. In Java, the copies cause a second problem, because a file named Stops2.java that holds the class Stops will not compile. A public class has to be in a file with the same name, and when the class example was tried this way, javac reported an error saying that class Stops belongs in a file named Stops.java.

Summary

A version is the state of a project at one moment, and version control records versions so that any of them can be opened later. A commit is a saved snapshot of the whole project with a message about the change, and a person makes it on purpose. The history lists the commits in order, and a useful commit message says what changed and why.

Sources: Chacon and Straub, Pro Git, 2nd ed., sections 1.1, 1.3, 2.2, 2.3 and 5.2 (2014); Git project, git-commit Documentation (n.d.); Git project, git-log Documentation (n.d.); Google, Create, view, or download a file (n.d.); classroom data, the Stops example repository (2026).

I Do questions
  1. notebook cue: version

    The Stops example has three commits. How many versions of Stops.java can be opened from its history?

    Check

    Three versions can be opened, one for each commit: the version that prints 5, the version that prints 5 and then 4, and the version that prints 8 and then 7. Each commit is a snapshot of the whole project, so each one keeps a whole version. See Reading a History, paragraph 3, and Figure 1.

  2. notebook cue: commit

    A commit is a snapshot plus one thing that a person writes. What is it?

    Check

    The person writes a message about the change. Git records the snapshot, the person's name and the date, but the message is the part a person writes. See What a Commit Records, paragraph 2.

  3. notebook cue: history

    Which message is more useful in a history: "update," or "Start at 8 stops because the route has 8"? Why?

    Check

    "Start at 8 stops because the route has 8" is more useful, because it says what changed and why. The message "update" would fit any commit at all, so a reader of the history learns nothing from it. See Writing a Commit Message, paragraph 1.

Figure 1. The three commits of the Stops example repository, from oldest to newest, each a snapshot of the project with its message, its date and what that version prints.
I Do questions
  1. notebook cue: version

    The Stops example has three commits. How many versions of Stops.java can be opened from its history?

    Check

    Three versions can be opened, one for each commit: the version that prints 5, the version that prints 5 and then 4, and the version that prints 8 and then 7. Each commit is a snapshot of the whole project, so each one keeps a whole version. See Reading a History, paragraph 3, and Figure 1.

  2. notebook cue: commit

    A commit is a snapshot plus one thing that a person writes. What is it?

    Check

    The person writes a message about the change. Git records the snapshot, the person's name and the date, but the message is the part a person writes. See What a Commit Records, paragraph 2.

  3. notebook cue: history

    Which message is more useful in a history: "update," or "Start at 8 stops because the route has 8"? Why?

    Check

    "Start at 8 stops because the route has 8" is more useful, because it says what changed and why. The message "update" would fit any commit at all, so a reader of the history learns nothing from it. See Writing a Commit Message, paragraph 1.

Versions, Commits and History

This section explains how a builder keeps each version of a program, what a commit records, and how to read a list of commits.

Versions of a Program

A version is the state of a project at one moment. Every time a person changes a program, there is a new version, whether or not anyone kept the old one. Many people keep old versions by copying files into another folder, a habit that the book Pro Git calls common, simple and easy to get wrong. A copy of a file with a new name is a version with no record of what changed or when, because the name is the only label it has.

Version control is a system that records changes to a set of files over time, so that a person can open a specific version later. With a version control system such as Git, a builder can return the whole project to an earlier version, compare changes over time and see who made a change and when.

What a Commit Records

In version control, a commit is a saved snapshot of the whole project at one moment, with a message about the change. The Pro Git authors explain that each time a builder commits, Git takes a picture of what all the files look like at that moment and stores it. If a file did not change, Git links to the copy it already has. For this reason, a commit holds the whole project and not only the lines that changed. Git also records who made the commit and when, and it labels each commit with a code called a hash.

A commit is made on purpose, and typing a change into a file does not add that change to the record. First, the builder chooses which changes go into the next commit, and then the builder commits them and writes a message. A change that was typed and not committed is not in the history, so it cannot be opened later as a version. A Google Doc saves changes on its own as the writer types, while a commit is made on purpose by a person and labeled with a message.

Reading a History

The history is the list of commits in order. When a builder asks Git for the history, Git lists the commits with the newest one first. Any earlier version can be opened from the history, so a change that made a program worse can be undone. A folder full of renamed copies is not a history, because the names do not record the order or the reason for each copy.

The class example is a short Java program named Stops.java, which prints a number of bus stops. Its history has three commits, and Git printed it below, one commit on each line, with the short hash, the date and the message.

77408ab 2026-11-04 Start at 8 stops because the route has 8
ea027f0 2026-11-03 Count down one stop after the first print
d3683b0 2026-11-02 Add Stops.java: print the number of stops

Read from the bottom up, the history runs from oldest to newest. The first commit adds Stops.java, which prints 5. The second commit makes the program count down one stop, so it prints 5 and then 4. The third commit starts the count at 8, so it prints 8 and then 7. Figure 1 shows the same three commits as a timeline from oldest to newest, with what each version prints.

Writing a Commit Message

A commit message says what changed, and a good message also says why. The Git documentation advises starting a message with one short line, no more than 50 characters, and Pro Git adds that the reason for the change belongs in the message. For example, "Start at 8 stops because the route has 8" tells a reader what changed and the reason for it. The message "update" is not an example of a useful message, because it would fit any commit. A longer message is not always a better one, since a long message that never names the change tells a reader nothing more.

The three files in the Board Question show the problem that version control solves, because their names carry no dates, no order and no reasons. In Java, the copies cause a second problem, because a file named Stops2.java that holds the class Stops will not compile. A public class has to be in a file with the same name, and when the class example was tried this way, javac reported an error saying that class Stops belongs in a file named Stops.java.

Summary

A version is the state of a project at one moment, and version control records versions so that any of them can be opened later. A commit is a saved snapshot of the whole project with a message about the change, and a person makes it on purpose. The history lists the commits in order, and a useful commit message says what changed and why.

Sources: Chacon and Straub, Pro Git, 2nd ed., sections 1.1, 1.3, 2.2, 2.3 and 5.2 (2014); Git project, git-commit Documentation (n.d.); Git project, git-log Documentation (n.d.); Google, Create, view, or download a file (n.d.); classroom data, the Stops example repository (2026).

Table Talk
A folder holds Stops.java, Stops2.java and Stops_new.java. Which one is the newest, and how would you know? Say what is missing.

Each table agrees on what information is missing from the three file names, and where that information could be kept.

Chromebooks stay closed while your table talks. Sections 1 and 2 of the discussion form are already done. After you talk, finish Section 3 right here under My View. Submit before the exit ticket.

Open the discussion form

This form has three sections. Section 1: answer today's Board Question. Section 2: after the reading. Section 3 opens later in class. Today's Board Question: A folder holds Stops.java, Stops2.java and Stops_new.java. Which one is the newest, and how would you know? Say what is missing.

CR 1. Board Question: A folder holds Stops.java, Stops2.java and Stops_new.java. Which one is the newest, and how would you know? Say what is missing. Give your answer and one reason.

Write your answer in your lab notebook, labeled CR 1.

MC 1. Think about your answer to the board question. A folder holds Stops.java, Stops2.java and Stops_new.java. Which one is the newest, and how would you know? Say what is missing. Which position is closest to yours now?

  • Stops_new.java, because its name says it is new.
  • Nobody can tell from the names. The dates and the reason for each change are missing.
  • Stops2.java, because 2 comes after the first one.

MC 2. (Reading claim 1) A commit saves a snapshot of the whole project, with a message.

  • Agree
  • Disagree

MC 3. (Reading claim 2) Typing a change into a file adds it to the history.

  • Agree
  • Disagree

MC 4. (Reading claim 3) A longer commit message is always a better commit message.

  • Agree
  • Disagree

MC 5. (Reading claim 4) When Git shows a history, the newest commit is listed first.

  • Agree
  • Disagree

MC 6. (Reading claim 5) A commit stores only the lines that changed, not the whole project.

  • Agree
  • Disagree

MC 7. (Reading claim 6) In Figure 1, the version from commit 2 prints 5 and then 4.

  • Agree
  • Disagree

MC 8. (Reading claim 7) In Reading 2, the value 3 is still stored in a after line 3 runs.

  • Agree
  • Disagree

MC 9. (Reading claim 8) A file named Stops2.java that holds the class Stops will not compile.

  • Agree
  • Disagree

CR 2. (A different view) Write the view at your table that was most different from yours. If everyone agreed, write the strongest argument against your table's answer.

Write your answer in your lab notebook, labeled CR 2.

CR 3. Think about the Board Question again: A folder holds Stops.java, Stops2.java and Stops_new.java. Which one is the newest, and how would you know? Say what is missing. Do you have the same opinion as when you first answered the board question? If it is the same, what from the reading or table talk reaffirmed your opinion? If it is different, what from the reading or table talk changed your opinion?

Write your answer in your lab notebook, labeled CR 3.