Introduction

Yes, Git can use different configuration for different projects, and this is a normal setup for developers who work across companies, identities, or workflows. The simplest level is repository-local configuration, but Git also supports conditional includes for directory-based configuration. Choosing the right scope depends on whether the setting belongs to one repository, a group of repositories, or your whole machine.

Understand Git Config Scopes

Git settings exist at three main levels:

• system
• global
• local

You can inspect them with:

git config --system --list
git config --global --list
git config --local --list

Local configuration lives inside .git/config and affects only one repository.

Use Repository-Local Configuration

For one specific project, set the values locally.

git config user.name "Work Identity"
git config user.email "[email protected]"
git config core.hooksPath .githooks

Because these commands run inside the repository, they update only that repository configuration.

Check the result:

git config --local --list

This is the cleanest answer when the configuration is truly repo-specific.

Use Conditional Includes for Groups of Projects

If you want one configuration for all repositories under a directory, use includeIf in your global Git config.

Example in ~/.gitconfig:

1[includeIf "gitdir:~/work/"]
2    path = ~/.gitconfig-work
3
4[includeIf "gitdir:~/personal/"]
5    path = ~/.gitconfig-personal

Then define the specialized files.

~/.gitconfig-work:

[user]
    name = Work Identity
    email = [email protected]

~/.gitconfig-personal:

[user]
    name = Personal Identity
    email = [email protected]

This is a strong setup when multiple repositories share the same identity or policy.

Use Different Signing Keys Per Project Group

Conditional includes are especially useful for signing configuration.

1[user]
2    signingkey = ABCD1234
3
4[commit]
5    gpgsign = true

That lets work repositories and personal repositories use different keys without manually switching settings before every commit.

Apply Workflow Settings Per Project

Identity is not the only reason to separate config. You may also want:

• different hooks paths
• different merge tools
• different pull behavior
• different line-ending rules

Example:

git config pull.rebase true
git config fetch.prune true

If a team has strict workflow conventions, putting those in local or conditionally included config is often cleaner than relying on memory.

Verify the Active Source of a Setting

When debugging multiple config layers, ask Git where a value came from.

git config --show-origin --get user.email

This is critical once you start combining global config, local config, and include rules. Without --show-origin, it is easy to edit the wrong file and think Git is ignoring you.

Local Versus Directory-Based Strategy

Use local config when:

• the setting is unique to one repository

Use includeIf when:

• many repositories under one folder should share a config profile

The directory-based method scales better if you regularly create new repositories under the same organizational root.

Common Pitfalls

• Changing global config when the setting should be repository-local.
• Forgetting to check the source of a value with --show-origin.
• Using includeIf with the wrong directory pattern.
• Manually editing identity before each commit instead of using config scopes.
• Mixing team workflow settings into personal global config unnecessarily.

Summary

• Git fully supports different configuration for different projects.
• Use local config for one repository and includeIf for groups of repositories.
• Separate identities, signing keys, and workflow settings by scope.
• Use git config --show-origin to debug layered config behavior.
• Choose the smallest scope that matches the real ownership of the setting.