Images are reused AI-generated editorial illustrations, not documentary photographs or verified product screenshots.
Setting up Git config is partly about commit identity and partly about repository behavior. The user.name and user.email values identify commit authorship; they are not a login or password. Freelancers working across personal and client repositories should choose configuration scope deliberately to avoid mixing identities or surprising project defaults.
Distinguish global and repository settings
Global settings apply broadly to your user account, while repository-local settings apply within a specific repository. For a client project, configure the approved author name and email locally when they should differ from personal work. Inspect the effective value and its source with git config --show-origin --get user.email.
Keep authentication outside author fields
Repository access uses the hosting service’s supported authentication method and credential tooling. Putting a token into user.email or a remote URL is not a sensible identity setup. Do not copy private credentials into documentation or screenshots. A valid author email does not prove that a person is authorized to access or sign a commit.
Review behavior settings before copying snippets
Settings for pull behavior, line endings or default branches can change collaboration outcomes. Follow the project’s documented conventions rather than pasting an entire configuration from another client. Check which scope a command modifies, and record exceptions that another developer needs to know during handover.
A practical checklist
- Agree the client’s author identity convention.
- Use repository-local settings for project-specific values.
- Inspect effective values and their source.
- Use supported credential storage for authentication.
- Document behavior settings that affect collaboration.
Worked example
Illustrative example: a freelancer’s global email is personal, but a client expects its assigned work address on project commits. They set the address locally and verify the source. They continue using the approved hosting login separately. The resulting author metadata is consistent without pretending the email field grants repository access.
Common questions
Does changing config rewrite old commits? No. Is user.name necessarily a hosting username? No. Can local settings override global ones? Yes, configuration precedence matters; inspect the effective result rather than relying on what you last typed.
What to do next
Check author identity when starting each repository and before the first delivery. If existing history needs correction, agree the process with the client instead of rewriting shared commits unilaterally.