Git commits

This post will cover what Git commits are and how they are working. If you are new to Git and versioning systems, you can read my introduction poston this topic.

What is commit?

If we look at our software project as a game, a commit is save of our progress. You pass some level, win a battle against some boss, and you want to save how far you got. You do not want to start from the beginning next time you play. The same is with software, you write some lines of code, but you still have lots more to write. So you make a commit. Write some more and do some more commits.

You can use different visualization tools to see commits timeline, but the image above displays an example of a project timeline. You make first commit, after that second, and by tracking line, you can see what changed between each commit.

Commit data

Each commit can carry different data. Some are mandatory, and some are optional. One necessary attribute is commit ID. This ID is the SHA-1 hash of everything important about this commit and uniquely identifies it. Other mandatory data are commit date and commit changes. There are two other pieces of data that are not required but are good practice to have them set. Those are commit message and commit author.

Commit change

Earlier, I wrote that commit is like a game checkpoint. But what does it save? Git tracks only differences between two commits. If I go back to the game analogy, you could have a character standing in a spot and make a save. Then we make it do two steps forward and the one back before making the next save. Kept in the commit is just a difference, and that is only one step ahead.

Now let’s drop game analogy and go back to software. Let’s say we have a file containing the following JavaScript code:

console.log("Hello world");

We could make a commit at this moment and add another line.

console.log("Hello world");
console.log("Another line");

If we would make a commit now, it would only contain this newly added line. It will ignore the first line because the first commit is tracking it.

And now to explain that two-step forward one backward example in code. We have a file with two lines of javascript code. First, we could add two lines.

console.log("Hello world");
console.log("Another line");
console.log("Line 3");
console.log("Line 4");

Before we make a new commit, we delete the third line.

console.log("Hello world");
console.log("Another line");
console.log("Line 4");

Making commit at this moment would only contain added this one line, and it would ignore that deleted line ever existing.

Changing a line is a special case. If the text in the first line, “Hello world”, would be changed to say “Hello world!”, git would see it as deletion and addition. First, it treats the original line as deleted, and this new line as added in its place.

Wrap up

Commits are not a complex feature but are a fundamental feature of Git. They show only changes done between two, and I hope this post made it easier to understand how it is doing that.