Локальная конфигурация Git - git config --local

Введение

Локальная конфигурация Git через команду git config --local — это тот уровень настроек, который применяется только к одному конкретному репозиторию. Вы можете настроить имя и email для конкретного проекта, включить или выключить автокоррекцию команд, настроить параметры merge и rebase — и все это не затронет остальные ваши проекты и не изменит глобальную конфигурацию пользователя.

Смотрите, я покажу вам, как с помощью локальной конфигурации можно:

• делать разные настройки для рабочих и личных репозиториев;
• управлять поведением Git в конкретном проекте;
• переопределять глобальные и системные настройки только там, где это нужно.

Давайте последовательно разберем, как работает git config --local, где хранится конфигурация, чем она отличается от глобальной и системной, и какие типичные настройки имеет смысл выносить именно в локальный уровень.

Уровни конфигурации Git и приоритеты

Основные уровни конфигурации

Git использует несколько уровней конфигурации:

1. Системный (system) — общие настройки для всей системы.
2. Глобальный (global) — настройки для текущего пользователя.
3. Локальный (local) — настройки для конкретного репозитория.
4. Временный (через переменные окружения и ключи команд) — действует только во время выполнения команды.

Важно понимать, как они «накладываются» друг на друга. Настройки с более «близкого» уровня переопределяют более «общие».

Приоритет такой (от самого слабого к самому сильному):

1. system
2. global
3. local
4. параметры команд и переменные окружения (например, GITAUTHORNAME)

Это значит, что если вы настроили user.name глобально, а затем задали другое user.name локально для репозитория, Git в этом репозитории будет использовать локальное значение.

Где хранятся конфигурации

Обратите внимание, в каких файлах Git хранит настройки:

• Системная:
  
  • в Linux и macOS обычно /etc/gitconfig
  • в Windows — что-то вроде C:\ProgramData\Git\config (зависит от установки)
• Глобальная (пользовательская):
  
  • в Linux и macOS ~/.gitconfig или ~/.config/git/config
  • в Windows C:\UsersВашПользователь.gitconfig
• Локальная (репозитория):
  
  • файл .git/config в корне конкретного репозитория

Смотрите, я покажу вам пример вывода всех уровней:

# Вывод всех уровней конфигурации, с указанием файла
git config --list --show-origin
# Комментарий:
# --list        - показать все параметры
# --show-origin - показать, из какого файла взят каждый параметр

Теперь вы увидите, как именно локальная конфигурация переопределяет глобальную.

Что делает git config --local

Краткое описание

Ключ --local в команде git config говорит Git: «работай только с локальным файлом конфигурации этого репозитория (.git/config)».

Команда вида:

git config --local user.name "Ivan Petrov"
# Комментарий:
# Устанавливаем локально имя пользователя только для текущего репозитория

записывает параметр user.name в .git/config текущего репозитория. В других репозиториях и в глобальной конфигурации это значение не изменится.

Если вы не передаете явно ни --system, ни --global, ни --local, Git по умолчанию использует локальный уровень, если команда выполняется внутри репозитория. То есть:

git config user.name "Ivan Petrov"
# Комментарий:
# Если вы находитесь внутри репозитория, это эквивалентно --local

Однако явное использование --local полезно:

• для наглядности (особенно в документации и скриптах);
• чтобы избежать путаницы, если вы случайно запускаете команду не из того каталога;
• в командах, где важно четко указать уровень.

Проверка локальной конфигурации

Чтобы вывести только локальные настройки, используйте:

git config --local --list
# Комментарий:
# Показать все настройки, которые записаны в .git/config текущего репозитория

Если вы запускаете эту команду вне репозитория, Git сообщит об ошибке, потому что локального файла .git/config просто нет.

Файл .git/config — структура и пример

Пример содержимого локального конфигурационного файла

Давайте посмотрим, как выглядит типичный .git/config:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true

[user]
    name = Ivan Petrov
    email = ivan.petrov@example.com

[remote "origin"]
    url = git@github.com:example/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "main"]
    remote = origin
    merge = refs/heads/main

Комментарии к этому примеру:

• секция [core] — базовые настройки репозитория;
• секция [user] — локальные значения имени и email;
• секция [remote "origin"] — конфигурация удаленного репозитория;
• секция [branch "main"] — настройки для конкретной ветки.

Хотя конфигурация хранится в ini-подобном формате, редактировать ее руками стоит аккуратно. Чаще используйте git config, чтобы избежать опечаток и некорректного форматирования.

Типичные сценарии использования локальной конфигурации

Разные user.name и user.email для разных проектов

Очень часто вы работаете с несколькими репозиториями:

• рабочие проекты (с корпоративным email);
• личные проекты (с личным email);
• open source (возможно, с другим именем или форматом email).

В этом случае удобно настроить глобальную конфигурацию «по умолчанию» и переопределить ее локально там, где нужно.

Пример настройки глобально:

git config --global user.name "Ivan Petrov"
git config --global user.email "ivan.personal@example.com"
# Комментарий:
# Это значения по умолчанию для всех репозиториев пользователя

Теперь переопределим их для рабочего проекта:

cd /path/to/work-project

git config --local user.name "Ivan Petrov Corp"
git config --local user.email "ivan.petrov@company.com"
# Комментарий:
# Эти значения будут использоваться только в этом репозитории

Проверим, что именно видит Git в этом репозитории:

git config user.name
git config user.email
# Комментарий:
# Без флага --local Git покажет "эффективное" значение
# с учетом переопределений между уровнями

Как видите, теперь вы можете безопасно коммитить изменения в рабочий репозиторий, не переживая, что коммиты будут подписаны личным email.

Специальные настройки для конкретного проекта

Иногда один проект требует специфических правил:

• другие параметры merge;
• работа исключительно через rebase;
• нестандартная политика форматирования сообщений коммитов;
• особые настройки для pull.

Давайте разберемся на примере.

Предположим, вы хотите, чтобы в конкретном репозитории git pull всегда выполнялся с rebase, а не с merge. Настроим это локально:

git config --local pull.rebase true
# Комментарий:
# В этом репозитории git pull будет выполнять rebase вместо merge

Теперь каждый раз при выполнении:

git pull
# Комментарий:
# В этом проекте по умолчанию будет происходить rebase

Git будет придерживаться локальной настройки pull.rebase, даже если глобально у вас настроен merge.

Еще пример — автоматическое исправление ошибок в командах только для одного репозитория:

git config --local help.autocorrect 10
# Комментарий:
# Если вы ошиблись в имени команды (например "git stauts")
# Git подождет 1.0 секунды и выполнит самую похожую команду ("git status")

Вы можете включить это только в одном репозитории, чтобы «потренироваться», не меняя поведение в остальных проектах.

Локальные алиасы команд

Алиасы Git позволяют создавать короткие псевдонимы для часто используемых команд. Они могут быть как глобальными, так и локальными.

Смотрите, я покажу вам пример локального алиаса для конкретного репозитория:

git config --local alias.st "status -sb"
# Комментарий:
# В этом репозитории команда "git st" будет выполнять "git status -sb"

Теперь, находясь в этом репозитории, вы можете написать:

git st
# Комментарий:
# Краткая форма для подробного статуса

Но в других репозиториях этот алиас не будет работать, если вы не настроите его там отдельно или глобально.

Это удобно, когда в одном проекте вы хотите специфическое поведение, например:

git config --local alias.lg "log --oneline --graph --decorate --all"
# Комментарий:
# В этом репозитории "git lg" покажет красивую историю коммитов в виде графа

Локальные настройки для конкретной команды внутри проекта

В больших монорепозиториях или специфичных проектах бывает полезно «тюнинговать» поведение Git только там. Например:

• включить или отключить автоконвертацию окончаний строк;
• настроить поведение при слиянии бинарных файлов;
• изменить стратегию merge.

