Your GitLab public profile email is shown on your profile page, while your commit email is embedded in each commit you make. They are separate settings with different audiences, so you should review each one separately. For future work, use the documented automatically generated private commit email. Prior public commits still contain the old email in their history and need a separate review because the new setting does not erase them retroactively.
Find public social profile clues with our TraceSeek app.
Two emails, two audiences
GitLab treats the public profile email and the commit email as separate settings. The profile email is part of what visitors see on your profile page, while the commit email is recorded inside the commits you create. Because the same address can appear in both places, it is easy to assume one change covers both. In practice, changing one does not necessarily change the other. Review each setting on its own so you know exactly what is public and where. [GitLab Docs: public profile, account ID and owner settings]
Reviewing your public profile email
Start with the profile page that others can see. Check whether the email shown there is one you are comfortable sharing with anyone who visits your profile. Your profile may be addressed by username or user ID on a specific GitLab host, and GitLab.com is a separate context from independently hosted instances. If you use more than one GitLab instance, review each account separately. Making a profile private can hide some sections, but it does not hide every previously public resource automatically, and administrators can impose visibility restrictions. Record what you observe and note that visibility settings may not cover every past artifact. [GitLab Docs: public profile, account ID and owner settings]
- Open your own profile as a visitor would see it, without changing anything.
- Note which email, if any, appears in the public profile sections.
- Record whether your instance is GitLab.com or a separate host, and review each account context separately.
Reviewing the commit email and using the private option
The commit email is stored in the commit itself and is visible to anyone who can see that commit. GitLab provides an automatically generated private commit email that you can use for future work. Switch to that private address in your settings if you want future commits to avoid exposing your personal email. This is a forward-looking change: it affects commits you make after the setting takes effect, not the ones already recorded. Check your settings on the specific instance you use, because availability and interface paths can vary. [GitLab Docs: public profile, account ID and owner settings]
- Locate the commit email setting on each GitLab instance you use.
- Switch to the documented private commit email for future commits.
- Make a new test commit and confirm the private address appears in it.
Why prior public commits need a separate review
Switching to a private commit email does not retroactively erase older public commits. Each existing commit already contains the email address that was used when it was created, and that record remains part of the commit history. The private setting only applies to future work. Reviewing prior commits therefore requires a separate look at where those commits are visible and what they contain. You may need to consider whether the old address is still exposed in public repositories or forks, and whether you want to take any further action on that history. [GitLab Docs: public profile, account ID and owner settings]
| observation | limit | next step |
|---|---|---|
| An older commit shows your personal email. | The private commit email setting does not change existing commits. | Decide separately whether to review or address the commit history. |
| Your profile email is hidden after a settings change. | Other previously public resources are not necessarily hidden. | Check each public artifact you care about on its own. |
| Your profile shows a status message. | A status may remain public even if profile sections are private. | Review the status separately from the email settings. |
Documenting what you find and where you stop
Keep a simple record of what you reviewed and what you changed. List the instance, the profile email setting, the commit email setting, and any older commits you noticed. If a setting or the private commit email option is not available on your instance, record it as unavailable and stop at that boundary rather than guessing an alternative. Use the official current help for your instance if you need more detail. This keeps your review grounded in what you can actually observe and control. [GitLab Docs: public profile, account ID and owner settings]
- Write down each instance you reviewed and the date of the review.
- Note any settings that were unavailable, and do not attempt workarounds.
- Keep the record of prior commits separate from the record of future settings.
A couple more questions
Does changing my commit email remove my old email from past commits?
No. The private commit email setting applies to future commits. Existing commits already contain the email that was used when they were created, so prior public commits need a separate review.
Is my profile email the same as my commit email?
They are separate settings. The profile email is shown on your profile page, and the commit email is recorded in each commit. Changing one does not automatically change the other.
What if the private commit email setting is not available on my instance?
Record it as unavailable and stop at that access boundary. Use the official current help for your instance if you need more detail, rather than guessing an alternative setting.
Sources & editorial notes
Official references checked on October 23, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.