A Git commit is one kind of "object" in git. Objects in Git are hashed like so:
SHA1("[objecttype] [objectlen]\0[objectdata]")
and a commit object looks like this (blatantly stolen from the Stripe V3 CTF):
tree #{tree}
parent #{parent}
author CTF user <me@example.com> #{timestamp} +0000
committer CTF user <me@example.com> #{timestamp} +0000
Give me a Gitcoin
The "tree" in the commit is the hash tree reference that actually points to your code.
You can probably cycle through a couple million milliseconds in the various timestamps involved to get a large selection of hashes to pick from without making your commit stand out.
Iterating through the author timestamp gives you a bit more than 16 bits for one day. Then you may wonder how much freedom you want to take with the committed timestamp; it should be later than the author timestamp, but if it's off by a few hours to a day it might still be fine, which gives you another ~14 bits, and you're already at 30 bits. Throw in flippable punctuation (i.e., in the commit message, do you write deadbeef as a single word or not? Do you add a full stop or not?) and perhaps some other variations of the commit message and file contents, and 32 bits of nonce is actually fairly easy to get.
It's still a very cool demonstration of why you really need to compare every single bit of your hashes.
A Git commit is one kind of "object" in git. Objects in Git are hashed like so:
SHA1("[objecttype] [objectlen]\0[objectdata]")
and a commit object looks like this (blatantly stolen from the Stripe V3 CTF):
The "tree" in the commit is the hash tree reference that actually points to your code.