Пример: отключим автоматическую конвертацию окончания строк только в одном проекте:

git config --local core.autocrlf false
# Комментарий:
# В этом репозитории Git не будет автоматически менять окончания строк

Это может быть важно, если проект уже настроен, например, через .gitattributes, и вы не хотите, чтобы глобальные настройки ломали форматирование.

Управление локальной конфигурацией: команды и приемы

Установка и изменение параметров (--local)

Основная форма команды:

git config --local <ключ> <значение>
# Комментарий:
# Устанавливаем параметр <ключ> в значение <значение> в файле .git/config

Примеры:

git config --local user.name "Ivan Petrov"
git config --local user.email "ivan.petrov@example.com"
git config --local core.editor "vim"
git config --local merge.ff false
# Комментарий:
# merge.ff false - запретить fast-forward merge по умолчанию в этом репозитории

Если параметр уже существует, он будет перезаписан.

Чтение значений локальной конфигурации

Чтобы получить конкретное значение, выполняйте:

git config --local user.name
# Комментарий:
# Покажет значение user.name, записанное именно в .git/config

Если такого параметра нет в локальной конфигурации, команда вернет ошибку выхода, а стандартный вывод будет пустым. Но запомните: без флага --local Git вернет «эффективное» значение, учитывая глобальный и системный уровни:

git config user.name
# Комментарий:
# Покажет значение user.name с учетом переопределений

Удаление локальных параметров

Иногда вам нужно удалить локально заданный параметр, чтобы вернуться к глобальному или системному значению. Для этого используйте флаг --unset:

git config --local --unset user.name
# Комментарий:
# Удаляем локальный user.name из .git/config

Теперь, если вы запросите:

git config user.name
# Комментарий:
# Git покажет глобальное (или системное) значение user.name, если оно задано

Если вы хотите удалить все значения параметра, который может встречаться несколько раз (например, несколько email), используйте --unset-all:

git config --local --unset-all user.email
# Комментарий:
# Удаляем все локальные значения user.email

Проверка и поиск параметров

Чтобы найти параметры, связанные с определенной темой, удобно воспользоваться фильтрацией:

git config --local --get-regexp "^user\."
# Комментарий:
# Покажет все локальные настройки user.* (user.name, user.email и т.д.)

Так вы быстро увидите, какие именно настройки для пользователя переопределены на локальном уровне.

Взаимодействие локальной конфигурации с глобальной и системной

Как понять, откуда взялся параметр

Иногда важно понять, почему Git ведет себя тем или иным образом. Для этого полезно посмотреть, из какого файла подхватывается тот или иной параметр.

Давайте посмотрим:

git config --show-origin user.name
# Комментарий:
# Покажет значение user.name и путь к файлу, откуда оно взято

Если вы хотите получить полную картину, используйте:

git config --list --show-origin
# Комментарий:
# Список всех параметров с указанием источника

Обратите внимание: если значение параметра переопределяется на нескольких уровнях, в итоговом списке вы увидите только «эффективное» значение (последнее по приоритету). Но его источник будет указан.

Типичная схема при конфликте настроек

Давайте посмотрим, как Git решит конфликт между уровнями.

Предположим:

• в /etc/gitconfig (system):
  user.name = System User
• в ~/.gitconfig (global):
  user.name = Global User
• в .git/config конкретного репозитория (local):
  user.name = Local User

В этом репозитории Git будет использовать:

git config user.name
# Эффективное значение: "Local User"

Если вы удалите локальный параметр:

git config --local --unset user.name

Теперь Git вернется к глобальному уровню:

git config user.name
# Эффективное значение: "Global User"

А если вы удалите и глобальный:

git config --global --unset user.name

Тогда останется только системный:

git config user.name
# Эффективное значение: "System User"

Так иерархия приоритетов постепенно «спускается» вниз.

Практические примеры локальных настроек

Настройка редактора только для одного репозитория

Представьте, что обычно вы используете один редактор, но в одном конкретном проекте вам удобнее работать с другим, например, из-за плагинов или интеграции с задачами.

