A commit can record more than a code change
In Git, a commit is a saved point in a project’s history. Usually it records changes to files, but Git can also make a commit when the files are exactly as they were before. The `--allow-empty` flag tells Git to create that history entry anyway.
This works because a commit is not simply a bundle of changed files. It is also a record that points to a particular project state and carries information such as its author, message, and place in the sequence of history. If the state matches the previous commit, Git can reuse the same underlying file snapshot while still adding a new commit record.
Why record an event with no file changes?
An empty commit can mark a point in a workflow that matters even though it does not alter the code. For example, a team might use one to trigger an automated build or deployment system that responds to new commits. It can also serve as a deliberate marker in the history, separating one phase of work from another.
That distinction is useful: the repository’s files describe what the project contains, while its commit history can also document when an event occurred. An empty commit leaves the first unchanged but adds the second.
Because it creates a real entry in history, an empty commit is different from merely writing a note outside Git—or from changing a file just to force a commit. The next time someone inspects the project’s timeline, the event is there without a meaningless edit attached.
