There's rarely a good reason to do this, but the parameter is --allow-empty for empty commits (no files changed), in contrast to --allow-empty-message for empty commit messages. You can also read more by typing git help commit or visiting the online documentation.
While the tree object (which has a hash of its own) will be identical, the commit will actually have a different hash, because it will presumably have a different timestamp and message, and will definitely have a different parent commit. All three of those factors are integrated into git's object hash algorithm.
There are a few reasons you might want an empty commit (incorporating some of the comments):
- As a "declarative commit", to add narration or documentation (via DavidNeiss) including after-the-fact data about passing tests or lint (via Robert Balicki).
- To test
git commands without generating arbitrary changes (via Vaelus).
- To re-create a deleted bare repository using
gitolite (via Tatsh).
- To arbitrarily create a new commit, such as for re-triggering build tooling (via mattLummus) or for the sake of personal logging or metrics (via DynamiteReed). However, think twice: depending on your branch/merge structure, commits may live for a very long time, so a "just commit nothing" strategy may be inadvertently pollute your team's repository with temporary workflow artifacts and make it hard to separate code revisions from ephemeral cruft.
Other strategies to add metadata to a commit tree include:
- Separate branches or lightweight tags that always point to a commit of a particular status (e.g. "last accepted commit" or "current staging commit").
- Annotated Tags for a way to record timestamp, committer, and message, pointing to an existing commit without adding an entry in the commit tree itself.
git notes to associate a mutable note on top of an existing immutable commit.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
