Clean CoDE Dojo

Committing Changes

10 minutesModule: Local Git Workflow in Action: From git init to Your First Commit

Now that our README is staged, we are ready to make our first commit.

Committing the README

We’re intentionally committing only the README at this point. It’s good practice to make small, focused commits that each represent one logical change. As the LICENSE file serves a different purpose, we leave it for a separate commit.

To commit, we run the git commit command with a clear commit message, which we can for instance specify after the -m flag.

>git commit -m "Add initial README"

The commit message

The commit message is important: It briefly explains what this commit does and, ideally, why the change was made. A clear, crisp message like Add initial README helps explain the purpose of the commit later, when you or someone else needs to revisit or debug changes.

When every commit has a clear purpose and a clear message, the history becomes much easier to read, navigate, and understand. This is also why we write commit messages in imperative form, so they’ll read naturally when we’ll later use various commands to view the project’s history.

Understanding the commit output

If the commit is successful, Git will print some output to summarize what happened in the commit:

[main (root-commit) f072751] Add initial README
1 file changed, 4 insertions(+)
create mode 100644 README.md

Here’s what each part means in the first line:

  • main – the name of the branch we committed to.
  • (root-commit) – this is the very first commit in the repository, the starting point or root of our commit history; each repository has one root commit, whereas every other commit will point to at least one parent commit.
  • f072751 – the first characters of the Git hash (the unique ID of the commit, so Git can uniquely identify each commit); it’s called a hash because Git uses a hash function to generate the ID based on the commit’s contents, but you don’t have to worry about these details. If you later need to refer to this exact commit, you can either use the hash or, for something easier to remember, Git allows you to assign tags to commits.
  • Add initial README – the commit message we wrote.

The second line summarizes what changed in the commit:

  • 1 file changed – we modified or added one file, in our case the README.
  • 4 insertions(+) – Git counts how many lines were added, removed, or changed. The file used in this example contained four lines of text at the time we committed it, so Git counted four new lines added to the file.

The last line tells Git created a new file README.md with specific permissions. It may look intimidating, but you can safely ignore it for everyday Git use. We won’t dive into further detail here, but you can find detailed explanations online.

Tracking and committing the LICENSE

Checking the status again, we see our LICENSE file is still untracked:

>git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
          LICENSE

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

Earlier, we created an empty LICENSE file as part of setting up the project structure. If we edit the file to add a simple placeholder message (which we will replace later with a real permissive open-source license), rechecking the status will display the same message as before, because the LICENSE file is currently untracked.

We can start tracking the file using git add LICENSE:

>git add LICENSE
On branch main

Changes to be committed:
  use "git restore --staged <file>..." to unstage)
          new file:   LICENSE

We then commit it using git commit -m "Add placeholder LICENSE file":

>git commit -m "Add placeholder LICENSE file"
[main 051d53b] Add placeholder LICENSE file
1 file changed, 2 insertions(+)
create mode 100644 LICENSE

The LICENSE file used in this example had two lines of placeholder text in it, so Git reports two insertions instead of the four we saw earlier, when we created the README.md from scratch. Notice there is also no root-commit anymore, because this commit has a parent – the previous commit we made for the README.

Checking the status, our working directory is clean – we have neither untracked files, nor modified tracked files.

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

Looking at the project’s history

Now that we have more than one commit, we can look at the project’s history. The command git log shows our commit history in reverse chronological order. By default, the output is very detailed, which can feel overwhelming when you’re just getting started or you when don’t need all the information.

Fortunately, the git log command has many flags to control what is shown. For a compact, easy-to-read summary that shows each commit on a single line using the short commit ID and the commit message, use the flag --oneline.

>git log --oneline
051d53b (HEAD -> main) Add placeholder LICENSE file
f072751 Add initial README

Our repository now contains two simple text-based files. Real projects usually have many more files, in an organized structure with folders for data, source code, tests, documentation, and so on. We will add more project structure in the next lesson.

Committing Changes