The Deploy That Fails Because of Your Git Email

A push reached the default branch. The commit was there on the remote. No build appeared.

Not a failed build — no build at all. No log to read, no error to search, nothing in the repository different from the commits that had deployed fine an hour earlier.

The cause was the commit author's email address. It was off by one character in the domain, and the hosting platform refused to attribute the commit to a member of the team. No team member, no build.

Why platforms do this

Connect a Git host to a deployment platform and you create an automatic path from "commit lands" to "code runs in production". That path needs an identity attached, for seat accounting, audit trails, and the obvious security question: whose change is this?

Most platforms answer by matching the commit author email against the emails on the accounts in your team. An unrecognised address means the commit cannot be attributed, and policies differ on what happens next — some skip the deploy silently, some queue it pending approval, some surface a warning most people never look at.

The result is a deploy that does not happen for a reason that lives in neither your code nor your CI configuration.

Diagnosing it in thirty seconds

git log -3 --format='%an <%ae>  %h  %s'

Compare those addresses against the ones registered on your deployment platform and Git host. Watch for:

• a work address that differs from the one on the platform account
• a typo in the domain — ours was @intsigna.com where the account used a different spelling
• the GitHub noreply address (12345+user@users.noreply.github.com) when the platform expects a real one
• a machine or CI identity committing on a developer's behalf
• a global user.email left over from a previous employer or a personal account

The last one is the most common on a shared or rebuilt machine, where git config --global was set once and forgotten.

Fixing it

Set the identity per repository, so a global default cannot leak into work commits:

git config user.email "you@company.com"
git config user.name  "Your Name"

For a commit that has already been pushed and refused, the content is fine — only the attribution is wrong. If it is the most recent commit and nobody has built on it:

git commit --amend --author="Your Name <you@company.com>" --no-edit
git push --force-with-lease

Prefer --force-with-lease to --force: it refuses if someone else has pushed in the meantime, which is the one scenario where a force push does real damage.

If rewriting is not acceptable — a shared branch, a commit others have pulled — the simplest honest fix is an empty commit with the right identity, which gives the platform something it can attribute:

git commit --allow-empty -m "Trigger deploy"
git push

That also solves a neighbouring problem. Some platforms skip building a commit SHA they have already built in another context — a preview deploy for the same SHA, for instance — so a promotion to production finds nothing to do. An empty commit produces a new SHA and a fresh build. We have reached for this one more than once.

Stop it happening again

Pin the identity where the work happens. A .gitconfig per project directory, or includeIf in your global config:

[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

Check it in CI. A pre-receive hook or a cheap CI step that rejects commits whose author domain is not on an allowlist turns a silent non-deploy into an explicit failure with a message:

email=$(git log -1 --format='%ae')
case "$email" in
  *@company.com) ;;
  *) echo "Commit author $email is not a company address — deploy will be skipped."; exit 1 ;;
esac

Write it down where it will be found. Not in a wiki — in the repository, in the contributing notes or a comment at the top of the deployment config. The people who hit this are usually new to the project or on a new machine, and they will not know to search for it.

The general lesson

When a deploy does not happen, the instinct is to look at the build. But "the build failed" and "no build was attempted" are different problems with different causes, and the second one leaves no artefact to investigate.

Before debugging code, confirm the platform saw a deployable commit at all. Most Git hosts expose deployment records through an API:

id=$(gh api "repos/OWNER/REPO/deployments?per_page=1" --jq '.[0].id')
gh api "repos/OWNER/REPO/deployments/$id" --jq '.sha[0:7]'
gh api "repos/OWNER/REPO/deployments/$id/statuses" --jq '.[0].state'

If the newest deployment SHA is not yours, the problem is upstream of the build — and no amount of reading your own code will find it.