Сделаем так:

git config --global core.editor "code --wait"
# Комментарий:
# Глобально используем VS Code как редактор для сообщений коммитов

cd /path/to/special-repo
git config --local core.editor "vim"
# Комментарий:
# Только в этом репозитории редактором будет vim

Теперь, когда вы будете делать:

git commit
# Комментарий:
# В этом репозитории сообщение коммита откроется в vim

в остальных же проектах все останется с VS Code.

Локальное управление окончанием строк

В кроссплатформенных проектах тема CRLF и LF встречается часто. Вы можете глобально включить core.autocrlf, но в некоторых проектах это может быть нежелательно.

Допустим, глобально:

git config --global core.autocrlf true
# Комментарий:
# В Windows Git будет конвертировать окончания строк в CRLF при checkout
# и обратно в LF при commit

Но в одном проекте это ломает тесты. Тогда внутри этого репозитория вы можете переопределить настройку:

cd /path/to/project
git config --local core.autocrlf false
# Комментарий:
# В этом проекте конвертации окончаний строк не будет

Теперь этот проект будет жить по своим локальным правилам, даже если глобальная конфигурация другая.

Локальные настройки безопасности и доступа

Иногда вам нужно задать специфичные настройки для работы с конкретным удаленным репозиторием:

• отдельный URL;
• особый транспорт;
• свои параметры для ssh.

Например, вы хотите в одном проекте явно указать использование определенного SSH-командного вызова:

git config --local core.sshCommand "ssh -i ~/.ssh/company_key"
# Комментарий:
# В этом репозитории Git будет использовать конкретный SSH ключ
# при работе с удаленным репозиторием

Теперь давайте посмотрим, как это влияет на взаимодействие:

git fetch origin
# Комментарий:
# Для подключения к origin будет использоваться указанная команда ssh

В других репозиториях эта настройка не действует и они используют вашу стандартную SSH-конфигурацию.

Переопределение стратегии слияния

В некоторых проектах команда может договориться использовать определенную стратегию merge только в этом репозитории.

Например, отключим fast-forward слияния:

git config --local merge.ff false
# Комментарий:
# В этом репозитории git merge будет всегда создавать merge commit,
# даже если можно обойтись fast-forward

Теперь, когда вы выполните:

git merge feature-branch
# Комментарий:
# Git создаст merge commit вместо простого перемещения указателя ветки

Эта политика будет действовать только в данном репозитории, не затрагивая ваши другие проекты.

Особенности и подводные камни локальной конфигурации

Работа вне репозитория

Ключевой момент: локальная конфигурация существует только там, где есть каталог .git. Если вы запускаете:

git config --local --list

из каталога, который не является репозиторием, вы получите ошибку вида:

• fatal: not in a git directory

Это логично: у Git просто нет локального файла .git/config. Поэтому, если вы пишете скрипты, всегда проверяйте, что команда запускается внутри репозитория.

Совместная работа и .git/config

Файл .git/config не коммитится в репозиторий. Он живет только локально на вашей машине. Это важно:

• вы не можете через .git/config распространять обязательные настройки для всей команды;
• каждый разработчик может иметь свой собственный .git/config в рамках одного и того же проекта.

Если вам нужно задать общие правила для всех (например, фильтры форматирования, атрибуты файлов и т.п.), используйте:

• файлы в рабочем дереве, которые коммитятся (.gitattributes, .gitignore);
• документацию по настройке .git/config для участников проекта, если нужны индивидуальные шаги.

Конфликт локальных и глобальных алиасов

Если вы создадите глобальный алиас и затем локальный с таким же именем, будет использован локальный.

Пример:

git config --global alias.st "status"
git config --local  alias.st "status -sb"

В этом репозитории:

git st
# Комментарий:
# Выполнится "git status -sb"

В других — просто git status. Это удобно, но может запутать, если вы забыли, что в одном проекте алиас работает иначе. Хорошая практика — использовать осмысленные названия алиасов и по возможности писать их в документации проекта.

