2.3. Take a snapshot of our content with Git

2.3.1. Add your new file to the Staging area

You can think of the Staging area as where files live before they are snapshotted.

To view the current status of the repo, run:

$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
      marbles.txt

      nothing added to commit but untracked files present (use "git add" to track)

In the output above, git has recommended that we use git add to “track” this new file.

$ git add marbles.txt

2.3.2. View what is ready for commit

$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   marbles.txt

Notice that the file marbles.txt is now displayed in green (if you have a color-enabled terminal), and is in a section labeled “Changes to be committed”.

🎉 This means we’re ready for the next step!

2.3.3. Take a snapshot

$ git commit -m "Add marbles.txt"
[main (root-commit) 075bbc6] Add marbles.txt
 1 file changed, 7 insertions(+)
  create mode 100644 marbles.txt

This will created a snapshot (called a commit in Git parlance) of our new file in the staging area, marbles.txt. The argument -m "Add marbles.txt" set a commit message, which describes our change.

In the output above, we can see that a new commit was created, and it was given the unique hash 075bbc6. One file was changed (marbles.txt), and seven lines were added (7 insertions(+) in Git language).

Note

You can omit the -m argument to use the interactive commit workflow, but I recommend replacing it with --verbose in that case to provide useful context when writing a commit message. For the purpose of this tutorial, we will not use the interactive commit interface and will always use -m.

2.3.4. Check the repository status again

$ git status
On branch main
nothing to commit, working tree clean

🎉 This tells us that our changes are saved as a snapshot in time, also known as a commit. The text working tree clean tells us that there are no changes in progress in the “working tree”, Git’s name for the directory of files we’re working on.

2.3.4.1. Viewing the History

Now that we’ve added our first commit to the history, we can take a look. git log displays a log of commits. Use git help log to learn more.

$ git log
commit 075bbc6f990324818619e3e081fe49298cf74888 (HEAD -> main)
Author: Matt Fisher <matt.fisher@nsidc.org>
Date:   Tue Mar 29 12:17:52 2022 -0600

    Add marbles.txt

There’s a lot of information here.

The first line commit 075bbc6f990324818619e3e081fe49298cf74888 (HEAD -> main) is the most important. It includes the commit hash, which is a long, intimidating, and seemingly random string. The string isn’t actually random, and you can learn more in the glossary entry for Hash if you’d like. You don’t need to use the full hash in any case, you can abbreviate these long hashes to 5+ characters. After the hash, in parentheses, are the refs, or labels, attached to this commit (HEAD and main). You can use these labels instead of the hash to refer to this commit. Note that some kinds of labels may move over time, so after you’ve made more commits, the HEAD and main labels will point at different commits.

Note

HEAD refers to your current location in the History.

main refers to the “main” or “default” branch which is created by default with every Git repository. You may also see the “main” branch called master in some repositories!

The next two lines, author and date, are self-explanatory, and the final line is the commit message we entered with the -m argument to git commit.

We can get a more compressed view of the history like so:

$ git log --graph --decorate --oneline --all
* 075bbc6 (HEAD -> main) Add marbles.txt

This type of display will be more useful when we have more commits.