Где находится файл gitconfig
Обновлено: 04.07.2024
Git рассматривает каждый файл в вашей рабочей копии как файл одного из трех нижеуказанных типов.
- Отслеживаемый файл — файл, который был предварительно проиндексирован или зафиксирован в коммите.
- Неотслеживаемый файл — файл, который не был проиндексирован или зафиксирован в коммите.
- Игнорируемый файл — файл, явным образом помеченный для Git как файл, который необходимо игнорировать.
Игнорируемые файлы — это, как правило, артефакты сборки и файлы, генерируемые машиной из исходных файлов в вашем репозитории, либо файлы, которые по какой-либо иной причине не должны попадать в коммиты. Вот некоторые распространенные примеры таких файлов:
- кэши зависимостей, например содержимое /node_modules или /packages ;
- скомпилированный код, например файлы .o , .pyc и .class ;
- каталоги для выходных данных сборки, например /bin , /out или /target ;
- файлы, сгенерированные во время выполнения, например .log , .lock или .tmp ;
- скрытые системные файлы, например .DS_Store или Thumbs.db ;
- личные файлы конфигурации IDE, например .idea/workspace.xml .
Игнорируемые файлы отслеживаются в специальном файле .gitignore , который регистрируется в корневом каталоге репозитория. В Git нет специальной команды для указания игнорируемых файлов: вместо этого необходимо вручную отредактировать файл .gitignore , чтобы указать в нем новые файлы, которые должны быть проигнорированы. Файлы .gitignore содержат шаблоны, которые сопоставляются с именами файлов в репозитории для определения необходимости игнорировать эти файлы.
Шаблоны игнорирования в Git
Для сопоставления с именами файлов в .gitignore используются шаблоны подстановки. С помощью различных символов можно создавать собственные шаблоны.
Две звездочки (**) означают, что ваш файл .gitignore находится в каталоге верхнего уровня вашего репозитория, как указано в соглашении. Если в репозитории несколько файлов .gitignore, просто мысленно поменяйте слова «корень репозитория» на «каталог, содержащий файл .gitignore» (и подумайте об объединении этих файлов, чтобы упростить работу для своей команды)*.
Если у вас есть файлы или каталоги, в имени которых содержатся спецсимволы шаблонов, для экранирования этих спецсимволов в .gitignore можно использовать обратную косую черту (\):
Общие файлы .gitignore в вашем репозитории
Обычно правила игнорирования Git задаются в файле .gitignore в корневом каталоге репозитория. Тем не менее вы можете определить несколько файлов .gitignore в разных каталогах репозитория. Каждый шаблон из конкретного файла .gitignore проверяется относительно каталога, в котором содержится этот файл. Однако проще всего (и этот подход рекомендуется в качестве общего соглашения) определить один файл .gitignore в корневом каталоге. После регистрации файла .gitignore для него, как и для любого другого файла в репозитории, включается контроль версий, а после публикации с помощью команды push он становится доступен остальным участникам команды. В файл .gitignore , как правило, включаются только те шаблоны, которые будут полезны другим пользователям репозитория.
Персональные правила игнорирования в Git
В специальном файле, который находится в папке .git/info/exclude , можно определить персональные шаблоны игнорирования для конкретного репозитория. Этот файл не имеет контроля версий и не распространяется вместе с репозиторием, поэтому он хорошо подходит для указания шаблонов, которые будут полезны только вам. Например, если у вас есть пользовательские настройки для ведения журналов или специальные инструменты разработки, которые создают файлы в рабочем каталоге вашего репозитория, вы можете добавить их в .git/info/exclude , чтобы они случайно не попали в коммит в вашем репозитории.
Глобальные правила игнорирования в Git
Кроме того, для всех репозиториев в локальной системе можно определить глобальные шаблоны игнорирования Git, настроив параметр конфигурации Git core.excludesFile . Этот файл нужно создать самостоятельно. Если вы не знаете, куда поместить глобальный файл .gitignore , расположите его в домашнем каталоге (потом его будет легче найти). После создания этого файла необходимо настроить его местоположение с помощью команды git config :
Будьте внимательны при указании глобальных шаблонов игнорирования, поскольку для разных проектов актуальны различные типы файлов. Типичные кандидаты на глобальное игнорирование — это специальные файлы операционной системы (например, .DS_Store и thumbs.db ) или временные файлы, создаваемые некоторыми инструментами разработки.
Игнорирование ранее закоммиченного файла
Чтобы игнорировать файл, для которого ранее был сделан коммит, необходимо удалить этот файл из репозитория, а затем добавить для него правило в .gitignore . Используйте команду git rm с параметром --cached , чтобы удалить этот файл из репозитория, но оставить его в рабочем каталоге как игнорируемый файл.
Опустите опцию --cached , чтобы удалить файл как из репозитория, так и из локальной файловой системы.
Коммит игнорируемого файла
Можно принудительно сделать коммит игнорируемого файла в репозиторий с помощью команды git add с параметром -f (или --force ):
Этот способ хорош, если у вас задан общий шаблон (например, *.log ), но вы хотите сделать коммит определенного файла. Однако еще лучше в этом случае задать исключение из общего правила:
Этот подход более прозрачен и понятен, если вы работаете в команде.
Скрытие изменений в игнорируем файле
Команда git stash — это мощная функция системы Git, позволяющая временно отложить и отменить локальные изменения, а позже применить их повторно. По умолчанию команда git stash ожидаемо не обрабатывает игнорируемые файлы и создает отложенные изменения только для тех файлов, которые отслеживаются Git. Тем не менее вы можете вызвать команду git stash с параметром --all, чтобы создать отложенные изменения также для игнорируемых и неотслеживаемых файлов.
Отладка файлов .gitignore
Если шаблоны .gitignore сложны или разбиты на множество файлов .gitignore , бывает непросто отследить, почему игнорируется определенный файл. Используйте команду git check-ignore с параметром -v (или --verbose ), чтобы определить, какой шаблон приводит к игнорированию конкретного файла:
При желании команде git check-ignore можно передать несколько имен файлов, причем сами имена могут даже не соответствовать файлам, существующим в вашем репозитории.
До этого момента мы описывали основы того, как Git работает и как его использовать, а так же мы познакомились с некоторыми инструментами Git, которые делают его использование простым и эффективным. В этой главе мы рассмотрим некоторые настройки Git и систему хуков, что позволяет настроить поведение Git. Таким образом, вы сможете заставить Git работать именно так как нужно вам или вашей компании.
Конфигурация Git
В главе Введение кратко упоминалось, что вы можете настроить Git, используя команду git config . Первое, что вы делали, это установили своё имя и e-mail адрес:
Сейчас вы познакомитесь с несколькими наиболее интересными опциями, которые можно установить для настройки поведения Git.
Кратко: Git использует набор конфигурационных файлов для изменения стандартного поведения, если это необходимо. Вначале, Git ищет настройки в файле /etc/gitconfig , который содержит настройки для всех пользователей в системе и всех репозиториев. Если передать опцию --system команде git config , то операции чтения и записи будут производиться именно с этим файлом.
Следующее место, куда смотрит Git — это файл
/.config/git/config ), который хранит настройки конкретного пользователя. Вы можете указать Git читать и писать в него, используя опцию --global .
Наконец, Git ищет параметры конфигурации в файле настроек в каталоге Git ( .git/config ) текущего репозитория. Эти значения относятся только к текущему репозиторию и доступны при передаче параметра --local команде git config . (Если уровень настроек не указан явно, то подразумевается локальный.)
Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из .git/config важнее значений из /etc/gitconfig .
Конфигурация Git это обычные текстовые файлы, поэтому можно вручную установить необходимые значения используя соответствующий синтаксис. Как правило, это проще чем вызывать команду git config для каждого параметра.
Базовая конфигурация клиента
Конфигурационные параметры Git разделяются на две категории: настройки клиента и настройки сервера. Большая часть — клиентские, для настройки ваших личных предпочтений в работе. Существует много, очень много настроек, но подавляющее большинство из них применимо только в конкретных случаях; мы рассмотрим только самые основные и самые полезные из них. Для просмотра полного списка настроек, поддерживаемых вашей версией Git, выполните команду:
core.editor
commit.template
Например, предположим что вы создали файл
/.gitmessage.txt , который выглядит так:
Чтобы заставить Git отображать содержимое этого файла в редакторе каждый раз при выполнении команды git commit , следует установить значение параметра commit.template :
core.pager
Данная настройка определяет какая программа будет использована для разбиения текста на страницы при выводе такой информации как log и diff . Вы можете указать more или любую другую (по умолчанию используется less ), а так же выключить совсем, установив пустое значение:
В таком случае, Git будет выводить весь текст полностью, вне зависимости от его длины.
user.signingkey
Если вы создаёте подписанные аннотированные теги (как описано в разделе Подпись главы 7), то установка GPG ключа в настройках облегчит вам задачу. Установить ключ можно следующим образом:
Теперь, вам не нужно указывать ключ для подписи каждый раз при вызове команды git tag :
core.excludesfile
В разделе Игнорирование файлов главы 2 сказано, что вы можете указывать шаблоны исключений в файле .gitignore вашего проекта, чтобы Git не отслеживал их и не добавлял в индекс при выполнении команды git add .
Однако, иногда вам нужно игнорировать определенные файлы во всех ваших репозиториях. Если на вашем компьютере работает Mac OS X, вероятно вы знакомы с файлами .DS_Store . Если вы используете Emacs или Vim, то вы знаете про файлы, имена которых заканчиваются на
Данная настройка позволяет вам определить что-то вроде глобального файла .gitignore . Если вы создадите файл
/.gitignore_global с содержанием:
… и выполните команду git config --global core.excludesfile
/.gitignore_global , то Git больше не потревожит вас на счёт этих файлов.
help.autocorrect
Если вы ошибётесь в написании команды, Git покажет вам что-то вроде этого:
Git старается угадать, что вы имели ввиду, но при этом команду не выполняет. Если вы установите help.autocorrect в значение 1, то Git будет выполнять эту команду:
Обратите внимание, что команда выполнилась через «0.1» секунды. help.autocorrect — это число, указываемое в десятых долях секунды. Поэтому, если вы установите значение 50, то Git даст вам 5 секунд изменить своё решение перед тем, как выполнить скорректированную команду.
Цвета в Git
Git полностью поддерживает цветовой вывод в терминале, что позволяет быстро и легко визуально анализировать вывод команд. Существует несколько опций для настройки цветов.
color.ui
Git автоматически подсвечивает большую часть своего вывода, но это можно отключить, если вам не нравится такое поведение. Для отключения цветового вывода в терминал, выполните следующую команду:
Значение по умолчанию — auto , при котором цвета используются при непосредственном выводе в терминал, но исключаются при перенаправлении вывода в именованный канал или файл.
Вы так же можете установить значение always , что делает вывод одинаковым как в терминал, так и в именованный канал. Скорее всего, вам это не понадобится; в большинстве случаев, при желании использовать цвета в перенаправленном выводе, указывается флаг --color команде Git для принудительного использования цветовых кодов. Практически всегда стандартное значение подходит лучше всего.
color.*
Если вы хотите явно указать вывод каких команд должен быть подсвечен и как, Git предоставляет соответствующие настройки. Каждая из них может быть установлена в значения true , false или always :
Каждая из них имеет вложенную конфигурацию, которую можно использовать для настройки отдельных частей вывода при желании переопределить их цвет. Например, чтобы установить для метаинформации вывода команды diff синий цвет, чёрный фон и полужирный шрифт, выполните команду:
Для установки цвета доступны следующие значения: normal , black , red , green , yellow , blue , magenta , cyan , или white . Для указания атрибутов текста, как bold в предыдущем примере, доступны значения: bold , dim , ul (подчёркнутый), blink и reverse (поменять местами цвет фона и цвет текста).
Внешние программы слияния и сравнения
Хоть в Git и есть встроенная программа сравнения, которая описывается в этой книге, вы можете установить вместо неё другую. Вы также можете настроить графический инструмент разрешения конфликтов слияния вместо того, чтобы разрешать конфликты вручную. Мы покажем как настроить Perforce Visual Merge Tool (P4Merge) для разрешения конфликтов слияния, так как это прекрасный и бесплатный инструмент.
Если у вас есть желание попробовать P4Merge, то она работает на всех основных платформах, так что у вас должно получиться. В примерах мы будем использовать пути к файлам, которые работают в системах Linux и Mac; для Windows вам следует изменить /usr/local/bin на путь к исполняемому файлу у вас в системе.
Для начала скачайте P4Merge. Затем, создайте скрипты обёртки для вызова внешних программ. Мы будем использовать путь к исполняемому файлу в системе Mac; в других системах — это путь к файлу p4merge . Создайте скрипт с названием extMerge для вызова программы слияния и передачи ей заданных параметров:
Скрипт вызова программы сравнения проверяет наличие 7 аргументов и передаёт 2 из них в скрипт вызова программы слияния. По умолчанию, Git передаёт следующие аргументы программе сравнения:
Так как вам нужны только old-file и new-file , следует использовать скрипт, который передаст только необходимые параметры.
Так же следует убедиться, что созданные скрипты могут исполняться:
Теперь можно изменить файл конфигурации для использования ваших инструментов слияния и сравнения. Для этого необходимо изменить ряд настроек: merge.tool — чтобы сказать Git какую стратегию использовать, mergetool.<tool>.cmd — чтобы сказать Git как запускать команду, mergetool.<tool>.trustExitCode — чтобы сказать Git как интерпретировать код выхода из программы, diff.external — чтобы сказать Git какую команду использовать для сравнения. Таким образом, команду конфигурации нужно запустить четыре раза:
или вручную отредактировать файл
/.gitconfig добавив соответствующие строки:
После этого, вы можете запускать команды diff следующим образом:
Вместо отображения вывода diff в терминале Git запустит P4Merge, выглядеть это будет примерно так:
Если при слиянии двух веток у вас возникнут конфликты, выполните команду git mergetool ; она запустит P4Merge чтобы вы могли разрешить конфликты используя графический интерфейс.
Используя скрипт обёртку для вызова внешних программ, вы можете легко изменить вызываемую программу. Например, чтобы начать использовать KDiff3 вместо P4Merge, достаточно изменить файл extMerge :
Теперь, Git будет использовать программу KDiff3 для сравнения файлов и разрешения конфликтов слияния.
Git изначально настроен на использование ряда других инструментов для разрешения конфликтов слияния, поэтому вам не нужно дополнительно что-то настраивать. Для просмотра списка поддерживаемых инструментов, выполните команду:
Если вы хотите использовать KDiff3 только для разрешения конфликтов слияния, но не для сравнения, выполните команду:
Если выполнить эту команду вместо настройки использования файлов extMerge и extDiff , то Git будет использовать KDiff3 для разрешения конфликтов слияния, а для сравнения — стандартную программу diff.
Форматирование и пробелы
core.autocrlf
Если вы программируете в Windows и работаете с людьми, которые не используют её (или наоборот), рано или поздно, вы столкнётесь с проблемами переноса строк. Это происходит потому, что Windows при создании файлов использует для обозначения переноса строки два символа «возврат каретки» и «перевод строки», в то время как Mac и Linux используют только один — «перевод строки». Это незначительный, но невероятно раздражающий факт кроссплатформенной работы; большинство редакторов в Windows молча заменяют переносы строк вида LF на CRLF или вставляют оба символа, когда пользователь нажимает клавишу ввод.
Git может автоматически конвертировать переносы строк CRLF в LF при добавлении файла в индекс и наоборот — при извлечении кода. Такое поведение можно включить используя настройку core.autocrlf . Если у вас Windows, то установите значение true — при извлечении кода LF окончания строк будут преобразовываться в CRLF:
Такая конфигурация позволит вам использовать CRLF переносы строк в Windows, при этом в репозитории и системах Mac и linux будет использован LF.
Если вы используете Windows и программируете только для Windows, то вы можете отключить описанный функционал задав значение false , сохраняя при этом CR символы в репозитории:
core.whitespace
Git поставляется настроенным на обнаружение и исправление некоторых проблем с пробелами. Он в состоянии найти шесть основных проблем, обнаружение трёх из них включено по умолчанию, а трёх других — выключено.
Те, что включены по умолчанию — это blank-at-eol , что ищет пробелы в конце строки; blank-at-eof , что ищет пробелы в конце файла; и space-before-tab , что ищет пробелы перед символом табуляции в начале строки.
Те, что выключены по умолчанию — это indent-with-non-tab , что ищет строки с пробелами вначале вместо символа табуляции (и контролируется настройкой tabwidth ); tab-in-indent , что ищет символы табуляции в отступах в начале строки; и cr-at-eol , которая указывает Git на валидность наличия CR в конце строки.
Указав через запятую значения для настройки core.whitespace , можно сказать Git какие из этих опций должны быть включены. Чтобы отключить ненужные проверки, достаточно удалить их из строки значений или поставить знак - перед каждой из них. Например, чтобы включить все проверки, кроме space-before-tab , выполните команду (при этом trailing-space является сокращением и охватывает как blank-at-eol , так и blank-at-eof ):
Или можно указать только часть проверок:
Так же можно указать Git автоматически исправлять эти проблемы перед применением патча:
Эти настройки так же применяются при выполнении команды git rebase . Если проблемные пробелы попали в коммит, но ещё не отправлены в удалённую ветку, можно выполнить git rebase --whitespace=fix для автоматического исправления этих проблем.
Конфигурация сервера
Для серверной части Git не так много настроек, но есть несколько интересных, на которые стоит обратить внимание.
receive.fsckObjects
Git способен убедиться, что каждый объект, отправленный командой push , валиден и соответствует своему SHA-1-хешу. По умолчанию эта функция отключена; это очень дорогая операция и может привести к существенному замедлению, особенно для больших объёмов отправляемых данных или для больших репозиториев. Вы можете включить проверку целостности объектов для каждой операции отправки, установив значение receive.fsckObjects в true :
receive.denyNonFastForwards
Для запрета перезаписи истории установите receive.denyNonFastForwards :
Сделать то же самое можно другим способом — используя хук на стороне сервера, мы рассмотрим его немного позже. Этот подход позволяет более гибко настроить ограничения, например, запретить перезапись истории определённой группе пользователей.
receive.denyDeletes
Политику denyNonFastForwards можно обойти, удалив ветку и создав новую с таким же именем. Для предотвращения этого, установите receive.denyDeletes в значение true :
Эта команда запретит удаление веток и тегов всем пользователям. Чтобы удалить ветку, придётся удалить все соответствующие ей файлы на сервере вручную. Куда более интересный способ — это настроить права пользователей, с ним вы познакомитесь в разделе Пример принудительной политики Git.
В этом документе мы подробнее изучим команду git config . Мы уже вкратце рассмотрели использование git config на странице Настройка репозитория. Команда git config — это удобная функция, которая используется для настройки значений конфигурации Git на глобальном и локальном уровнях проекта. Эти уровни конфигурации соответствуют текстовым файлам .gitconfig . При выполнении команды git config происходит изменение текстового файла конфигурации. Мы рассмотрим общие параметры конфигурации, такие как электронная почта, имя пользователя и редактор, а также обсудим псевдонимы Git, позволяющие создавать сокращенные команды для наиболее часто используемых операций Git. Освоив команду git config и различные параметры конфигурации Git, вы сможете создать сложный персонализированный рабочий процесс в Git.
Использование
Самый простой пример использования git config — вызов этой команды с именем конфигурации. При этом отобразится заданное для этого имени значение. Имена конфигурации представляют собой строку, состоящую из иерархической последовательности «раздела» и «ключа», разделенных точкой. Пример: user.email
В этом примере «email» является дочерним свойством блока конфигурации «user». Команда вернет адрес электронной почты (если таковой был указан), который Git свяжет с локально созданными коммитами.
Уровни и файлы git config
Прежде чем рассматривать использование git config , поговорим немного об уровнях конфигурации. Чтобы указать уровень конфигурации, на котором производится работа, к команде git config можно добавить аргументы. Доступны следующие уровни конфигурации:
По умолчанию, если не были переданы опции конфигурации, команда git config будет вести запись на локальном уровне. Конфигурация локального уровня применяется к репозиторию, в котором вызывается команда git config . Значения локальной конфигурации хранятся в файле, который находится в каталоге .git репозитория: .git/config
Конфигурация глобального уровня зависит от пользователя, то есть применяется к пользователю операционной системы. Значения глобальной конфигурации хранятся в файле, который находится в домашнем каталоге пользователя. Это
/.gitconfig в Unix-системах и C:\ \.gitconfig в системах Windows.
Конфигурация уровня системы применяется ко всей машине. Она охватывает всех пользователей операционной системы и все репозитории. Конфигурация уровня системы указывается в файле gitconfig в корневой папке системы. В Unix-системах это $(prefix)/etc/gitconfig , в системах Windows файл находится в C:\Documents and Settings\All Users\Application Data\Git\config для Windows XP и в C:\ProgramData\Git\config для Windows Vista и более новых версий.
Итак, порядок приоритета уровней конфигурации следующий: локальный, глобальный, системный. Это значит, что при поиске значения конфигурации система Git будет начинать с локального уровня и подниматься до уровня системы.
Запись значения
Для расширения знаний о git config рассмотрим пример записи значения:
Редактор git config — core.editor
Многие команды Git запускают текстовый редактор, чтобы запросить дальнейший ввод информации. Один из наиболее частых примеров использования команды git config — это настройка редактора, который должен применяться в Git. Ниже приведена таблица наиболее популярных редакторов и соответствующие команды git config .
git config --global core.editor "atom --wait"
git config --global core.editor "emacs"
git config --global core.editor "nano -w"
git config --global core.editor "vim"
git config --global core.editor "subl -n -w"
git config --global core.editor "'c:/program files (x86)/sublime text 3/sublimetext.exe' -w"
git config --global core.editor "'c:/program files/sublime text 3/sublimetext.exe' -w"
git config --global core.editor "mate -w"
Инструменты слияния
При возникновении конфликта слияния Git запускает «инструмент слияния». По умолчанию в Git используется внутренняя реализация обычной Unix-программы diff. Внутренняя программа diff в Git представляет собой простейшее средство для просмотра конфликтов слияния. Вместо нее можно использовать любое другое стороннее решение для разрешения конфликтов. Обзор различных инструментов слияния и конфигурации см. в руководстве по советам и инструментам для решения конфликтов с помощью Git.
Выделение выводимой информации цветом
Git поддерживает выделение выводимой в терминале информации различными цветами, что помогает быстро читать вывод Git. Для настройки вывода Git можно использовать индивидуальную цветовую тему. Для установки значений цветов используется команда git config .
color.ui
Это основная переменная, влияющая на выделение цветом в Git. Если задать этой переменной значение false, выделение любой выводимой в терминале Git информации цветом будет отключено.
Значение переменной color.ui по умолчанию равно auto. Это означает, что маркироваться цветом будет только непосредственный выходной поток терминала. Если же выходной поток перенаправляется в файл или передается другому процессу, то такой вывод цветом не маркируется.
Можно присвоить переменной color.ui значение always. Тогда вывод будет выделяться цветом даже при перенаправлении выходного потока в файлы или конвейеры. Однако это может вызвать проблемы, поскольку принимающий конвейер может не ожидать, что входные данные будут иметь цветовую кодировку.
Значения цветов в Git
Помимо переменной color.ui , доступны и более тонкие настройки цвета. Как и переменной color.ui , эти цветовым настройкам можно присваивать значения false, auto или always. Кроме того, им можно присвоить конкретное значение цвета. Вот несколько примеров поддерживаемых значений цвета:
Настройка цветовой конфигурации в Git
2. color.branch. слот >
- Это значение также применяется к выводу команды git branch. Переменная слот > может принимать одно из следующих значений:
- 1) current: текущая ветка;
- 2) local: локальная ветка;
- 3) remote: ссылка на удаленную ветку в refs/remotes;
- 4) upstream: вышестоящая отслеживаемая ветка.
- 5) plain: любая другая ссылка.
- Применяет цвета к выводу команд git diff , git log и git show .
4. color.diff . слот >
- Значение слот > в параметре color.diff указывает системе Git, в какой части команды diff использовать указанный цвет:
- 1) context: текст контекста diff. Контекст Git — это строки текстового контекста в diff или patch, которые подсвечивают изменения;
- 2) plain: синоним контекста;
- 3) meta: применяет цвет к метаданным diff;
- 4) frag: применяет цвет к заголовку участка кода или к функции в заголовке участка кода;
- 5) old: окрашивает удаленные строки в diff;
- 6) new: окрашивает добавленные строки в diff;
- 7) commit: окрашивает заголовки коммитов в diff.
- 8) whitespace: задает в diff цвет для любых ошибок, связанных с пробелами.
5. color.decorate. слот >
- Настройка цвета для вывода команды git log --decorate . Поддерживаемые значения параметра слот >: branch , remoteBranch , tag , stash или HEAD . Они применяются к локальным веткам, удаленным отслеживаемым веткам, тегам, отложенным изменениям и указателю HEAD соответственно.
7. color.grep. слот >
- Применяется также для команды git grep. Переменная слот > указывает, к какой части вывода команды grep применить цвет:
- 1) context: несоответствующий текст в строках контекста;
- 2) filename: префикс имени файла;
- 3) function: строки с именами функций;
- 4) linenumber: префикс номера строки;
- 5) match: соответствующий текст;
- 6) matchContext: соответствующий текст в строках контекста;
- 7) matchSelected: соответствующий текст в выбранных строках;
- 8) selected: несоответствующий текст в выбранных строках;
- 9) separator: разделители между полями в строке (:, -, и =) и между участками кода (--).
- Эта переменная задает цвет для интерактивных подсказок. Примеры: git add --interactive и git clean --interactive .
9. color.interactive. слот >
- Включает или отключает выделение выводимой информации цветом при использовании пейджера.
- Включает или отключает выделение выводимой информации цветом для команды git show-branch.
- Логическое значение, которое включает или отключает выделение выводимой информации цветом для команды git status.
13) color.status. слот >
Используется для того, чтобы задать пользовательский цвет для указанных элементов git status. Переменная слот > поддерживает следующие значения:
- 1) header:
- указывает на текст заголовков в области состояния;
- оба значения указывают на файлы, которые были добавлены, но не зафиксированы в виде коммитов;
- указывает на файлы, которые были изменены, но не добавлены в индекс Git;
- указывает на файлы, которые не отслеживаются системой Git;
- применяет цвет к текущей ветке.
- цвет предупреждения о том, что ветка отсутствует;
- окрашивает файлы, в которых есть неслитые изменения.
Псевдонимы
Концепция псевдонимов может быть вам знакома по командной строке операционной системы. Если нет, то знайте, что псевдонимы — это пользовательские сокращенные команды, которые расширяются до более длинных или комбинированных команд. Псевдонимы экономят время и силы на ввод часто используемых команд. Git предоставляет собственную систему псевдонимов. Чаще всего псевдонимы Git используются для сокращения команды commit. Псевдонимы хранятся в файлах конфигурации Git. Это значит, что для настройки псевдонимов можно использовать команду git config .
В этом примере создается псевдоним ci для команды git commit . После этого вы сможете вызывать команду git commit с помощью команды git ci . Псевдонимы также могут ссылаться на другие псевдонимы для создания более сложных сочетаний команд.
В этом примере создается псевдоним amend, который включает псевдоним ci в новый псевдоним, использующий флаг --amend .
Форматирование и пробелы
В Git есть функции для подсвечивания ошибок с пробелами при использовании git diff. Ошибки с пробелами будут выделяться цветом, указанным в color.diff.whitespace
Следующие возможности по умолчанию включены:
- blank-at-eol — подсвечивает висячие пробелы в конце строк;
- space-before-tab — подсвечивает пробелы перед символом табуляции в строках с отступом;
- blank-at-eof — подсвечивает пустые строки, вставленные в конец файла.
Следующие возможности по умолчанию отключены:
- indent-with-non-tab — подсвечивает строку, в которой для отступа используются пробелы вместо символов табуляции;
- tab-in-indent — подсвечивает как ошибку отступ, начинающийся с символа табуляции;
- trailing-space — сокращение для возможностей blank-at-eol и blank-at-eof;
- cr-at-eol — подсвечивает символ возврата каретки в конце строки;
- tabwidth= — определяет, сколько позиций символов занимает символ табуляции. Значение по умолчанию: 8. Допустимые значения: от 1 до 63.
Резюме
В этой статье мы рассказали, как использовать команду git config ; объяснили, почему эта команда удобна для редактирования исходных файлов git config в файловой системе, и рассмотрели основные операции чтения и записи для параметров конфигурации. Кроме того, мы изучили распространенные сценарии настройки конфигурации:
- настройка редактора Git;
- переопределение уровней конфигурации;
- сброс значений по умолчанию для конфигурации;
- настройка цветов в Git.
В целом git config — это вспомогательный инструмент, помогающий быстро редактировать исходные файлы git config на диске. Мы подробно рассмотрели параметры индивидуальной настройки. Если вы захотите настроить репозиторий, вам обязательно понадобятся базовые знания параметров конфигурации Git. Демонстрацию основ работы см. в нашем руководстве.
In this document, we'll take an in-depth look at the git config command. We briefly discussed git config usage on our Setting up a Repository page. The git config command is a convenience function that is used to set Git configuration values on a global or local project level. These configuration levels correspond to .gitconfig text files. Executing git config will modify a configuration text file. We'll be covering common configuration settings like email, username, and editor. We'll discuss Git aliases, which allow you to create shortcuts for frequently used Git operations. Becoming familiar with git config and the various Git configuration settings will help you create a powerful, customized Git workflow.
Usage
The most basic use case for git config is to invoke it with a configuration name, which will display the set value at that name. Configuration names are dot delimited strings composed of a 'section' and a 'key' based on their hierarchy. For example: user.email
In this example, email is a child property of the user configuration block. This will return the configured email address, if any, that Git will associate with locally created commits.
git config levels and files
Before we further discuss git config usage, let's take a moment to cover configuration levels. The git config command can accept arguments to specify which configuration level to operate on. The following configuration levels are available:
By default, git config will write to a local level if no configuration option is passed. Local level configuration is applied to the context repository git config gets invoked in. Local configuration values are stored in a file that can be found in the repo's .git directory: .git/config
Global level configuration is user-specific, meaning it is applied to an operating system user. Global configuration values are stored in a file that is located in a user's home directory.
/.gitconfig on unix systems and C:\Users\ \.gitconfig on windows
System-level configuration is applied across an entire machine. This covers all users on an operating system and all repos. The system level configuration file lives in a gitconfig file off the system root path. $(prefix)/etc/gitconfig on unix systems. On windows this file can be found at C:\Documents and Settings\All Users\Application Data\Git\config on Windows XP, and in C:\ProgramData\Git\config on Windows Vista and newer.
Thus the order of priority for configuration levels is: local, global, system. This means when looking for a configuration value, Git will start at the local level and bubble up to the system level.
Writing a value
Expanding on what we already know about git config , let's look at an example in which we write a value:
git config editor - core.editor
Many Git commands will launch a text editor to prompt for further input. One of the most common use cases for git config is configuring which editor Git should use. Listed below is a table of popular editors and matching git config commands:
git config --global core.editor "atom --wait"
git config --global core.editor "emacs"
git config --global core.editor "nano -w"
git config --global core.editor "vim"
git config --global core.editor "subl -n -w"
git config --global core.editor "'c:/program files (x86)/sublime text 3/sublimetext.exe' -w"
git config --global core.editor "'c:/program files/sublime text 3/sublimetext.exe' -w"
git config --global core.editor "mate -w"
Merge tools
In the event of a merge conflict, Git will launch a "merge tool." By default, Git uses an internal implementation of the common Unix diff program. The internal Git diff is a minimal merge conflict viewer. There are many external third party merge conflict resolutions that can be used instead. For an overview of various merge tools and configuration, see our guide on tips and tools to resolve conflits with Git.
Colored outputs
Git supports colored terminal output which helps with rapidly reading Git output. You can customize your Git output to use a personalized color theme. The git config command is used to set these color values.
color.ui
This is the master variable for Git colors. Setting it to false will disable all Git's colored terminal output.
By default, color.ui is set to auto which will apply colors to the immediate terminal output stream. The auto setting will omit color code output if the output stream is redirected to a file or piped to another process.
You can set the color.ui value to always which will also apply color code output when redirecting the output stream to files or pipes. This can unintentionally cause problems since the receiving pipe may not be expecting color-coded input.
Git color values
Git color configuration settings
- Configures the output color of the Git branch command
2. color.branch. slot >
- This value is also applicable to Git branch output. slot > is one of the following:
- 1. current: the current branch
- 2. local: a local branch
- 3. remote: a remote branch ref in refs/remotes
- 4. upstream: an upstream tracking branch
- 5. plain: any other ref
- Applies colors to git diff , git log , and git show output
4. color.diff . slot >
- Configuring a slot > value under color.diff tells git which part of the patch to use a specific color on.
- 1. context: The context text of the diff. Git context is the lines of text content shown in a diff or patch that highlights changes.
- 2. plain: a synonym for context
- 3. meta: applies color to the meta information of the diff
- 4. frag: applies color to the "hunk header" or "function in hunk header"
- 5. old: applies a color to the removed lines in the diff
- 6. new: colors the added lines of the diff
- 7. commit: colors commit headers within the diff
- 8. whitespace: sets a color for any whitespace errors in a diff
5. color.decorate. slot >
7. color.grep. slot >
- Also applicable to git grep. The slot > variable specifies which part of the grep output to apply color.
- 1. context: non-matching text in context lines
- 2. filename: filename prefix
- 3. function: function name lines
- 4. linenumber: line number prefix
- 5. match: matching text
- 6. matchContext: matching text in context lines
- 7. matchSelected: matching text in selected lines
- 8. selected: non-matching text in selected lines
- 9. separator: separators between fields on a line (:, -, and =) and between hunks (--)
- This variable applies color for interactive prompts and displays. Examples are git add --interactive and git clean --interactive
9. color.interactive. slot >
- Enables or disables colored output when the pager is in use
- Enables or disables color output for the git show branch command
- A boolean value that enables or disables color output for Git status
13. color.status. slot >
Used to specify custom color for specified git status elements. slot > supports the following values:
- 1. header
- Targets the header text of the status area
- Both target files which are added but not committed
- Targets files that are modified but not added to the git index
- Targets files which are not tracked by Git
- Applies color to the current branch
- The color the "no branch" warning is shown in
- Colors files which have unmerged changes
Aliases
You may be familiar with the concept of aliases from your operating system command-line; if not, they're custom shortcuts that define which command will expand to longer or combined commands. Aliases save you the time and energy cost of typing frequently used commands. Git provides its own alias system. A common use case for Git aliases is shortening the commit command. Git aliases are stored in Git configuration files. This means you can use the git config command to configure aliases.
This example creates a ci alias for the git commit command. You can then invoke git commit by executing git ci . Aliases can also reference other aliases to create powerful combos.
This example creates an alias amend which composes the ci alias into a new alias that uses --amend flag .
Formatting & whitespace
Git has several "whitespace" features that can be configured to highlight whitespace issues when using git diff. The whitespace issues will be highlighted using the configured color color.diff.whitespace
The following features are enabled by default:
- blank-at-eol highlights orphan whitespaces at the line endings
- space-before-tab highlights a space character that appears before a tab character when indenting a line
- blank-at-eof highlights blank lines inserted at the end of a file
The following features are disabled by default
- indent-with-non-tab highlights a line that is indented with spaces instead of tabs
- tab-in-indent highlights an initial tab indent as an error
- trailing-space is shorthand for both blank-at-eol and blank-at-eof
- cr-at-eol highlights a carriage-return at the line endings
- tabwidth= defines how many character positions a tab occupies. The default value is 8. Allowed values are 1-63
Summary
In this article, we covered the use of the git config command . We discussed how the command is a convince method for editing raw git config files on the filesystem. We looked at basic read and write operations for configuration options. We took a look at common config patterns:
- How to configure the Git editor
- How to override configuration levels
- How to reset configuration defaults
- How to customize git colors
Overall, git config is a helper tool that provides a shortcut to editing raw git config files on disk. We covered in depth personal customization options. Basic knowledge of git configuration options is a prerequisite for setting up a repository. See our guide there for a demonstration of the basics.
Читайте также: