Где находится файл gitconfig
Обновлено: 21.11.2024
До сих пор мы рассмотрели основы того, как работает Git и как его использовать, и представили ряд инструментов, которые Git предоставляет, чтобы помочь вам использовать его легко и эффективно. В этой главе мы увидим, как вы можете заставить Git работать более индивидуально, введя несколько важных параметров конфигурации и систему хуков. С помощью этих инструментов легко заставить Git работать именно так, как нужно вам, вашей компании или вашей группе.
Конфигурация Git
Как вы кратко прочитали в разделе «Начало работы», вы можете указать параметры конфигурации Git с помощью команды git config. Первое, что вы сделали, это указали свое имя и адрес электронной почты:
Теперь вы познакомитесь с несколькими наиболее интересными параметрами, которые можно настроить таким образом, чтобы настроить использование Git.
Во-первых, краткий обзор: Git использует набор файлов конфигурации, чтобы определить поведение не по умолчанию, которое может вам понадобиться. В первую очередь Git ищет эти значения в общесистемном файле [путь]/etc/gitconfig, который содержит настройки, применяемые к каждому пользователю в системе и ко всем их репозиториям. Если вы передадите параметр --system в git config , он будет читать и писать именно из этого файла.
Следующее место, куда обращается Git, — это файл ~/.gitconfig (или ~/.config/git/config ), специфичный для каждого пользователя. Вы можете заставить Git читать и писать в этот файл, передав параметр --global.
Наконец, Git ищет значения конфигурации в файле конфигурации в каталоге Git ( .git/config ) любого репозитория, который вы используете в данный момент. Эти значения относятся к этому единственному репозиторию и представляют собой передачу параметра --local в git config . Если вы не укажете, с каким уровнем вы хотите работать, это значение по умолчанию.
Каждый из этих «уровней» (системный, глобальный, локальный) перезаписывает значения на предыдущем уровне, поэтому значения в .git/config перевешивают, например, значения в [path]/etc/gitconfig .
Файлы конфигурации Git представляют собой обычный текст, поэтому вы также можете установить эти значения, отредактировав файл вручную и вставив правильный синтаксис. Однако, как правило, проще запустить команду git config.
Базовая конфигурация клиента
Параметры конфигурации, распознаваемые Git, делятся на две категории: на стороне клиента и на стороне сервера. Большинство опций находятся на стороне клиента — настройка ваших личных рабочих предпочтений. Поддерживается много, много параметров конфигурации, но большая их часть полезна только в определенных крайних случаях; здесь мы рассмотрим только самые распространенные и полезные варианты. Если вы хотите увидеть список всех опций, распознаваемых вашей версией Git, вы можете запустить:
core.editor
По умолчанию Git использует все, что вы установили в качестве текстового редактора по умолчанию с помощью одной из переменных среды оболочки VISUAL или EDITOR, либо использует редактор vi для создания и редактирования ваших сообщений фиксации и тегов. Чтобы изменить это значение по умолчанию на другое, вы можете использовать параметр core.editor:
Теперь независимо от того, какой редактор оболочки установлен по умолчанию, Git будет запускать Emacs для редактирования сообщений.
commit.template
Если вы укажете путь к файлу в вашей системе, Git будет использовать этот файл в качестве начального сообщения по умолчанию при фиксации. Ценность создания пользовательского шаблона фиксации заключается в том, что вы можете использовать его, чтобы напомнить себе (или другим) о правильном формате и стиле при создании сообщения фиксации.
Например, рассмотрим файл шаблона ~/.gitmessage.txt, который выглядит следующим образом:
Обратите внимание, что этот шаблон фиксации напоминает коммиттеру о том, что строка темы должна быть короткой (ради вывода git log --oneline), добавить под ней дополнительные сведения и указать номер заявки или сообщения об ошибке, если таковая имеется. существует.
Чтобы указать Git использовать его в качестве сообщения по умолчанию, которое появляется в вашем редакторе при запуске git commit , установите значение конфигурации commit.template:
Затем ваш редактор откроет что-то вроде этого для вашего сообщения фиксации заполнителя, когда вы фиксируете:
Если у вашей команды есть политика сообщений о коммитах, размещение шаблона этой политики в вашей системе и настройка Git для его использования по умолчанию может повысить вероятность регулярного соблюдения этой политики.
core.pager
Этот параметр определяет, какой пейджер используется при выводе страниц Git, таких как log и diff . Вы можете установить его на больше или на ваш любимый пейджер (по умолчанию меньше ), или вы можете отключить его, задав пустую строку:
Если вы запустите это, Git выдаст весь вывод всех команд, независимо от их длины.
user.signingkey
Если вы создаете подписанные аннотированные теги (как описано в разделе «Подписание вашей работы»), установка ключа подписи GPG в качестве параметра конфигурации упрощает задачу. Установите идентификатор ключа следующим образом:
Теперь вы можете подписывать теги, не указывая свой ключ каждый раз с помощью команды git tag:
core.excludesfile
Вы можете поместить шаблоны в файлы .gitignore, чтобы Git не рассматривал их как неотслеживаемые файлы или не пытался помещать их в промежуточное состояние, когда вы запускаете для них команду git add, как описано в разделе «Игнорирование файлов».
Но иногда вам нужно игнорировать определенные файлы для всех репозиториев, с которыми вы работаете. Если на вашем компьютере установлена macOS, вы, вероятно, знакомы с файлами .DS_Store. Если вы предпочитаете редактор Emacs или Vim, вы знаете, что имена файлов заканчиваются на ~ или .swp .
Этот параметр позволяет вам написать своего рода глобальный файл .gitignore. Если вы создадите файл ~/.gitignore_global со следующим содержимым:
… и вы запустите git config --global core.excludesfile ~/.gitignore_global , Git больше никогда не будет беспокоить вас по поводу этих файлов.
help.autocorrect
Если вы наберете команду с ошибкой, появится примерно следующее:
Git услужливо пытается понять, что вы имели в виду, но по-прежнему отказывается это делать. Если вы установите для help.autocorrect значение 1, Git фактически выполнит для вас эту команду:
Обратите внимание, что «0,1 секунды» — это бизнес. help.autocorrect на самом деле является целым числом, представляющим десятые доли секунды. Поэтому, если вы установите значение 50, Git даст вам 5 секунд, чтобы передумать, прежде чем выполнять автокорректируемую команду.
Цвета в Git
Git полностью поддерживает цветной вывод терминала, что очень помогает быстро и легко визуально анализировать вывод команды. Ряд параметров может помочь вам настроить цвет по своему вкусу.
color.ui
Git автоматически окрашивает большую часть своего вывода, но есть главный переключатель, если вам не нравится такое поведение. Чтобы отключить весь цветной вывод терминала Git, сделайте следующее:
Настройкой по умолчанию является auto , которая окрашивает вывод, когда он поступает прямо на терминал, но пропускает коды управления цветом, когда вывод перенаправляется в канал или файл.
Вы также можете установить его всегда, чтобы игнорировать разницу между терминалами и трубами. Вам это редко понадобится; в большинстве случаев, если вам нужны цветовые коды в перенаправленном выводе, вы можете вместо этого передать флаг --color команде Git, чтобы заставить ее использовать цветовые коды. Настройка по умолчанию почти всегда соответствует вашим потребностям.
цвет.*
Если вы хотите уточнить, какие команды окрашиваются и как, Git предоставляет настройки окраски для конкретных глаголов. Для каждого из них можно установить значение true , false или всегда :
Кроме того, у каждого из них есть поднастройки, которые можно использовать для установки определенных цветов для частей вывода, если вы хотите переопределить каждый цвет. Например, чтобы установить для метаинформации в выводе различий синий цвет переднего плана, черный фон и полужирный текст, вы можете запустить:
Для цвета можно задать любое из следующих значений: нормальный , черный , красный , зеленый , желтый , синий , пурпурный , голубой или белый . Если вам нужен атрибут, подобный полужирному в предыдущем примере, вы можете выбрать полужирный, затемненный, ul (подчеркивание), blink и инвертировать (поменять местами передний план и фон).
Внешние инструменты слияния и сравнения
Несмотря на то, что в Git есть внутренняя реализация diff, которую мы показывали в этой книге, вместо этого вы можете настроить внешний инструмент. Вы также можете настроить графический инструмент разрешения конфликтов слияния вместо того, чтобы разрешать конфликты вручную. Мы продемонстрируем настройку инструмента визуального слияния Perforce (P4Merge) для выполнения различий и разрешения слияния, поскольку это удобный графический инструмент, к тому же бесплатный.
Если вы хотите попробовать это, P4Merge работает на всех основных платформах, так что вы сможете это сделать. Мы будем использовать имена путей в примерах, которые работают в системах macOS и Linux; для Windows вам придется изменить /usr/local/bin на путь к исполняемому файлу в вашей среде.
Для начала загрузите P4Merge из Perforce. Далее вы настроите внешние скрипты-оболочки для запуска ваших команд. Мы будем использовать путь macOS для исполняемого файла; в других системах это будет место, где установлен ваш двоичный файл p4merge. Настройте сценарий оболочки слияния с именем extMerge, который вызывает ваш двоичный файл со всеми предоставленными аргументами:
Оболочка diff проверяет наличие семи аргументов и передает два из них сценарию слияния. По умолчанию Git передает программе сравнения следующие аргументы:
Поскольку вам нужны только аргументы старого и нового файлов, вы используете скрипт-оболочку для передачи нужных вам аргументов.
Вам также необходимо убедиться, что эти инструменты являются исполняемыми:
Теперь вы можете настроить свой конфигурационный файл для использования собственного разрешения слияния и инструментов сравнения. Для этого требуется ряд пользовательских настроек: merge.tool, чтобы сообщить Git, какую стратегию использовать, mergetool..cmd, чтобы указать, как запускать команду, mergetool..trustExitCode, чтобы сообщить Git, указывает ли код выхода этой программы на успешное разрешение слияния. или нет, и diff.external, чтобы сообщить Git, какую команду запускать для diff. Итак, вы можете запустить четыре команды конфигурации:
или вы можете отредактировать файл ~/.gitconfig, добавив следующие строки:
После того, как все это установлено, если вы запускаете команды diff, такие как эта:
Вместо того, чтобы получать вывод различий в командной строке, Git запускает P4Merge, который выглядит примерно так:
Если вы попытаетесь объединить две ветки и впоследствии возникнут конфликты слияния, вы можете запустить команду git mergetool ; он запускает P4Merge, чтобы разрешить конфликты с помощью этого инструмента с графическим интерфейсом.
Преимущество этой настройки оболочки заключается в том, что вы можете легко менять инструменты сравнения и слияния. Например, чтобы заменить ваши инструменты extDiff и extMerge на запуск инструмента KDiff3, все, что вам нужно сделать, это отредактировать файл extMerge:
Теперь Git будет использовать инструмент KDiff3 для просмотра различий и разрешения конфликтов слияния.
Git предустановлен для использования ряда других инструментов разрешения слияния без необходимости настраивать конфигурацию cmd. Чтобы просмотреть список поддерживаемых инструментов, попробуйте следующее:
Если вы не заинтересованы в использовании KDiff3 для сравнения, а хотите использовать его только для разрешения слияния, и команда kdiff3 находится в вашем пути, вы можете выполнить:
Если вы запустите это вместо настройки файлов extMerge и extDiff, Git будет использовать KDiff3 для разрешения слияния и обычный инструмент Git diff для сравнения.
Форматирование и пробелы
Проблемы с форматированием и пробелами – это одни из самых неприятных и малозаметных проблем, с которыми сталкиваются многие разработчики при совместной работе, особенно кроссплатформенной. Для исправлений или другой совместной работы очень легко внести тонкие изменения пробелов, потому что редакторы вносят их молча, и если ваши файлы когда-либо касаются системы Windows, их окончания строк могут быть заменены. В Git есть несколько параметров конфигурации, которые помогут решить эти проблемы.
core.autocrlf
Если вы программируете в Windows и работаете с людьми, которые этого не делают (или наоборот), вы, вероятно, в какой-то момент столкнетесь с проблемами окончания строки. Это связано с тем, что Windows использует как символ возврата каретки, так и символ перевода строки для новой строки в своих файлах, тогда как системы macOS и Linux используют только символ перевода строки. Это малозаметный, но невероятно раздражающий факт кроссплатформенной работы; многие редакторы в Windows молча заменяют существующие окончания строк в стиле LF на CRLF или вставляют оба символа конца строки, когда пользователь нажимает клавишу ввода.
Git может справиться с этим, автоматически преобразовывая окончания строк CRLF в LF, когда вы добавляете файл в индекс, и наоборот, когда код извлекается в вашу файловую систему. Вы можете включить эту функцию с помощью параметра core.autocrlf. Если вы работаете на компьютере с Windows, установите для него значение true — это преобразует окончания LF в CRLF при извлечении кода:
Если вы работаете в системе Linux или macOS, в которой используются окончания строк LF, вы не хотите, чтобы Git автоматически преобразовывал их при извлечении файлов; однако, если случайно появляется файл с окончаниями CRLF, вы можете захотеть исправить это с помощью Git. Вы можете указать Git конвертировать CRLF в LF при фиксации, но не наоборот, установив core.autocrlf для ввода:
Эта настройка должна оставить вам окончания CRLF при извлечении Windows, но окончания LF в системах macOS и Linux и в репозитории.
Если вы программист Windows и работаете над проектом только для Windows, вы можете отключить эту функцию, записав возврат каретки в репозиторий, установив для параметра конфигурации значение false :
core.whitespace
Git предустановлен для обнаружения и исправления некоторых проблем с пробелами. Он может искать шесть основных проблем с пробелами: три включены по умолчанию и могут быть отключены, а три по умолчанию отключены, но их можно активировать.
По умолчанию включены три параметра: blank-at-eol , который ищет пробелы в конце строки; Blank-at-eof , который замечает пустые строки в конце файла; и space-before-tab, который ищет пробелы перед табуляцией в начале строки.
Три из них отключены по умолчанию, но их можно включить: indent-with-non-tab , который ищет строки, начинающиеся с пробелов, а не с табуляции (и управляется параметром tabwidth); tab-in-indent, который следит за табуляцией в отступе строки; и cr-at-eol , который сообщает Git, что возврат каретки в конце строк допустим.
Вы можете указать Git, какие из них вы хотите включить, задав для core.whitespace нужные значения, разделенные запятыми. Вы можете отключить параметр, добавив - перед его именем, или использовать значение по умолчанию, полностью исключив его из строки настроек. Например, если вы хотите, чтобы были установлены все, кроме пробела перед табуляцией, вы можете сделать это (с конечным пробелом, который является сокращением для охвата как пустого на eol, так и пустого на eof ):
Или вы можете указать только часть настройки:
Git обнаружит эти проблемы, когда вы запустите команду git diff, и попытаетесь выделить их цветом, чтобы вы могли исправить их перед фиксацией. Он также будет использовать эти значения, чтобы помочь вам при применении исправлений с помощью git apply .Когда вы применяете исправления, вы можете попросить Git предупредить вас, если он применяет исправления с указанными проблемами с пробелами:
Или вы можете сделать так, чтобы Git попытался автоматически исправить проблему перед применением исправления:
Эти параметры также применимы к команде git rebase. Если вы зафиксировали проблемы с пробелами, но еще не отправили их в основной поток, вы можете запустить git rebase --whitespace=fix, чтобы Git автоматически исправлял проблемы с пробелами по мере перезаписи исправлений.
Конфигурация сервера
Для серверной части Git доступно не так много параметров конфигурации, но есть несколько интересных, на которые стоит обратить внимание.
получить.fsckObjects
Git может убедиться, что каждый объект, полученный во время отправки, по-прежнему соответствует контрольной сумме SHA-1 и указывает на допустимые объекты. Однако он не делает этого по умолчанию; это довольно дорогая операция и может замедлить ее, особенно при больших репозиториях или при отправке. Если вы хотите, чтобы Git проверял непротиворечивость объектов при каждой отправке, вы можете заставить его делать это, установив для Receive.fsckObjects значение true:
Теперь Git будет проверять целостность вашего репозитория перед каждой отправкой, чтобы убедиться, что неисправные (или вредоносные) клиенты не передают поврежденные данные.
receive.denyNonFastForwards
Если вы перебазируете уже отправленные коммиты, а затем попытаетесь отправить их снова или иным образом попытаетесь отправить коммит в удаленную ветку, не содержащую коммит, на который в данный момент указывает удаленная ветка, вы будете отклонен. Обычно это хорошая политика; но в случае перебазирования вы можете решить, что знаете, что делаете, и можете принудительно обновить удаленную ветку с помощью флага -f в вашей команде push.
Чтобы указать Git отказаться от принудительной отправки, установите Receive.denyNonFastForwards :
Еще один способ сделать это — использовать перехватчики получения на стороне сервера, о которых мы поговорим чуть позже. Такой подход позволяет выполнять более сложные действия, например запрещать небыструю перемотку вперед определенному подмножеству пользователей.
receive.denyDeletes
Одним из способов обхода политики denyNonFastForwards является удаление пользователем ветки, а затем отправка ее обратно с новой ссылкой. Чтобы избежать этого, установите для параметра receive.denyDeletes значение true:
Это запрещает любое удаление веток или тегов — ни один пользователь не может этого сделать. Чтобы удалить удаленные ветки, необходимо вручную удалить ref-файлы с сервера. Есть также более интересные способы сделать это для каждого пользователя с помощью ACL, как вы узнаете из примера Git-Enforced Policy.
В этом документе мы подробно рассмотрим команду git config. Мы кратко обсудили использование git config на нашей странице Настройка репозитория. Команда git config — это удобная функция, которая используется для установки значений конфигурации Git на глобальном или локальном уровне проекта. Эти уровни конфигурации соответствуют текстовым файлам .gitconfig. Выполнение git config изменит текстовый файл конфигурации. Мы рассмотрим общие параметры конфигурации, такие как электронная почта, имя пользователя и редактор. Мы обсудим псевдонимы Git, которые позволяют создавать ярлыки для часто используемых операций Git. Знакомство с git config и различными параметрами конфигурации Git поможет вам создать мощный настраиваемый рабочий процесс Git.
Использование
Самый простой вариант использования git config – вызвать его с именем конфигурации, которое будет отображать установленное значение для этого имени. Имена конфигураций представляют собой строки, разделенные точками, состоящие из «раздела» и «ключа» в зависимости от их иерархии. Например: user.email
В этом примере электронная почта является дочерним свойством блока конфигурации пользователя. Это вернет настроенный адрес электронной почты, если таковой имеется, который Git свяжет с локально созданными фиксациями.
уровни и файлы конфигурации git
Прежде чем мы продолжим обсуждение использования git config, давайте рассмотрим уровни конфигурации. Команда git config может принимать аргументы, чтобы указать, на каком уровне конфигурации работать. Доступны следующие уровни конфигурации:
По умолчанию git config записывает данные на локальный уровень, если параметр конфигурации не передан. Конфигурация локального уровня применяется к репозиторию контекста, в котором вызывается git config. Значения локальной конфигурации хранятся в файле, который можно найти в каталоге .git репозитория: .git/config
Конфигурация глобального уровня зависит от пользователя, то есть применяется к пользователю операционной системы. Значения глобальной конфигурации хранятся в файле, расположенном в домашнем каталоге пользователя. ~ /.gitconfig в системах Unix и C:\Users\ \.gitconfig в Windows
Конфигурация на уровне системы применяется ко всему компьютеру. Это касается всех пользователей операционной системы и всех репозиториев. Файл конфигурации системного уровня находится в файле gitconfig вне корневого пути системы. $(префикс)/etc/gitconfig в системах unix.В Windows этот файл можно найти в папке C:\Documents and Settings\All Users\Application Data\Git\config в Windows XP и в C:\ProgramData\Git\config в Windows Vista и более поздних версиях.
Таким образом, порядок приоритета уровней конфигурации следующий: локальный, глобальный, системный. Это означает, что при поиске значения конфигурации Git запустится на локальном уровне и перейдет на системный уровень.
Запись значения
Расширяя то, что мы уже знаем о git config , давайте рассмотрим пример, в котором мы записываем значение:
редактор конфигурации git — core.editor
Многие команды Git запускают текстовый редактор, чтобы запросить дальнейший ввод. Одним из наиболее распространенных вариантов использования git config является настройка того, какой редактор должен использовать Git. Ниже приведена таблица популярных редакторов и соответствующих команд git config:
| Редактор | команда конфигурации |
|---|---|
| Atom | ~ git config --global core.editor "atom --wait" ~ |
| emacs | ~ git config --global core.editor "emacs"~ |
| nano | ~ git config --global core.editor "nano -w"~ |
| vim | ~ git config -- global core.editor "vim"~ |
| Sublime Text (Mac) | ~ git config --global core.editor "subl -n -w" ~ |
| Sublime Text (Win, 32-разрядная установка) | ~ git config --global core.editor "'c:/program files (x86 )/sublime text 3/sublimetext.exe' -w"~ |
| Sublime Text (Win, 64-битная установка) | ~ git config -- global core.editor "'c:/program files/sublime text 3/sublimetext.exe' -w"~ |
| Textmate | ~ git config - -global core.editor "mate -w"~ |
Инструменты объединения
В случае конфликта слияния Git запустит «инструмент слияния». По умолчанию Git использует внутреннюю реализацию обычной программы Unix diff. Внутренний Git diff — это минимальное средство просмотра конфликтов слияния. Вместо этого можно использовать множество внешних сторонних разрешений конфликтов слияния. Обзор различных инструментов и настроек слияния см. в нашем руководстве по советам и инструментам для разрешения конфликтов с Git.
Цветные результаты
Git поддерживает цветной вывод терминала, который помогает быстро читать вывод Git. Вы можете настроить выходные данные Git для использования персонализированной цветовой темы. Для установки этих значений цвета используется команда git config.
color.ui
Это главная переменная для цветов Git. Установка его в false отключит весь цветной вывод терминала Git.
По умолчанию для color.ui установлено значение auto, при котором цвета будут применяться к непосредственному выходному потоку терминала. Автоматическая настройка пропускает вывод цветового кода, если выходной поток перенаправляется в файл или передается другому процессу.
Вы можете установить для color.ui значение always, которое также будет применять вывод цветового кода при перенаправлении выходного потока в файлы или конвейеры. Это может непреднамеренно вызвать проблемы, поскольку приемный канал может не ожидать ввода с цветовой кодировкой.
Git значения цвета
Настройки конфигурации цвета Git
- Настраивает цвет вывода команды ветки Git
- Это значение также применимо к выходным данным ветки Git. slot > является одним из следующих:
- 1. current: текущая ветка
- 2. local: локальный филиал
- 3. remote: ссылка на удаленную ветку в refs/remotes
- 4. upstream: восходящая ветвь отслеживания
- 5. обычный: любая другая ссылка
- Применяет цвета к выходным данным git diff , git log и git show
- Настройка значения slot > в color.diff сообщает git, для какой части патча использовать определенный цвет.
- 1. context: текст контекста diff. Контекст Git — это строки текстового содержимого, отображаемые в diff или patch, которые выделяют изменения.
- 2. обычный: синоним контекста
- 3. мета: применяет цвет к метаинформации различий.
- 4. frag: применяет цвет к «заголовку фрагмента» или «функции в заголовке фрагмента»
- 5. old: применяет цвет к удаленным строкам в diff
- 6. новое: окрашивает добавленные строки diff
- 7. commit: цвета заголовков фиксации в diff
- 8. пробел: устанавливает цвет для любых ошибок пробелов в diff
- Также применимо к git grep. Переменная slot > указывает, к какой части вывода grep применить цвет.
- 1. контекст: несоответствие текста в строках контекста
- 2. имя файла: префикс имени файла
- 3. функция: строки имени функции
- 4. linenumber: префикс номера строки
- 5. match: соответствующий текст
- 6. matchContext: сопоставление текста в строках контекста
- 7.matchSelected: соответствие текста в выделенных строках
- 8. selected: несоответствующий текст в выделенных строках
- 9. разделитель: разделители между полями в строке (:, - и =) и между фрагментами (--)
- Эта переменная применяет цвет для интерактивных подсказок и дисплеев. Примеры: git add --interactive и git clean --interactive
- Включает или отключает цветной вывод при использовании пейджера.
- Включает или отключает вывод цвета для команды git show branch
- Логическое значение, которое включает или отключает вывод цвета для статуса Git.
Используется для указания пользовательского цвета для указанных элементов статуса git. slot > поддерживает следующие значения:
- 1. заголовок
- Требуется текст заголовка области состояния.
- Оба целевых файла добавлены, но не зафиксированы
- Выбирает файлы, которые были изменены, но не добавлены в индекс git.
- Нацелены на файлы, которые не отслеживаются Git
- Применяет цвет к текущей ветке
- Цвет, которым отображается предупреждение "нет перехода".
- Файлы цветов, в которых есть неслитые изменения
Псевдонимы
Возможно, вы знакомы с концепцией псевдонимов из командной строки вашей операционной системы; если нет, то это настраиваемые ярлыки, которые определяют, какая команда будет расширена до более длинных или комбинированных команд. Псевдонимы экономят ваше время и энергию при вводе часто используемых команд. Git предоставляет собственную систему псевдонимов. Обычный вариант использования псевдонимов Git — сокращение команды фиксации. Псевдонимы Git хранятся в файлах конфигурации Git. Это означает, что вы можете использовать команду git config для настройки псевдонимов.
В этом примере создается псевдоним ci для команды git commit. Затем вы можете вызвать git commit, выполнив git ci . Псевдонимы также могут ссылаться на другие псевдонимы для создания мощных комбинаций.
В этом примере создается изменение псевдонима, которое объединяет псевдоним ci в новый псевдоним, использующий флаг --amend .
Форматирование и пробелы
Git имеет несколько функций "пробелов", которые можно настроить для выделения проблем с пробелами при использовании git diff. Проблемы с пробелами будут выделены настроенным цветом color.diff.whitespace
Следующие функции включены по умолчанию:
- blank-at-eol выделяет потерянные пробелы в конце строки
- space-before-tab выделяет пробел, который появляется перед символом табуляции при отступе строки
- blank-at-eof выделяет пустые строки, вставленные в конец файла
Следующие функции отключены по умолчанию
- Отступ без табуляции выделяет строку с отступом с пробелами вместо табуляции
- tab-in-indent выделяет начальный отступ табуляции как ошибку
- конечный пробел – это сокращение от пустого на конце и пустого на конце
- cr-at-eol выделяет символы возврата каретки в конце строки
- tabwidth= определяет, сколько символов занимает табуляция. Значение по умолчанию: 8. Допустимые значения: 1–63.
Обзор
В этой статье мы рассмотрели использование команды git config . Мы обсудили, как команда является убедительным методом редактирования необработанных файлов конфигурации git в файловой системе. Мы рассмотрели основные операции чтения и записи для параметров конфигурации. Мы рассмотрели распространенные шаблоны конфигурации:
- Как настроить редактор Git
- Как переопределить уровни конфигурации
- Как сбросить настройки по умолчанию
- Как настроить цвета git
В целом, git config — это вспомогательный инструмент, позволяющий быстро редактировать необработанные файлы конфигурации git на диске. Мы подробно рассмотрели варианты персональной настройки. Базовые знания параметров конфигурации git являются необходимым условием для настройки репозитория. См. наше руководство там для демонстрации основ.
Хотя императивное программирование часто используется, декларативный подход оказался полезным перед лицом требований к сложным, .
На первый взгляд, разница между микроприложениями и микросервисами просто связана с проблемами внешнего интерфейса и серверной части. Но .
IDP могут предоставить продуктивную и безопасную среду для групп разработчиков. Рассмотрите все за и против, чтобы увидеть, является ли внутренний .
Разрастание UX-дизайна имитирует разрастание городов как в стремлении к росту, так и в потенциально опасных подводных камнях. Вот несколько вещей .
Запах кода может стать причиной плохого кодирования в угольной шахте. А плохое кодирование — это признак того, что требуется рефакторинг. Давайте .
Чтобы успешно передать Agile-разработку на аутсорсинг, организации должны уделять первоочередное внимание общению и обеспечивать достаточную адаптацию.
Nvidia запустила облачную версию своей платформы Omniverse для 3D-моделирования.Компания также представила Omniverse .
Преодолейте сбои AWS, научившись создавать многорегиональную архитектуру, обеспечивающую отказоустойчивость в случае аварии.
Чтобы добиться высокой доступности и отказоустойчивости в AWS, ИТ-администраторы должны сначала понять различия между двумя моделями.
Одного обвиняемого обвиняют в использовании печально известного вредоносного ПО Trisis или Triton против компаний энергетического сектора, включая домен .
Microsoft хочет сделать Defender единственным продуктом для защиты конечных точек, который нужен компаниям, но перевешивают ли преимущества недостатки? Прочтите .
В этом выпуске подкаста Risk & Repeat рассматриваются две громкие утечки, совершенные новой группой угроз Lapsus$, а также действия Microsoft и Okta.
Считаете, что готовы к сертификационному экзамену AWS Certified Solutions Architect? Проверьте свои знания, ответив на эти 12 вопросов и.
Amazon заявила, что ее система мониторинга микроавтобусов предназначена исключительно для обеспечения безопасности водителей. Но многие отраслевые эксперты обеспокоены этим.
Amazon хотела бы укрепить свое глобальное присутствие, но гигант электронной коммерции сегодня сталкивается с препятствиями и проблемами, которых не было.
Теперь, когда Git есть в вашей системе, вам нужно сделать несколько вещей, чтобы настроить среду Git. Вы должны сделать это только один раз на любом данном компьютере; они останутся между обновлениями. Вы также можете изменить их в любое время, повторно выполнив команды.
Git поставляется с инструментом под названием git config, который позволяет вам получать и задавать переменные конфигурации, управляющие всеми аспектами внешнего вида и работы Git. Эти переменные можно хранить в трех разных местах:
Файл [путь]/etc/gitconfig: содержит значения, применяемые к каждому пользователю в системе и ко всем их репозиториям. Если вы передадите параметр --system в git config , он будет читать и писать именно из этого файла. Поскольку это файл конфигурации системы, для внесения в него изменений вам потребуются права администратора или суперпользователя.
Файл ~/.gitconfig или ~/.config/git/config: значения, относящиеся лично к вам, пользователю. Вы можете настроить Git для чтения и записи именно в этот файл, передав параметр --global, и это повлияет на все репозитории, с которыми вы работаете в вашей системе.
файл конфигурации в каталоге Git (то есть .git/config ) любого репозитория, который вы используете в настоящее время: специфичный для этого единственного репозитория. Вы можете заставить Git читать и писать в этот файл с помощью параметра --local, но на самом деле это значение по умолчанию. Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала должным образом.
Каждый уровень переопределяет значения предыдущего уровня, поэтому значения в .git/config имеют приоритет над значениями в [path]/etc/gitconfig .
В системах Windows Git ищет файл .gitconfig в каталоге $HOME (для большинства пользователей C:\Users\$USER). Он также по-прежнему ищет [path]/etc/gitconfig , хотя он относится к корню MSys, где вы решите установить Git в своей системе Windows при запуске установщика. Если вы используете версию 2.x или более позднюю версию Git для Windows, также есть файл конфигурации системного уровня в C:\Documents and Settings\All Users\Application Data\Git\config в Windows XP и в C:\ ProgramData\Git\config в Windows Vista и новее. Этот файл конфигурации можно изменить только с помощью git config -f от имени администратора.
Вы можете просмотреть все свои настройки и их происхождение, используя:
Ваша личность
Первое, что вы должны сделать при установке Git, — указать свое имя пользователя и адрес электронной почты. Это важно, потому что каждый коммит Git использует эту информацию, и она неизменяемо встроена в коммиты, которые вы начинаете создавать:
Опять же, вам нужно сделать это только один раз, если вы передадите параметр --global, потому что тогда Git всегда будет использовать эту информацию для всего, что вы делаете в этой системе. Если вы хотите переопределить это с другим именем или адресом электронной почты для определенных проектов, вы можете запустить команду без параметра --global, когда вы находитесь в этом проекте.
Многие инструменты с графическим интерфейсом помогут вам сделать это при первом запуске.
Ваш редактор
Теперь, когда ваша учетная запись настроена, вы можете настроить текстовый редактор по умолчанию, который будет использоваться, когда Git потребуется ввести сообщение. Если он не настроен, Git использует системный редактор по умолчанию.
Если вы хотите использовать другой текстовый редактор, например Emacs, вы можете сделать следующее:
В системе Windows, если вы хотите использовать другой текстовый редактор, вы должны указать полный путь к его исполняемому файлу. Это может отличаться в зависимости от того, как упакован ваш редактор.
В случае Notepad++, популярного редактора программирования, вы, вероятно, захотите использовать 32-разрядную версию, поскольку на момент написания 64-разрядная версия не поддерживает все подключаемые модули. Если вы работаете в 32-разрядной системе Windows или у вас есть 64-разрядный редактор в 64-разрядной системе, введите что-то вроде этого:
Vim, Emacs и Notepad++ — это популярные текстовые редакторы, часто используемые разработчиками в системах на базе Unix, таких как Linux и macOS или Windows. Если вы используете другой редактор или 32-разрядную версию, найдите конкретные инструкции по настройке вашего любимого редактора с помощью Git в командах git config core.editor.
Вы можете обнаружить, что если вы не настроите свой редактор таким образом, вы попадете в действительно запутанное состояние, когда Git попытается запустить его. Пример в системе Windows может включать преждевременное завершение операции Git во время редактирования, инициированного Git.
Название вашей ветки по умолчанию
По умолчанию Git создаст ветку с именем master, когда вы создадите новый репозиторий с помощью git init . Начиная с Git версии 2.28, вы можете задать другое имя для начальной ветки.
Чтобы установить main в качестве имени ветки по умолчанию, выполните следующие действия:
Проверка настроек
Если вы хотите проверить параметры конфигурации, вы можете использовать команду git config --list, чтобы вывести список всех параметров, которые Git может найти на данный момент:
Вы можете видеть ключи несколько раз, поскольку Git считывает один и тот же ключ из разных файлов (например, [path]/etc/gitconfig и ~/.gitconfig ). В этом случае Git использует последнее значение для каждого уникального ключа, который он видит.
Вы также можете проверить, что Git считает значением определенного ключа, набрав git config :
Поскольку Git может считывать одно и то же значение переменной конфигурации из нескольких файлов, возможно, у вас есть неожиданное значение для одного из этих значений, и вы не знаете, почему. В подобных случаях вы можете запросить у Git происхождение этого значения, и он сообщит вам, за каким файлом конфигурации было последнее слово при установке этого значения:
При использовании git config --global для настройки, в какой файл он будет записываться?
Я не могу найти его в этих местах:
Я не установил ENV?
Моя версия Git: 1.6.5.1.1367.gcd48 — для Windows 7
git config --global --edit должен сообщить вам точное местоположение, независимо от того, какие у вас настройки — просто посмотрите, какой файл появляется в вашем редакторе.
git config --global --list также был полезен, когда он не существует, так как он указывал расположение, где git ожидает, что он будет.
18 ответов 18
Обновление 2016 г.: с git 2.8 (март 2016 г.) вы можете просто использовать:
А в Git 2.26 (1 квартал 2020 г.) вы можете добавить параметр --show-scope
он будет работать с нестандартными местами установки. (например, Git Portable)
(например, последнюю версию PortableGit-2.14.2-64-bit.7z.exe , которую можно распаковать где угодно)
Исходный ответ (2010 г.)
--глобальный
Для вариантов записи: пишите в глобальный файл ~/.gitconfig, а не в репозиторий .git/config .
Поскольку вы используете Git для Windows, может быть неясно, какому расположению это соответствует. Но если вы посмотрите на etc/profile (в C:\Program Files\Git ), вы увидите:
Это означает, что файл находится в C:\Users\MyLogin\.gitconfig для Git в Windows 7.
Я был очень глуп, я не добавил флаг "--global" в команду редактирования! «git config --global --edit» показал файл со всеми моими изменениями конфигурации, «git config --edit» был файлом, который я продолжал открывать и думать, где этот элемент конфигурации editor/compare/etc, который я только что установил! Большое спасибо.
Спасибо. Я видел другие места, где было сказано, что это %USERPROFILE%. На моем компьютере HOMEDRIVE и HOMEPATH переназначаются на сетевой диск. Поиски на моем локальном диске ничего не дали. Так что это очень помогло.
Действительно полезно, у меня была та же проблема: если вы находитесь в домене с подключенным домашним диском, он попытается создать там конфигурацию git. Это было бы хорошим запросом функции — используйте %HOMEDRIVE% или %USERPROFILE%
Почему это называется глобальным, если оно предназначено только для одного пользователя? Разве (для unix) /etc/gitconfig не будет «глобальным», а ~/.gitconfig только «локальным». и я предполагаю, что .git/config "гиперлокальный" ----- По сути, я нахожу термин "глобальный" для этого сбивающим с толку, и мне было интересно, была ли веская причина для номенклатуры?
@PeterAjtai "глобальный", потому что он предназначен для всего вашего репозитория. В отличие от «локального» (только для одного репо) или «системного» (то есть для всех репо, для всех пользователей)
Я также искал глобальный файл .gitconfig на своем компьютере с Windows и нашел этот хитрый трюк с помощью git.
Выполните: git config --global -e и тогда, если вам повезет, вы получите текстовый редактор, загруженный с вашим глобальным файлом .gitconfig. Просто найдите папку оттуда (или попробуйте сохранить как.), и вуаля! :-)
То, что я искал! команда -е! Потому что редактирование свойства за раз просто не входит в мою задачу.
В *nix это ~/.gitconfig . Есть ли у вас дома соответствующий файл?
В Windows вы можете ввести git bash
Если вы хотите легко добраться до него, напишите псевдоним :) Вот мой: alias gitconfig='open -a Sublime\ Text.app ~/.gitconfig' . Используйте любой текстовый редактор.
Windows XP — C:\Documents and Settings\\.gitconfig
Windows Vista+ C:\Users\\.gitconfig
Возможно, лучше описать это как %USERPROFILE%, тогда ответ будет работать для всех версий Windows, прошлых, настоящих и будущих.
За исключением того, что я думаю, что на самом деле это %HOMEDRIVE%%HOMEPATH%, как и в других ответах, что во многих случаях равно %USERPROFILE%, но у некоторых из нас есть ИТ-конфигурации, указывающие вместо этого на подключенный диск.
Глобальное расположение определяется в Windows MsysGit с использованием переменных среды HOMEDRIVE и HOMEPATH, если вы не определили переменную среды HOME. Это подробно описано в сценарии 'profile'.
В моей корпоративной среде HOMEDRIVE имеет формат H:, который затем сопоставляется с сетевым URL-адресом \\share\$. Затем вся партия отображается как «Мои документы», чего не ожидают другие. Возможно, возникли некоторые дополнительные проблемы с переназначением диска на URL. Я даже не могу настроить переменные HOMEDRIVE или HOMEPATH.
В моем случае я определил личную переменную среды HOME и указал ее на D:\git\GitHOME и скопировал все эти файлы GIT (без расширения) в каталог GitHOME для безопасного хранения.
Переменные среды Windows можно задать на вкладке "Дополнительно" в диалоговом окне свойств "Мой компьютер".
Я просматривал ответы, которые собирался опубликовать по переменным HOMEDRIVE и HOMEPATH, так как они только что застали меня во время использования Bower. Похоже, что ряд утилит в Windows читаются из
:\User\\.gitconfig , а сам инструмент Git сохраняет в %HOMEPATH%\.gitconfig . Мне пришлось сделать еще один шаг и скопировать обновленный файл конфигурации из моего H:` (наша сеть использует для этого ту же букву диска) в мою локальную пользовательскую папку, только тогда Git правильно использовал правила при вызове Bower. @ZaLiTHkA, В моей корпоративной сети домашний диск пользователя (H:) также переназначается обратно в папку C:\User\, поэтому я этого не заметил. Если вы сможете определить, какие утилиты FOSS допускают ошибку, то это будет полезная информация, которая поможет приступить к составлению отчетов/исправлению этих инструментов. Если это внутренние корпоративные инструменты, вы предоставлены сами себе ;-)
Если это не сложнее, чем простая строка установки, я не вижу HOME, определенного в сценарии etc\profile. Похоже, он по-прежнему работает так, как описано, но я не понимаю, где в настоящее время устанавливается HOME.
@ojchase Моя часть ответа о том, где написана конфигурация --glob, относится конкретно к Windows. Ядро Linux git пишет в такие места, куда направляет XDG (т.е. я знаю, что linux пишет в другие места и имеет другие соглашения, и, что важно, у него есть корневой каталог, в то время как у Windows есть «Диски» ;-)
@PhilipOakley На самом деле я тоже имел в виду Windows; извините, я был неясен. Объединив ваш ответ и другие, я ожидал увидеть какую-то строку HOME = $HOMEDRIVE$HOMEPATH (или аналогичную) в C:\Program Files\Git\etc\profile, и эта строка, похоже, не существует, но, вероятно, использовалась? Я не смог точно выяснить, что устанавливает $HOME, если только он не установлен переменной среды, чего я бы предпочел не делать.
Когда создается глобальный файл .gitconfig?
Во-первых, git не создает автоматически глобальный файл конфигурации (.gitconfig) во время установки. Файл не создается до тех пор, пока он не будет записан в первый раз. Если вы никогда не устанавливали системную переменную, ее не будет в вашей файловой системе. Я предполагаю, что это может быть источником проблемы.
Один из способов попросить Git создать его — запросить редактирование. Это приведет к принудительному созданию файла.
git config --global --edit
Если вы отслеживаете домашнюю папку пользователя при вводе этой команды, вы увидите, как по волшебству появится файл .gitconfig.
Где хранится конфигурация git?
Вот краткое изложение имен и местоположений файлов конфигурации, связанных с тремя областями Git, а именно: системными, глобальными и локальными:
- Системная конфигурация Git: файл с именем gitconfig находится в папке -git-install-location-/ming/etc
- Глобальная конфигурация Git: файл с именем .gitconfig, расположенный в домашней папке пользователя (C:\Users\git user)
- Локальная конфигурация Git: файл с именем config в папке .git локального репозитория.
Конечно, лучше увидеть, чем поверить, поэтому вот изображение, показывающее каждый файл и каждое местоположение. Я взял изображение из статьи, которую написал на эту тему.
Есть четвертое место, называемое переносимой конфигурацией: здесь упоминаются 4 места; Git для Windows поддерживает четыре уровня конфигурации. На самом низком уровне находятся параметры конфигурации для конкретной машины, известные как «переносимые», и находятся в «%ProgramData%\Git\config»
.Если вы используете TortoiseGit на ПК с Windows, вы можете использовать:
чтобы открыть глобальный файл .gitignore.
Но если вы используете свой ПК с Windows (7) в домене, каталог вашего профиля может быть общим сетевым ресурсом (подключенным как диск). В этом случае TortoiseGit (по крайней мере: 1.6.5.0) указывает вам неправильный каталог (на c.). Дополнительные сведения см. в закрытой проблеме TortoiseGit 922. Или используйте %HOMEDRIVE%%HOMEPATH%, чтобы открыть каталог, содержащий файл .gitignore.
Как отметил @MatrixFrog в своем комментарии, если цель состоит в том, чтобы отредактировать конфигурацию, вы можете запустить:
Эта команда откроет файл конфигурации (в данном случае --global) в выбранном редакторе и дождется закрытия файла (так же, как во время git rebase -i ).
Вы можете использовать это, чтобы выяснить, где находится глобальный .gitconfig, если ваш редактор сообщает вам, в каком каталоге находится файл. Вы также можете использовать другие параметры ( --system , --local и т. д. ), чтобы найти и отредактировать другие местоположения .gitconfig. P.S. -e то же самое, что и --edit
Я использую SmartGit с msysgit в Windows 8.1 и заметил, что файл gitconfig может находиться в трех разных местах:
Но используется тот, который находится в %USERPROFILE%\.gitconfig .
Может быть полезно отметить (для платформ *nix): некоторые типы глобальной конфигурации/информации git хранятся в /usr/share/git-core/ , например сценарии автозаполнения git и следующие (по умолчанию) хуки:
- applypatch-msg
- после обновления
- предварительно зафиксировать
- prepare-commit-msg
- фиксация-сообщение
- предварительно применить исправление
- предварительно перебазировать
- обновить
Каждый из них может содержать собственный набор команд для выполнения во время, описываемое соответствующими именами файлов.
Я использую Windows 7 и использую git в качестве установки, следуя инструкциям на GitHub (год или два назад). Я бы подумал, что это довольно распространенный вариант использования. Ни один из приведенных выше ответов не помог мне, и после большого разочарования я в конце концов нашел свой «настоящий» файл gitconfig в следующем каталоге;
Очевидно, что подставьте свое имя пользователя и предположительно суффикс после PortableGit_ на уникальный идентификатор GUID или что-то подобное.
У меня также была проблема с моим глобальным .gitconfig. Это на тот случай, если у кого-то тоже есть это странное
фатальная ошибка: при чтении файлов конфигурации произошла неизвестная ошибка
Теперь я это исправил. Проблема заключалась во втором .gitconfig в этой папке:
Я не знаю, откуда это взялось. Но теперь все снова работает как часы.
Я считаю важным опубликовать эту цитату:
Git для Windows поддерживает четыре уровня конфигурации. На самом низком уровне находятся параметры конфигурации для конкретной машины, известные как «переносимые», и находятся в «%ProgramData%\Git\config». Один уровень приоритета использует параметры конфигурации установки, известные как «система», которые находятся в «\ mingw64 \ etc \ gitconfig». Для изменения обоих этих файлов конфигурации обычно требуются повышенные привилегии.
Начиная с использования определенных значений, известных как «глобальная» конфигурация, которую можно найти в «%UserProfile%.gitconfig», мы находим « файлы конфигурации, редактируемые пользователем. Параметры конфигурации с наивысшим приоритетом находятся в «локальной» конфигурации, которую обычно можно найти в «.git\config».
В приведенном блоге рекомендуется изменить «систему» или « установка» определенные параметры конфигурации, что хорошо, но пользователи должны ожидать, что другие установки Git не будут поглощать указанные параметры. Если вам нужны настройки для всей машины, используйте «переносимый» файл конфигурации, в противном случае выберите «глобальные» или «локальные» файлы конфигурации.
Надеюсь, люди найдут эту информацию полезной.
Читайте также: