LuisLlamas Logo
guardando-historia-git-con-commit

Saving History with Git Commit

  • 6 min
  • Beginner

We’ve seen that Git is a version control tool where we can save “snapshots” of our project as we progress.

An Commit is precisely each of those “save operations.” The Commit is the most important operation in the Git system.

But, unlike the classic Ctrl + S in a text editor, a :[Commit] is an immutable package that records and captures the state of your project in time.

In this article, we’ll see how to create these save points, how to structure the associated messages that explain the history of your code.

What is a Commit, Really?

Technically, a commit is an object that contains:

  1. A snapshot of your entire project at that moment.
  2. Some metadata: Author, date, and an explanatory message.
  3. A pointer to the previous commit (its parent).

Thanks to this pointer to the parent, Git can build history as a chain of links. The current commit knows where it came from, and so on back to the beginning of time (init).

Creating Your First Commit

The way to create a commit is (you can see it coming), it’s the commit command. The most common and quick syntax is using the -m (message) option to write the description directly on the command line.

git commit -m "Create initial project structure"
Copied!

If everything went well, Git will respond with something like:

[main (root-commit) 834a9b1] Create initial project structure 3 files changed, 55 insertions(+)

That’s it! Your changes are permanently recorded in Git’s database. They are now safe.

What if I forget -m?

If you just type git commit and press Enter, Git will automatically open your default text editor (Vim, Nano, VS Code… the one we configured in the installation lesson).

This is not an error. It’s useful when you want to write a long message with multiple paragraphs.

  1. The editor opens.
  2. You write your message on the first line.
  3. You save and close the file.
  4. Git detects the closure and creates the commit.

The -aShortcut (Skipping the Stage)

Remember we said that to save a change you first have to do add and then commit? Well, it’s true… but with nuances.

Actually, Git offers us a shortcut for files that are already being tracked.

git commit -a -m "Fix error in main loop"
Copied!

The -a flag (all) tells Git: “Find all the files you already know about that have changed, add them to the stage automatically, and make the commit.”

The files still go through the Stage, but Git will do the add automatically.

It only works for already tracked files that have been modified. It does not work for Untracked files.

The “Little Ball” Diagrams

The concept of a commit is so central to Git that the entire industry has adopted the same visual form to represent them: graph diagrams (a.k.a. the “little ball diagrams”).

Each of those circles represents one of those immutable “snapshots” with its code, its author, and its message. The line connecting them is the history of your project moving forward in time.

We will use this type of graph in the course to explain future concepts.

Best Practices for Messages

The commit message is a very important tool for traceability. A history full of messages like “fix”, “changes”, “asdf”, or “update” is not very useful.

When something breaks in a year and you have to find out when it happened, you’ll be grateful for having written clear messages.

There’s a lot of fanaticism around commit messages. It’s often taught that absolutely every commit must have a perfect, literary message. I’ll tell you the theory, and in the end, I’ll give you my opinion.

The Perfect Theory

If you consult the official documentation, a “perfect” commit message should have this structure:

Short summary of changes (max 50 characters)

More detailed message body, explaining WHAT and WHY
this change was made. Don't explain HOW (that's seen in the code).
You can use multiple lines.
Copied!

Although realistically, for 95% of day-to-day commits, a single clear and descriptive summary line is more than enough.

On the other hand, it is recommended that, to maintain consistency, it is very convenient to follow these three guidelines:

Write the message as if you were giving an order or completing the sentence: “If I apply this commit, it will…”

  • ❌ Bad: “Added login button” (Past tense)
  • ❌ Bad: “Adding login button” (Gerund)
  • ✅ Good: “Add login button” (Imperative)

In English, it’s more evident (Add vs Added), but in Spanish, we maintain the infinitive/imperative to be consistent.

The message should describe the change without having to open the code.

  • ❌ Bad: “Fix bug” (Which of the 200 bugs?)
  • ❌ Bad: “Style changes”
  • ✅ Good: “Fix overflow in mobile menu”
  • ✅ Good: “Update primary color to corporate blue”

This is a very widespread practice (and mandatory in many companies). It involves adding a prefix that indicates the type of change:

  • feat: For a new feature.
  • fix: To fix a bug.
  • docs: Changes only in documentation.
  • style: Formatting changes (spaces, semicolons) that don’t affect the code.
  • refactor: Code changes that don’t add functionality or fix bugs, only improve the structure.

Examples:

  • feat: add support for dark mode
  • fix: prevent crash when dividing by zero
  • docs: update instructions in README

As I said, there’s a lot of fanaticism around commit messages, with which I don’t entirely agree. Not every commit needs a great message.

What’s truly important is that Git is a useful and practical tool for you and your team. If to not lose your work you need to make three intermediate “low-impact” commits with quick messages like “update”, do it.

Later we will learn techniques like using branches, and techniques like Squash to take all those “dirty” commits from your branch and merge them into a single perfect commit before sharing them with the rest of the team.

The perfect history is required when you integrate your work into the main branches, not while you are experimenting in your personal space.

On this page