228

How can I make a new commit and create a new message if no changes are made to files?

Is this not possible since the commit's code (SHA ?) will be the same?

d-_-b
  • 21,536
  • 40
  • 150
  • 256

5 Answers5

291

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.
rogerdpack
  • 62,887
  • 36
  • 269
  • 388
Jeff Bowman
  • 90,959
  • 16
  • 217
  • 251
  • 7
    I've started to follow the git flow [branch model](http://nvie.com/posts/a-successful-git-branching-model/). When you make a `dev` branch form `master` and then a `feat` branch immediately from `dev`, the `feat` branch looks to come from the `master` branch as there is no distinguishing commit on the `dev` branch which the `feat` branch comes from. An empty commit when you first make the `dev` branch helps establish the `dev` branch as it's own indefinitely lasting branch independent of `master`. Generally it's helpful when you use branches as layers, and create two layers from a single commit – Novice C Sep 27 '16 at 08:45
  • 3
    Another reason: If you omit something of importance out of your commit message before pushing, you cannot do `commit --amend` if the remote does not allow force pushing. This way you can allow developers to see an important message that goes with the previous commit. – Andy J Feb 15 '17 at 00:47
  • 3
    I want to do this because I pushed a commit, but forgot to mention something in the commit message. Our commit messages are integrated with issue tracking and continuous integration software and the contents of the commit message affect those applications. Is there a better way? This seems like the best solution in my case. The only thing I can imagine would be somehow being able to revert the previous commit. – sytech Aug 18 '17 at 19:48
  • 2
    I just used this to trigger our pre-commit hook, which scripts the database. So there were changes, just git couldn't see them until after the script had run. Could have run it manually of course, but then that would run the script twice. – yoyodyn Nov 23 '18 at 21:29
  • 1
    Maybe not a fantastic reason, but also to create a Pull request on GitHub to contact the owners when simply opening an Issue was disabled. – Cœur Feb 06 '19 at 03:22
  • 2
    Very useful when interacting with issue tracking builtin to git servers as github and gogs. – SimonF Apr 29 '19 at 08:37
  • 1
    When you're using an integrated PMS and you forgot to put the work item number in previous pushed commits but you want the PMS to track the commit against the work item. – romulusnr Mar 20 '20 at 18:39
  • 1
    Yes there's commit --amend but that's a nightmare when the previous commit is already pushed. – romulusnr Mar 20 '20 at 18:41
  • 2
    Used to mark transitioning "master" branch to "main" branch; see e.g. [this link](https://dev.to/afrodevgirl/replacing-master-with-main-in-github-2fjf). Just one example of using blank commits to capture significant changes to the _repository itself_ which are not captured by code versioning. – Ryan Jendoubi Aug 29 '20 at 18:14
  • One reason could be: Since the last commit I've been sleeping and now I am marking the actual time I start working (with a message of "nop", as in no op) in the next commit so you could tell how long it took me actually to make the changes. – ecv Sep 24 '21 at 17:34
99

Empty commit with a message

git commit --allow-empty -m "Empty test commit"

Empty commit with an empty message but you will be asked to type the message

git commit --allow-empty --allow-empty-message

Empty commit with an empty message

git commit --allow-empty --allow-empty-message -m ""
Blazej SLEBODA
  • 8,936
  • 7
  • 53
  • 93
57

If I understood you right, you want to make an empty commit. In that case you need:

git commit --allow-empty
Dima
  • 6,721
  • 4
  • 24
  • 43
5

Maybe as a more sensible alternative, you could create an annotated tag (a named commit with a message). See the git tag -a option.

nowox
  • 25,978
  • 39
  • 143
  • 293
kan
  • 28,279
  • 7
  • 71
  • 101
5

If you are using a system like gitversion It makes a lot of sense to do this sort of commit. You could have a commit that is specifically for bumping the major version using a +semver: major comment.

Kevin Johnson
  • 51
  • 1
  • 1