How to commit no change and new message?

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?

Solution

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 it will definitely have a different parent commit. All of those factors are integrated into git's object hash algorithm (among others like author and committer).

Empty commits become a part of the git commit graph just like regular commits, so be careful if using --allow-empty for ephemeral usage like triggering build scripts or "scratch pad" notes in large projects. Those commits may add noise to the git history or may make it more difficult for you or your collaborators to find more-relevant commits later—your colleagues may not expect to download your build script invocations every time they pull your repo. For local development this might be a reason to label ephemeral empty commits consistently (perhaps using -m) and remove them pre-merge with git rebase -i.

That said, to incorporate some of the comments, you may want long-lived empty commits for some of these reasons:

To add intended commit messages when you cannot --amend the commit, particularly when force-pushes are disallowed (via Andy J).
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 interact with product management systems (via romulusnr) or issue tracking systems, including ones built into GitHub or git hosts like GOGS (via SimonF).
When using certain git branch models, such as git flow, to distinguish a long-lived branch like dev from its first feature (via Novice C).
To mark repository milestones that don't have their own code changes, such as a move from master to main naming (via Ryan Jendoubi) or milestones in feature development (via NeilG).

And also some ephemeral ones:

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), executing precommit hooks (via yoyodyn, for the sake of personal logging or metrics (via DynamiteReed), or time tracking (via ecv), noting as above that depending on the nature of the commits and repository, this might not be a good fit for a long-lived shared repo.

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.