Настройка редактора в Git с помощью git config core.editor

27 марта 2026

Автор

Олег Марков

Введение

Настройка редактора через параметр git config core.editor определяет, в каком приложении вы будете редактировать сообщения коммитов, тексты для git rebase -i, сообщения тегов и другие служебные файлы Git. Если выбрать редактор неудачно или настроить его неправильно, вы можете столкнуться с неприятными ситуациями: коммиты без сообщений, зависшие процессы Git или странное поведение при интерактивном rebase.

В этой статье вы увидите, как именно Git использует редактор, как задать его один раз на всю систему, как настроить разные редакторы под разные задачи и как избежать типичных ошибок (например, когда редактор запускается, но Git "ждет бесконечно").

Давайте последовательно разберем, как работает core.editor, как задать корректную команду для разных редакторов (Vim, Nano, VS Code, IntelliJ IDEA, Notepad++ и других), а затем разберем типичные проблемы и пути их решения.

Что такое core.editor и как Git использует редактор

Когда Git вообще запускает редактор

Параметр core.editor отвечает за команду редактора, которую Git запускает в интерактивных сценариях. Чаще всего вы сталкиваетесь с ним в таких ситуациях:

git commit без флага -m
Git открывает редактор для ввода сообщения коммита.
git commit --amend без -m
Открывается редактор для изменения существующего сообщения.
git rebase -i
Открывается файл со списком коммитов, где вы редактируете действия (pick, squash, edit и т.д.).
git tag -a v1.0
Откроется редактор для ввода аннотированного описания тега.
git merge (в определенных ситуациях)
При конфликте может открываться редактор для сообщения merge-коммита.
Некоторые скрипты-хуки Git (например, commit-msg) тоже могут вызывать редактор.

Важно понимать, что Git:

Создает временный файл (например, с шаблоном сообщения).
Запускает команду редактора и передает этому редактору путь к файлу.
Ждет, пока процесс редактора завершится.
Считывает содержимое файла после закрытия редактора.

Если редактор не блокирует терминал (например, запускается в фоне и не "держит" процесс), Git будет считать, что вы закончили редактирование, хотя окно редактора еще открыто. Это основа многих проблем с настройкой core.editor. Чуть позже мы разберем, как правильно учитывать это поведение.

Порядок поиска редактора Git

Перед тем как запускать редактор, Git идет по такому пути:

Проверяет переменную окружения GIT_EDITOR.
Если не задана, проверяет core.editor из настроек git config.
Если не найдено, смотрит переменную окружения VISUAL, а затем EDITOR.
Если и их нет, падает обратно на стандартное поведение (зависит от системы: часто это Vim на Linux, Notepad на Windows и т.д.).

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

Основы git config core.editor

Где хранится настройка core.editor

Настройки Git расположены в нескольких уровнях:

Глобальные (для пользователя) — файл ~/.gitconfig или ~/.config/git/config.
Системные — обычно /etc/gitconfig (зависят от ОС).
Локальные (для конкретного репозитория) — файл .git/config в корне репозитория.

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

git config --global core.editor "nano"
# Здесь мы задаем редактор nano для всех репозиториев текущего пользователя

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

git config core.editor "vim"
# Эта настройка попадет в .git/config конкретного репозитория

Чтобы посмотреть текущую настройку:

git config core.editor
# Здесь Git выведет строку команды редактора, если она задана

Если вы хотите увидеть, откуда взялась настройка (и все уровни конфигов):

git config --show-origin core.editor
# Здесь Git покажет путь к файлу конфигурации, где определен core.editor

Формат значения core.editor

Параметр core.editor — это не просто имя программы, а полноценная команда, которую Git запускает через оболочку (shell). Смотрите, я покажу вам базовый пример:

git config --global core.editor "vim"
# Здесь Git будет запускать команду 'vim <файл>'

Можно указывать:

Полный путь к бинарю:

git config --global core.editor "/usr/bin/nano"
# Здесь мы явно указываем путь к бинарному файлу nano

Команду с аргументами:

git config --global core.editor "vim -n"
# Здесь мы запускаем vim без swap-файлов (опция -n)

Команду из нескольких слов с кавычками:

git config --global core.editor "code --wait"
# Здесь 'code' - команда VS Code, '--wait' - флаг ожидания закрытия окна

