Особенности настройки git под windows
Когда вы начнете работать с версией git под windows в командной строке, вы столкнётесь со следующей проблемой — все сообщения git, в которых фигурируют русские символы будут нечитаемы. Имена файлов, на русском языке, будут выглядеть так — «\362\345\361\362», а тексты коммитов примерно так — . Т.е. исходная строка преобразуется в utf8 в соответствии с кодировкой latin1.
Устранение проблем
Для примера я создал каталог rep на диске C:, создал в нем новый файл с именем тест и инициализировал новый репозиторий. После этого добавил в репозиторий все файлы из текущего каталога.
C:\rep>git init Initialized empty Git repository in C:/rep/.git/ C:\rep>git add .
Видно что файлы с русскими буквами, показываются не в той кодировке, в которой бы мы смогли их без проблем прочесть.
C:\rep>git status # On branch master # # Initial commit # # Untracked files: # (use "git add . " to include in what will be committed) # # "\362\345\361\362" nothing added to commit but untracked files present (use "git add" to track)
Чтобы исправить такое поведение git необходимо изменить параметр quotepath в секции [core], установив его в false.
quotepath = false
NB: Поменять можно либо глобальный файл настроек либо локальный.
Глобальный файл настроек находится здесь C:\Program Files\Git\etc\gitconfig, локальный в каталоге репозитория .git\config.
Следующая проблема возникает при редактировании описания коммита.
C:\rep>git commit -a -s
Если отредактировать и сохранить коммит в 8-битной кодировке, то появится следующее сообщение:
Warning: commit message does not conform to UTF-8. You may want to amend it after fixing the message, or set the config variable i18n.commitencoding to the encoding your project uses. [master (root-commit) cc05f8a] ╚эшЎшрышчрЎш яЁюхъЄр Signed-off-by: maslakov 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 "\362\345\361\362"
Соответственно необходимо указать кодировку в которой будут вносится описания коммитов, в секции [i18n], параметр commitencoding
commitencoding = cp1251
Третья проблема, которая возникает при работе с консольным интерфейсом git в это вывод лога:
C:\rep>git log
по умолчанию он выглядит так
commit cc05f8a470e8602ded60ba9c979c93148b334d4e Author: maslakov Date: Tue Nov 10 12:37:38 2009 +0300 Signed-off-by: maslakov
Как показало вскрытие в этом «виновата» утилита less, убедить её показывать текст правильно поможет установка переменной окружения LESSCHARSET=koi8-r или можно просто указать в качестве вьювера утилиту cat. Чтобы текст показывался постранично, передать вывод утилиты cat утилите more.
Кроме того необходимо задать параметр logoutputencoding в секции [i18n]
logoutputencoding = cp866
В принципе, после установки вышеуказанных настроек, основные проблемы использования национальных языков, в 8-битных кодировках, будут решены.
Вот мой файл \.git\config
[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true quotepath = false pager = cat|more.com editor = far -e [i18n] commitencoding = cp1251 logoutputencoding = cp866
Текст коммитов я редактирую в far, поэтому параметр editor у меня определен как far -e
Надеюсь кому-то данная информация будет полезна…
UPD: спасибо Алексею Шумкину за дополнение
ashu> я нашёл решение для less
http://www.linuxcenter.ru/lib/books/kostromin/gl_11_05.phtml
вкратце — нужно установить переменную окружения LESSCHARSET=koi8-r (у меня под Cygwin 1.5 заработало)
UPD2: спасибо hokum за дополнение
К сожалению, приведенные решения не помогли побороть проблему с выводом русских символов в выводе команд git diff, git show.
К установленному Git в каталог bin скопировал iconv.exe, а в конфиг Git’а прописал:
pager = iconv.exe -f cp1251 -t utf-8 | less
файлы проекта у меня соответственно в кодировке cp1251.
Файл iconv.exe можно найти скачав архив с бинарными файлами проекта iconv под Windows gnuwin32.sourceforge.net/packages/libiconv.htm.
Дополнительно к нему понадобяться dll:
libcharset1.dll
libiconv2.dll (у меня уже был в установке Git, заменять не стал)
libintl3.dll ( из архива Dependencies, оттуда же откуда качается iconv)
Нету файла .gitconfig, что делать?
Вчера впервые установил Git. Первые шаги делал руководствуясь сайтом GitHowTo, все получалось. Но тут столкнулся с проблемой. Нету файла .gtconfig там где он должен быть((
Как решить эту проблему?
- Вопрос задан более трёх лет назад
- 1777 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 2

Виктор @v_decadence
А где ищите?
Он либо в ~/.gitconfig (Linux), либо C:\Users\MyLogin\.gitconfig (Windows).
Создаётся он при первом использовании команды git config с флагом —global, наверно.

Чтобы имена нормально отображались, нужно выключить эту опцию
1.6 Введение — Первоначальная настройка Git
Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git под себя. Это нужно сделать только один раз — при обновлении версии Git настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.
В состав Git входит утилита git config , которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:
- Файл [path]/etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр —system , то параметры будут читаться и сохраняться именно в этот файл. Так как этот файл является системным, то вам потребуются права суперпользователя для внесения изменений в него.
- Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра —global и применяется ко всем репозиториям, с которыми вы работаете в текущей системе.
- Файл config в каталоге Git (т. е. .git/config ) репозитория, который вы используете в данный момент, хранит настройки конкретного репозитория. Вы можете заставить Git читать и писать в этот файл с помощью параметра —local , но на самом деле это значение по умолчанию. Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала правильно.
Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в [path]/etc/gitconfig .
В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME ( C:\Users\$USER для большинства пользователей). Кроме того, Git ищет файл [path]/etc/gitconfig , но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git при запуске инсталлятора.
Если вы используете Git для Windows версии 2.х или новее, то так же обрабатывается файл конфигурации уровня системы, который имеет путь C:\Documents and Settings\All Users\Application Data\Git\config в Windows XP или C:\ProgramData\Git\config в Windows Vista и новее. Этот файл может быть изменён только командой git config -f , запущенной с правами администратора.
Чтобы посмотреть все установленные настройки и узнать где именно они заданы, используйте команду:
$ git config --list --show-origin
Имя пользователя
Первое, что вам следует сделать после установки Git — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com
Опять же, если указана опция —global , то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе. Если для каких-то отдельных проектов вы хотите указать другое имя или электронную почту, можно выполнить эту же команду без параметра —global в каталоге с нужным проектом.
Многие GUI-инструменты предлагают сделать это при первом запуске.
Выбор редактора
Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно проделать следующее:
$ git config --global core.editor emacs
В системе Windows следует указывать полный путь к исполняемому файлу при установке другого текстового редактора по умолчанию. Пути могут отличаться в зависимости от того, как работает инсталлятор.
В случае с Notepad++, популярным редактором, скорее всего вы захотите установить 32-битную версию, так как 64-битная версия ещё не поддерживает все плагины. Если у вас 32-битная Windows или 64-битный редактор с 64-битной системой, то выполните следующее:
$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
Примечание
Vim, Emacs и Notepad++ — популярные текстовые редакторы, которые часто используются разработчиками как в Unix-подобных системах, таких как Linux и Mac, так и в Windows. Если вы используете другой редактор или его 32-битную версию, то обратитесь к разделу Команды git config core.editor за дополнительными инструкциями как использовать его совместно с Git.
Предупреждение
В случае, если вы не установили свой редактор и не знакомы с Vim или Emacs, вы можете попасть в затруднительное положение, когда какой-либо из них будет запущен. Например, в Windows может произойти преждевременное прерывание команды Git при попытке вызова редактора.
Настройка ветки по умолчанию
Когда вы инициализируете репозиторий командой git init , Git создаёт ветку с именем master по умолчанию. Начиная с версии 2.28, вы можете задать другое имя для создания ветки по умолчанию.
Например, чтобы установить имя main для вашей ветки по умолчанию, выполните следующую команду:
$ git config --global init.defaultBranch main
Проверка настроек
Если вы хотите проверить используемую конфигурацию, можете использовать команду git config —list , чтобы показать все настройки, которые Git найдёт:
$ git config --list user.name=John Doe user.email=johndoe@example.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto .
Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из /etc/gitconfig и ~/.gitconfig ). В таком случае Git использует последнее значение для каждого ключа.
Также вы можете проверить значение конкретного ключа, выполнив git config :
$ git config user.name John Doe
Примечание
Так как Git читает значение настроек из нескольких файлов, возможна ситуация когда Git использует не то значение что вы ожидали. В таком случае вы можете спросить Git об origin этого значения. Git выведет имя файла, из которого значение для настройки было взято последним:
$ git config --show-origin rerere.autoUpdate file:/home/johndoe/.gitconfig false
Git config где находится windows
- Object-oriented vs. functional programming explained While plenty of developers entertain the idea of adopting a functional programming model, it’s important to first know exactly .
- The 5 SOLID principles of object-oriented design explained In this primer on SOLID, we’ll examine the five principles this development ideology embodies, the practices they encourage and .
- How to make a strong business case for software projects Every software project proposal requires in-depth research into the technical aspects at play, but the business case for the .
- Create an open source security policy for your organization Using open source software raises concerns about security and intellectual property. Here’s how to make sound decisions and avoid.
- Conduct load tests with JMeter on Kubernetes Apache JMeter and other load-testing tools can be used with Kubernetes to conduct stress tests to see how well an app performs in.
- Don’t neglect API functional testing APIs are how applications connect to a database, partner servers and integrated applications. Testing their efficacy is an .
- 7 keys to an effective hybrid cloud migration strategy Cloud readiness, storage costs, network lag and metrics can make or break the choice to move data, applications and workloads to .
- 8 hybrid cloud security challenges and how to manage them Hybrid cloud’s benefits are many and varied but so are the security issues surrounding integration, compatibility, governance, .
- Pros and cons of 10 common hybrid cloud use cases For businesses contemplating the advantages and disadvantages of their applications living in a distributed cloud infrastructure.
- How to become an incident responder: Requirements and more Incident response is a growth area that provides career advancement options and a good salary. Here’s an in-depth look at job .
- How to create an incident response playbook Using an incident response playbook can speed up an organization’s responses to cyberattacks. Find out how to build repeatable .
- 10 of the biggest zero-day attacks of 2023 There were many zero-day vulnerabilities exploited in the wild in 2023. Here’s a look at 10 of the most notable and damaging .
- AWS Control Tower aims to simplify multi-account management Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates .
- Break down the Amazon EKS pricing model There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service .
- Compare EKS vs. self-managed Kubernetes on AWS AWS users face a choice when deploying Kubernetes: run it themselves on EC2 or let Amazon do the heavy lifting with EKS. See .