Ручное редактирование .git/config

Иногда проще открыть .git/config в редакторе и внести правки. Это допустимо, но стоит быть аккуратным:

• не нарушайте структуру секций [section];
• следите за отступами (обычно это просто эстетика, но иногда помогает читабельности);
• не дублируйте ключи без необходимости.

Если вы сомневаетесь, лучше используйте git config:

git config --local user.name "New Name"
# Комментарий:
# Git корректно добавит или обновит значение в .git/config

Заключение

Локальная конфигурация Git через git config --local — это механизм тонкой настройки поведения Git для конкретных репозиториев. Она позволяет:

• переопределять глобальные и системные параметры там, где это действительно нужно;
• задавать разные имя и email для разных проектов;
• настраивать поведение merge, rebase, pull и других команд для отдельных репозиториев;
• создавать локальные алиасы и специфичные настройки безопасности.

Главная идея — разделять «общие» настройки (global, system) и настройки для конкретного проекта (local). Это помогает избежать неожиданных эффектов, когда изменение конфигурации для одного проекта внезапно влияет на все остальные.

Используйте git config --local, когда:

• вы настраиваете репозиторий под требования команды или проекта;
• вам нужно отличать рабочие и личные коммиты;
• необходимо специально настроить инструменты или стратегии работы с этим конкретным репозиторием.

И всегда помните про приоритеты: local переопределяет global и system, а параметры команд и переменные окружения могут временно переопределять все остальные уровни.

Частозадаваемые технические вопросы по теме и ответы

Вопрос 1. Как сделать так, чтобы в одном репозитории Git всегда использовал определенный ключ SSH, не меняя глобальные настройки?

Ответ: Настройте core.sshCommand локально:

git config --local core.sshCommand "ssh -i ~/.ssh/my_project_key"
# Комментарий:
# Теперь все операции fetch/push/pull в этом репозитории будут использовать указанный ключ

Проверьте соединение:

git ls-remote origin
# Комментарий:
# Если команда выполняется без ошибок, ключ используется корректно

---

Вопрос 2. Как посмотреть только те параметры, которые действительно переопределены локально, без учета глобальных?

Ответ: Используйте команду с флагом --local:

git config --local --list
# Комментарий:
# Покажет только настройки, записанные в .git/config

Если вы хотите сравнить с глобальными, отдельно выполните:

git config --global --list
# Комментарий:
# Так вы поймете, какие параметры различаются

---

Вопрос 3. Как сбросить все локальные настройки и начать «с чистого листа» для конфигурации репозитория?

Ответ: Самый простой способ — переименовать или удалить файл .git/config. Аккуратный вариант:

cd /path/to/repo
mv .git/config .git/config.backup
# Комментарий:
# Старый конфиг сохранен, можно вернуться к нему при необходимости

После этого можно заново задать необходимые параметры через git config. Если все работает корректно, старый файл можно удалить.

---

Вопрос 4. Как задать несколько значений для одного локального параметра, например, несколько email в одном репозитории?

Ответ: Используйте опцию --add вместо простой установки:

git config --local --add user.email "ivan.main@example.com"
git config --local --add user.email "ivan.alt@example.com"
# Комментарий:
# В .git/config появится несколько записей user.email

Посмотреть все значения можно так:

git config --local --get-all user.email
# Комментарий:
# Покажет все локальные email, заданные для этого репозитория

---

Вопрос 5. Как временно переопределить локальную настройку только для одной команды без изменения .git/config?

Ответ: Воспользуйтесь переменными окружения или флагами команды. Например, вы хотите разово изменить имя автора:

GIT_AUTHOR_NAME="Temp Name" GIT_AUTHOR_EMAIL="temp@example.com" git commit
# Комментарий:
# Эти значения будут использоваться только для этого коммита

Локальная конфигурация останется неизменной, а следующий коммит снова возьмет параметры из конфигурации.