Основное требование: команда должна завершаться только после того, как вы закончите редактирование файла, иначе Git посчитает, что работа над файлом закончена слишком рано.

Настройка популярных редакторов

Теперь давайте пройдемся по реальным примерам. Ниже вы увидите, как настроить самые популярные редакторы в Linux, macOS и Windows.

Vim

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

Простой вариант

git config --global core.editor "vim"
# Здесь Git будет открывать vim в текущем терминале

С дополнительными параметрами

Например, вы хотите отключить создание swap-файлов и открыть файл в режиме без совместимости:

git config --global core.editor "vim -n -c 'set nocompatible'"
# -n    выключает swap
# -c    выполняет команду Vim при старте (здесь: set nocompatible)

Обратите внимание, что внутри строки есть одинарные кавычки. В Windows в Git Bash может потребоваться немного другой синтаксис (двойные кавычки вокруг всего выражения, а внутри экранировать кавычки или использовать другой способ задания опций).

Nano

Nano удобен для новичков: он прост, показывает подсказки по управлению внизу, и его легко закрыть.

Глобальная настройка Nano

git config --global core.editor "nano"
# Теперь Git при коммитах и rebase будет запускать nano

Если вы хотите включить переноси строк, подсветку и т.п., вы можете указать конфигурационный файл Nano, но на уровне core.editor это делается редко. Часто такие настройки задают в ~/.nanorc.

Пример с параметрами (демонстрационный):

git config --global core.editor "nano --nowrap"
# Параметр --nowrap отключает автоматический перенос строк

VS Code

VS Code — один из самых частых редакторов у разработчиков. Здесь очень важно добавить флаг ожидания, чтобы Git не продолжил работу до закрытия окна.

Linux и Windows (если команда `code` доступна в PATH)

git config --global core.editor "code --wait"
# --wait говорит VS Code не возвращать управление, пока файл не закрыт

macOS через `open`

Если у вас нет команды code в PATH, но VS Code установлен стандартно, вы можете сделать так:

git config --global core.editor "open -W -n -a 'Visual Studio Code'"
# -W   ждать завершения приложения
# -n   открыть новое окно, если уже запущен
# -a   указать конкретное приложение

Но обычно проще один раз установить code в PATH из самого VS Code и использовать code --wait. В VS Code это делается через командную палитру: Command Palette → Shell Command → Install 'code' command in PATH.

Visual Studio Code Insiders

Если вы используете Insiders-версию, команда будет другой:

git config --global core.editor "code-insiders --wait"
# Здесь мы явно используем бинарь code-insiders

IntelliJ IDEA и другие IDE JetBrains

IDE JetBrains не всегда удобно использовать как редактор сообщений Git, но иногда это нужно.

Linux (пример)

git config --global core.editor "idea.sh"
# Здесь мы указываем скрипт запуска IDEA

Но есть нюанс: многие IDE JetBrains не блокируют консоль до закрытия редактора. В таком случае Git может вернуться сразу. Более надежный вариант — использовать встроенный в IDE механизм работы с Git, а не вызывать IDE через core.editor.

Для случаев, когда IDE поддерживает параметр "ждать", можно использовать скрипт-обертку, но это уже больше про вашу конкретную IDE и окружение. Здесь я помечу важную мысль: многие IDE не подходят в роли core.editor именно из-за отсутствия блокирующего режима.

Notepad и Notepad++

Windows — стандартный Блокнот (Notepad)

По умолчанию Git для Windows часто использует встроенный текстовый редактор (Notepad). Если вы хотите указать его явно:

git config --global core.editor "notepad.exe"
# Стандартный блокнот Windows; Git дождется его закрытия

Windows — Notepad++

Notepad++ — популярный редактор под Windows. Главное — включить опцию ожидания (-multiInst и -notabbar тут не обязательны, но иногда помогают).

git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"
# Здесь мы указываем полный путь к notepad++.exe
# -multiInst   запускать отдельный процесс
# -nosession   не восстанавливать предыдущую сессию

Если у вас пробелы в пути, обязательно оборачивайте весь путь в кавычки. Обратите внимание: в Git Bash иногда удобнее использовать прямые слэши, как в примере выше.

Sublime Text

Sublime Text тоже часто используют в роли редактора Git.

Linux / macOS с командой subl

git config --global core.editor "subl -n -w"
# -n   открыть новое окно
# -w   ждать закрытия файла (важно для Git)

Windows

git config --global core.editor "'C:/Program Files/Sublime Text/subl.exe' -n -w"
# Здесь мы указываем путь к бинарю Sublime и флаги -n -w

Emacs

Для любителей Emacs все тоже достаточно просто.

git config --global core.editor "emacs"
# Git откроет Emacs в терминале (emacs-nox)

Если вы хотите открыть графическую версию Emacs и при этом Git должен ждать:

git config --global core.editor "emacsclient -c -a emacs"
# emacsclient -c   открыть новое окно
# -a emacs         запустить Emacs, если он еще не запущен

В этом случае вам нужно убедиться, что Emacs настроен на работу с emacsclient (обычно это делается в init-файле Emacs).

Как проверить, что core.editor работает правильно

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

Простой тест через git commit

Создайте тестовый репозиторий, сделайте файл и попробуйте закоммитить:

mkdir editor-test
cd editor-test
git init
# Создаем простой файл
echo "test" > file.txt
git add file.txt

# Запускаем коммит без -m, чтобы открылся редактор
git commit
# Здесь Git должен открыть ваш настроенный редактор

После закрытия редактора:

Если вы ввели сообщение и сохранили файл, коммит должен завершиться успешно.
Если вы удалили все строки или оставили только комментарии (начинающиеся с #), Git, скорее всего, отменит коммит с сообщением, что сообщение пустое.

Проверка через rebase -i

Чтобы проверить работу редактора для интерактивного rebase, сделайте несколько коммитов:

echo "1" > a.txt
git add a.txt
git commit -m "First"

echo "2" >> a.txt
git add a.txt
git commit -m "Second"

echo "3" >> a.txt
git add a.txt
git commit -m "Third"

# Теперь запускаем интерактивный rebase
git rebase -i HEAD~3
# Здесь Git должен открыть редактор со списком трех коммитов

Если редактор открывается, вы видите строки вида:

pick <hash1> First
pick <hash2> Second
pick <hash3> Third
# Комментарии ниже...

И все работает корректно — ваша настройка core.editor в порядке.

Особенности кроссплатформенной настройки

Разные пути к бинарям

На Linux и macOS путь к бинарю часто прост:

/usr/bin/vim
/usr/bin/nano
/usr/local/bin/code
и т.п.

На Windows же путь к программе может включать пробелы и разные каталоги, например:

C:\Program Files\VS Code\Code.exe
C:\Program Files\Notepad++\notepad++.exe

Чтобы команда работала везде, обычно:

Для Linux/macOS достаточно имени бинаря, если он в PATH: code, vim, nano.
Для Windows иногда лучше явно задавать путь в кавычках.

Давайте разберемся на примере VS Code в Windows:

git config --global core.editor "'C:/Users/Имя/AppData/Local/Programs/Microsoft VS Code/Code.exe' --wait"
# Здесь мы указываем полный путь к Code.exe и добавляем флаг --wait

Кавычки вокруг пути важны, так как в пути есть пробелы (Microsoft VS Code).

Git Bash vs CMD vs PowerShell

На Windows Git часто используется внутри Git Bash, но команда git config будет одинаковой. Разница может быть только в том, как трактуются кавычки и слэши:

В Git Bash удобно использовать пути вида C:/Program Files/....
В CMD / PowerShell — чаще C:\Program Files..., но иногда это не критично.

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

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

Работа с переменными GIT_EDITOR, VISUAL и EDITOR

core.editor — не единственный механизм выбора редактора. Иногда удобнее использовать переменные окружения, особенно если вы хотите временно поменять редактор только на одну команду.

GIT_EDITOR

GIT_EDITOR имеет наивысший приоритет для Git. Ее можно использовать для временной подмены:

GIT_EDITOR="nano" git commit
# Здесь только для этой команды git commit Git использует nano

Комментарии:

Настройка core.editor при этом не игнорируется навсегда, только на время этой команды.
После завершения команда GIT_EDITOR не сохраняется (если вы задали ее только перед командой).

VISUAL и EDITOR

Если GIT_EDITOR и core.editor не заданы, Git смотрит переменные VISUAL, затем EDITOR. Это историческое поведение, и многие системы задают эти переменные (например, через .bashrc).

Настройка в Linux может выглядеть так:

export EDITOR="vim"
# Здесь мы говорим всем программам, что используем vim по умолчанию

После этого Git, не имея core.editor, будет использовать vim.

Если вы хотите единую настройку сразу для всех программ (crontab, редакторы сообщений и т.д.), переменные окружения — хороший вариант. Если хотите конфигурировать только Git, — удобнее core.editor.

Частые проблемы и их решения

Теперь давайте посмотрим на типичные проблемы, которые возникают при настройке core.editor, и как их решать.

Проблема 1. Редактор открывается, но Git "не ждет"

Чаще всего это происходит с GUI-редакторами и IDE (VS Code, Sublime, Notepad++, IntelliJ).

Симптомы:

Запускаете git commit.
Открывается окно редактора.
Но в терминале Git сразу завершает коммит или выдает ошибку.
Иногда коммит фиксируется без сообщения или с тем, что было в файле до редактирования.

Причина:

Команда редактора завершается сразу (например, процесс-обертка запускает отдельный процесс и сам завершает работу).
Git думает, что редактирование закончено, хотя окно редактора еще открыто.

Решение:

Ищите флаг "wait" или аналогичный для вашего редактора:
- VS Code — --wait.
- Sublime Text — -w.
- Многие IDE этого не имеют вообще.
Убедитесь, что вы вызываете именно "клиент", который может ждать, а не простой launcher.

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

git config --global core.editor "code --wait"
# VS Code: обязательно --wait

git config --global core.editor "subl -n -w"
# Sublime: -w заставляет ждать закрытия

Проблема 2. Git пишет "There was a problem with the editor"

Симптомы:

После запуска git commit или git rebase -i вы видите ошибку:
- error: There was a problem with the editor '...'
Редактор может даже не открыться.

Причины:

Неправильный путь к редактору.
Команда редактора завершается с ненулевым кодом выхода.
Shell не может правильно разобрать строку (проблемы с кавычками).

Шаги для диагностики:

Посмотрите текущую настройку:

git config core.editor
# Проверьте, нет ли опечаток и битых кавычек

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

code --wait somefile.txt
# Здесь вы проверяете, действительно ли команда запускает редактор без ошибок

Если команда содержит полный путь, убедитесь, что он корректен (особенно в Windows — проверьте разрядность Program Files / Program Files (x86)).

Если вы не уверены, временно задайте простой редактор (nano, vim) и проверьте, что Git в принципе работает:

git config --global core.editor "nano"
# Если с nano все работает, ошибка в предыдущей команде редактора

Проблема 3. Пустые сообщения коммитов

Симптомы:

Вы открываете редактор, пишете текст, закрываете окно.
Git сообщает, что "Aborting commit due to empty commit message" или просто не делает коммит.

Причины:

Вы случайно оставили строку в виде комментария (начинается с #).
В файле не осталось ни одной "не закомментированной" строки.
Редактор сохранил файл в другой кодировке / с необычными символами — редко, но случается.

Что проверить:

В сообщении коммита хотя бы одна строка не должна начинаться с #.
Убедитесь, что вы именно сохраняете файл (в Vim это :wq, в Nano — Ctrl+O, затем Ctrl+X).
Проверьте, что у вас нет автодополнения, которое перезаписывает файл при закрытии.

Проблема 4. Редактор не открывается вообще

Симптомы:

При git commit Git зависает или сразу выдает ошибку.
Вы не видите окно редактора.

Проверки:

Попробуйте задать самый простой редактор, который точно есть на системе:
- Linux/macOS: nano или vi.
- Windows: notepad.exe.
```
git config --global core.editor "nano"
# Если с nano все заработало, проблема была в предыдущей команде
```

Проверьте переменные GIT_EDITOR, VISUAL, EDITOR. Иногда они могут переопределять вашу настройку core.editor:

echo "$GIT_EDITOR"
echo "$VISUAL"
echo "$EDITOR"
# Если там что-то есть, попробуйте временно очистить или изменить

Если вы работаете под WSL (Windows Subsystem for Linux), убедитесь, что ваш редактор действительно установлен внутри WSL, а не только на Windows-хосте.

Дополнительные техники и советы

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

Если вы часто переключаетесь между разными редакторами (например, в терминале удобнее Vim, а для сложных rebase вы предпочитаете VS Code), вы можете завести alias-ы:

git config --global alias.vim-editor "config --global core.editor vim"
git config --global alias.code-editor "config --global core.editor 'code --wait'"
# Теперь вы можете быстро переключаться:
# git vim-editor
# git code-editor

Обратите внимание: это alias-ы не для операций с репозиторием, а для настройки Git. Их удобно использовать, когда вы экспериментируете с редакторами.

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

Иногда внутри одного проекта вам нужен специфический редактор (например, интегрированный в IDE). В этом случае настройка делается без флага --global:

git config core.editor "code --wait"
# Эта настройка будет записана в .git/config только текущего репозитория

Для другого проекта вы можете оставить глобальную настройку (например, Vim), а в этом проекте использовать другой редактор.

Просмотр и ручное редактирование gitconfig

Вы можете вручную открыть файл с настройками Git в любом редакторе и посмотреть раздел [core].

Пример глобального файла ~/.gitconfig:

[core]
    editor = vim
    autocrlf = input
# Здесь мы видим, что editor = vim

Вы можете отредактировать строку editor = ... вручную, но осторожнее с синтаксисом: не добавляйте лишних символов и следите за отступами.

Настройка git config core.editor — простой по форме, но важный по эффекту шаг. От него зависит, насколько комфортно вы будете работать с коммитами, rebase и другими операциями в Git. Понимание того, как именно Git запускает редактор, как он ждет его закрытия и какие флаги нужно добавить для разных редакторов, помогает избежать множества мелких, но раздражающих проблем.

Если вы начнете с простого консольного редактора (nano или vim), а затем аккуратно настроите любимый GUI-редактор с правильным набором флагов (--wait, -w и аналогичные), вы получите удобный и предсказуемый рабочий процесс.

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

Как сделать так, чтобы для commit использовался один редактор, а для rebase - другой

Напрямую в Git разделить редактор по типам операций нельзя, но можно использовать обертку-скрипт. Например, создайте скрипт git-editor.sh:

#!/bin/sh
# Если первый аргумент содержит "COMMIT_EDITMSG" - используем один редактор
case "$1" in
  *COMMIT_EDITMSG*)
    nano "$1"     # Здесь nano для сообщений коммита
    ;;
  *)
    code --wait "$1"   # Здесь VS Code для остальных случаев
    ;;
esac

Сделайте его исполняемым и укажите в core.editor:

git config --global core.editor "/полный/путь/git-editor.sh"

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

Как полностью сбросить настройку core.editor и вернуться к поведению по умолчанию

Выполните:

git config --global --unset core.editor
# Удаляет глобальную настройку
git config --system --unset core.editor
# При необходимости уберите системную
git config --unset core.editor
# Уберите локальную для текущего репозитория

После этого Git будет искать редактор в GIT_EDITOR, VISUAL, EDITOR и своих дефолтах. Можно проверить:

git config --show-origin core.editor
# Если ничего не выводит - настройка снята

Как настроить разные редакторы для разных пользователей на одной машине

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

git config --global core.editor "nano"
# Выполните под одним пользователем

git config --global core.editor "code --wait"
# Выполните под другим пользователем

Системный конфиг (--system) лучше не трогать или оставлять там только базовый редактор.

Можно ли использовать окружение WSL для редактора при работе с Git for Windows

Можно, но это усложняет схему. Проще настроить редактор отдельно в WSL и отдельно в Git for Windows. Если нужно именно пересечение, используйте редактор, доступный и из Windows, и из WSL (например, VS Code через code.exe) и указывайте соответствующую команду в core.editor в каждом окружении.

Как открыть уже созданное сообщение коммита повторно в выбранном редакторе

Если вы хотите отредактировать последнее сообщение коммита тем же редактором, который настроен в core.editor, просто используйте:

git commit --amend
# Git откроет редактор с текущим сообщением, вы сможете его изменить

Если нужно другое сообщение без изменения содержимого коммита (только текст), добавьте --no-edit, но это как раз пропускает открытие редактора, так что для редактирования текста --amend без --no-edit — правильный путь.