Accounts and profile
Beginner GitHub UI
Why this matters
Two settings decide whether your work is attributed to you and whether GitHub is usable at all: the email your commits carry, and how much it emails you. Both are two minutes of work and both are unpleasant to fix retroactively.
The account
One personal account is enough, and it is yours rather than your employer's: the account follows you between jobs, while access to the company's repositories does not. If your organization uses single sign-on, your personal account is linked to it rather than replaced (lesson 8.5).
The parts of profile photo → Settings worth visiting on the first day:
| Setting | Why |
|---|---|
| Emails | Which address commits are attributed to, and whether it is public |
| Password and authentication | Two-factor authentication, which GitHub requires of contributors |
| SSH and GPG keys | The key for pushing over SSH (lesson 8.2) |
| Notifications | The difference between a useful inbox and 300 unread messages |
| Developer settings | Personal access tokens (lesson 10.12) |
| Public profile | Name, photo and pronouns, which is how colleagues recognize you in a review |
Email, and why commits get attributed to nobody
A commit carries the email address configured in Git (lesson 3.3). GitHub links a commit to your account only if that address is one of your verified addresses. Get it wrong and your work shows as an unlinked name with a grey avatar, forever.
GitHub also offers a noreply address, in the form 12345678+username@users.noreply.github.com, shown on the Emails settings page. Two related settings live there:
- Keep my email addresses private replaces your address with the noreply one in web-based operations.
- Block command line pushes that expose my email rejects a push whose commits carry your real address, which is a useful guard rail rather than an inconvenience.
If you want the privacy, configure Git to use the noreply address and everything lines up:
$ git config --global user.email "12345678+ana@users.noreply.github.com"Existing commits keep the address they were made with. Changing it fixes the future, not the past.
Notifications
GitHub's default is to notify you about everything you are involved in, which starts fine and ends unbearable once you are in a busy organization. Three controls do most of the work, under Settings → Notifications:
| Control | Sensible setting |
|---|---|
| Default notification email | One address, and consider "only participating and @mentions" for email |
| Automatically watch repositories | Off, so joining a team does not subscribe you to everything |
| Watching (per repository) | Participating and @mentions for most, All Activity for the one you own |
The Notifications inbox at the top of the page is worth learning instead of email: it groups by repository, marks things done, and can be filtered to reason:review-requested, which is the query that shows what is actually waiting on you.
The profile
Your profile page is public by default and is genuinely read: reviewers click your name. A real name, a photo and one line of description turn an anonymous handle into a colleague. Pronouns can be set on the same page and are shown next to your name.
Contribution activity, the grid of squares on your profile, is also public. It counts commits to the default branch, issues, pull requests and reviews; private-repository activity appears without detail if you enable it. It is not a productivity measure, whatever anyone says.
How to do it
The one thing that must match is your commit email:
$ git config --global user.emailana@northwind-trails.exampleCompare that with the addresses on your GitHub Emails page. If it is not there and not verified, either add it or switch to your noreply address.
Accounts in the bottom left signs VS Code in to GitHub, which is what the built-in pull request and Codespaces features use. Signing in there does not change your commit identity, which is still git config user.email.
Settings → Version Control → GitHub → Add account, by token or through the browser. The Use current GitHub account option in commit settings can set your commit email to the account's, which is the mistake-proof choice.
The same settings under Edit profile, with Emails, Account for two-factor authentication, Notifications and Preferences. GitLab also has a "commit email" setting and a private noreply address. See lesson 9.1.
- Profile photo → Settings → Emails: verify the address you commit with, or copy the noreply address.
- Tick Keep my email addresses private and Block command line pushes that expose my email if you want the address hidden.
- Password and authentication: enable two-factor authentication.
- Notifications: turn off Automatically watch repositories and set watching to participating and mentions.
- Public profile: name, photo, pronouns.
Common mistakes
- A commit email that is not on your account, so nothing you do is attributed to you.
- Leaving
Automatically watch repositorieson, then declaring GitHub unusable. - An empty profile, which makes you an anonymous handle to people asked to review your work.
- Using a work account you will lose access to for personal contributions.
- Assuming the contribution grid means something. It counts events, not value.
Try it yourself
Goal: make your account attribute your work correctly and stop shouting at you.
- Run
git config --global user.emailand compare it with your verified addresses on GitHub. - Decide between your real address and the noreply one, and set Git to match.
- Enable two-factor authentication if it is not on.
- Turn off Automatically watch repositories, and set your busiest repository to Participating and @mentions.
- Open your notifications inbox and filter it with
reason:review-requested; bookmark that.
Expected result: a commit you push is linked to your account with your avatar, and your notifications show what is waiting on you rather than everything that happened.
Show solution
Step 5 is the habit that survives. The inbox filter is the GitHub equivalent of a to-do list; without it, review requests arrive as email among hundreds and are missed, which is the most common reason a pull request sits for three days.