Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once on any given computer; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
You can view all of your settings and where they are coming from using:
Your Identity
The first thing you should do when you install Git is to set your user name and email address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you start creating:
Many of the GUI tools will help you do this when you first run them.
Your Editor
Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. If not configured, Git uses your system’s default editor.
If you want to use a different text editor, such as Emacs, you can do the following:
On a Windows system, if you want to use a different text editor, you must specify the full path to its executable file. This can be different depending on how your editor is packaged.
In the case of Notepad++, a popular programming editor, you are likely to want to use the 32-bit version, since at the time of writing the 64-bit version doesn’t support all plug-ins. If you are on a 32-bit Windows system, or you have a 64-bit editor on a 64-bit system, you’ll type something like this:
Vim, Emacs and Notepad++ are popular text editors often used by developers on Unix-based systems like Linux and macOS or a Windows system. If you are using another editor, or a 32-bit version, please find specific instructions for how to set up your favorite editor with Git in git config core.editor commands.
You may find, if you don’t setup your editor like this, you get into a really confusing state when Git attempts to launch it. An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit.
Your default branch name
To set main as the default branch name do:
Checking Your Settings
You may see keys more than once, because Git reads the same key from different files ( [path]/etc/gitconfig and
You can also check what Git thinks a specific key’s value is by typing git config :
Since Git might read the same configuration variable value from more than one file, it’s possible that you have an unexpected value for one of these values and you don’t know why. In cases like that, you can query Git as to the origin for that value, and it will tell you which configuration file had the final say in setting that value:
git config
Использование
Самый простой пример использования git config — вызов этой команды с именем конфигурации. При этом отобразится заданное для этого имени значение. Имена конфигурации представляют собой строку, состоящую из иерархической последовательности «раздела» и «ключа», разделенных точкой. Пример: user.email
В этом примере «email» является дочерним свойством блока конфигурации «user». Команда вернет адрес электронной почты (если таковой был указан), который Git свяжет с локально созданными коммитами.
Уровни и файлы git config
Конфигурация глобального уровня зависит от пользователя, то есть применяется к пользователю операционной системы. Значения глобальной конфигурации хранятся в файле, который находится в домашнем каталоге пользователя. Это
/.gitconfig в Unix-системах и C:\ \.gitconfig в системах Windows.
Итак, порядок приоритета уровней конфигурации следующий: локальный, глобальный, системный. Это значит, что при поиске значения конфигурации система Git будет начинать с локального уровня и подниматься до уровня системы.
Запись значения
Для расширения знаний о git config рассмотрим пример записи значения:
Редактор git config — core.editor
Редактор
Команда config
Atom
Инструменты слияния
При возникновении конфликта слияния Git запускает «инструмент слияния». По умолчанию в Git используется внутренняя реализация обычной Unix-программы diff. Внутренняя программа diff в Git представляет собой простейшее средство для просмотра конфликтов слияния. Вместо нее можно использовать любое другое стороннее решение для разрешения конфликтов. Обзор различных инструментов слияния и конфигурации см. в руководстве по советам и инструментам для решения конфликтов с помощью Git.
Выделение выводимой информации цветом
color.ui
Это основная переменная, влияющая на выделение цветом в Git. Если задать этой переменной значение false, выделение любой выводимой в терминале Git информации цветом будет отключено.
Значение переменной color.ui по умолчанию равно auto. Это означает, что маркироваться цветом будет только непосредственный выходной поток терминала. Если же выходной поток перенаправляется в файл или передается другому процессу, то такой вывод цветом не маркируется.
Можно присвоить переменной color.ui значение always. Тогда вывод будет выделяться цветом даже при перенаправлении выходного потока в файлы или конвейеры. Однако это может вызвать проблемы, поскольку принимающий конвейер может не ожидать, что входные данные будут иметь цветовую кодировку.
Значения цветов в Git
Цвет также можно указывать в виде шестнадцатеричного цветового кода, например #ff0000, или в виде одного из 256 цветовых значений ANSI, если ваш терминал их поддерживает.
Настройка цветовой конфигурации в Git
2. color.branch. слот >
5. color.decorate. слот >
9. color.interactive. слот >
13) color.status. слот >
Используется для того, чтобы задать пользовательский цвет для указанных элементов git status. Переменная слот > поддерживает следующие значения:
Псевдонимы
Форматирование и пробелы
В Git есть функции для подсвечивания ошибок с пробелами при использовании git diff. Ошибки с пробелами будут выделяться цветом, указанным в color.diff.whitespace
Следующие возможности по умолчанию включены:
Следующие возможности по умолчанию отключены:
Резюме
В этой статье мы рассказали, как использовать команду git config ; объяснили, почему эта команда удобна для редактирования исходных файлов git config в файловой системе, и рассмотрели основные операции чтения и записи для параметров конфигурации. Кроме того, мы изучили распространенные сценарии настройки конфигурации:
В целом git config — это вспомогательный инструмент, помогающий быстро редактировать исходные файлы git config на диске. Мы подробно рассмотрели параметры индивидуальной настройки. Если вы захотите настроить репозиторий, вам обязательно понадобятся базовые знания параметров конфигурации Git. Демонстрацию основ работы см. в нашем руководстве.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Первоначальная настройка Git
Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git под себя. Это нужно сделать только один раз — при обновлении версии Git настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.
Чтобы посмотреть все установленные настройки и узнать где именно они заданы, используйте команду:
Имя пользователя
Первое, что вам следует сделать после установки Git — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
Многие GUI-инструменты предлагают сделать это при первом запуске.
Выбор редактора
Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно проделать следующее:
В системе Windows следует указывать полный путь к исполняемому файлу при установке другого текстового редактора по умолчанию. Пути могут отличаться в зависимости от того, как работает инсталлятор.
В случае с Notepad++, популярным редактором, скорее всего вы захотите установить 32-битную версию, так как 64-битная версия ещё не поддерживает все плагины. Если у вас 32-битная Windows или 64-битный редактор с 64-битной системой, то выполните следующее:
Vim, Emacs и Notepad++ — популярные текстовые редакторы, которые часто используются разработчиками как в Unix-подобных системах, таких как Linux и Mac, так и в Windows. Если вы используете другой редактор или его 32-битную версию, то обратитесь к разделу Команды git config core.editor за дополнительными инструкциями как использовать его совместно с Git.
В случае, если вы не установили свой редактор и не знакомы с Vim или Emacs, вы можете попасть в затруднительное положение, когда какой-либо из них будет запущен. Например, в Windows может произойти преждевременное прерывание команды Git при попытке вызова редактора.
Настройка ветки по умолчанию
Например, чтобы установить имя main для вашей ветки по умолчанию, выполните следующую команду:
Проверка настроек
Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из /etc/gitconfig и
/.gitconfig ). В таком случае Git использует последнее значение для каждого ключа.
Также вы можете проверить значение конкретного ключа, выполнив git config :
Так как Git читает значение настроек из нескольких файлов, возможна ситуация когда Git использует не то значение что вы ожидали. В таком случае вы можете спросить Git об origin этого значения. Git выведет имя файла, из которого значение для настройки было взято последним:
Введение в Git
Оглавление
Предисловие
Git — самая популярная распределённая система контроля версиями.[1][2]
Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).
Эта статья для тех, кто имеет по крайней мере базовые знания и навык работы с git и желает расширить свои знания.
Здесь рассматриваются только технические аспекты git’а, для более подробного погружения в философию git’а и его внутреннюю реализацию, советую прочитать несколько полезных книг (см. Рекомендуемая литература).
1. Настройка git
Прежде чем начинать работу с git необходимо его настроить под себя!
1.1 Конфигурационные файлы
которая позволит вам изменить стандартное поведение git, если это необходимо, но вы можете редактировать конфигурационные файлы в ручную (я считаю так быстрее).
1.2 Настройки по умолчанию
Есть куча настроек git’а как для сервера так и для клиента, здесь будут рассмотрены только основные настройки клиента.
где name это название параметра, а value его значение, для того что бы задать настройки. Пример:
установит редактор по умолчанию nano.
1.3 Псевдонимы (aliases)
Если вы не хотите печатать каждую команду для Git целиком, вы легко можете настроить псевдонимы. Для создания псевдонима используйте:
где SHORT_NAME это имя для сокращения, а COMMAND команда(ы) которую нужно сократить. Пример:
после выполнения этой команды вы можете просматривать информацию о последнем коммите на текущей ветке выполнив git last.
Я советую вам использовать следующие сокращения (вы также можете определить любые свои):
2. Основы git
2.1 Создание репозитория
2.2 Состояние файлов
Для просмотра состояния файлов в вашем репозитории используйте:
Жизненный цикл файлов Как видно на картинке файлы могут быть не отслеживаемые (Untracked) и отслеживаемые. Отслеживаемые файлы могут находится в 3 состояниях: Не изменено (Unmodified), изменено (Modified), подготовленное (Staged). Если вы добавляете (с помощью git add) «Не отслеживаемый» файл, то он переходит в состояние «Подготовлено». Если вы изменяете файл в состояния «Не изменено», то он переходит в состояние «Изменено». Если вы сохраняете изменённый файл (то есть находящийся в состоянии «Изменено») он переходит в состояние «Подготовлено». Если вы делаете коммит файла (то есть находящийся в состоянии «Подготовлено») он переходит в состояние «Не изменено». Если версии файла в HEAD и рабочей директории отличаются, то файл будет находится в состояний «Изменено», иначе (если версия в HEAD и в рабочем каталоге одинакова») файл будет находится в состояний «Не изменено». Если версия файла в HEAD отличается от рабочего каталога, но не отличается от версии в индексе, то файл будет в состоянии «Подготовлено».
2.3 Работа с индексом
Надеюсь вы поняли, как выглядит жизненный цикл git репозитория. Теперь разберём как вы можете управлять индексом и файлами в вашем git репозитории.
Индекс — промежуточное место между вашим прошлым коммитом и следующим. Вы можете добавлять или удалять файлы из индекса. Когда вы делаете коммит в него попадают данные из индекса, а не из рабочей области.
Что бы просмотреть индекс, используйте git status.
Что бы добавить файлы в индекс используйте
Полезные параметры команды git add:
Что бы удалить файлы из индекса вы можете использовать 2 команды git reset и git restore. git-restore — восстановит файлы рабочего дерева. git-reset — сбрасывает текущий HEAD до указанного состояния. По сути вы можете добиться одного и того же с помощью обеих команд.
Что бы удалить из индекса некоторые файлы используйте:
С помощью git status вы можете посмотреть какие файлы изменились но если вы также хотите узнать что именно изменилось в файлах то воспользуйтесь командой:
2.4 Работа с коммитами
Теперь, когда ваш индекс находится в нужном состояний, пора сделать коммит ваших изменений. Запомните, что все файлы для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. На деле файлы в нём будут, но только их старая версия (если таковая имеется).
Для того что бы сделать коммит ваших изменений используйте:
Полезные опции команды git commit:
где commit это верхний коммит в вашей цепочке с которого вы бы хотели что либо изменить.
pick 2748cb4 first commit edit 750f5ae second commit pick 716eb99 third commit
После сохранения скрипта вы вернётесь в командную строку и git скажет что необходимо делать дальше:
Остановлено на 750f5ae … second commit You can amend the commit now, with
Once you are satisfied with your changes, run
Для удаления коммита Необходимо удалить строку с коммитом. Пример: вы хотите удалить коммит 750f5ae Нужно изменить скрипт с такого: pick 2748cb4 third commit pick 750f5ae second commit pick 716eb99 first commit на такой: pick 2748cb4 first commit pick 716eb99 third commit
Для объединения коммитов Необходимо изменить pick на squash над коммитами которые вы хотите объединить. Пример: вы хотите объединить коммиты 750f5ae и 716eb99. Необходимо изменить скрипт с такого: pick 2748cb4 third commit pick 750f5ae second commit pick 716eb99 first commit На такой pick 2748cb4 third commit squash 750f5ae second commit squash 716eb99 first commit
Заметьте что в интерактивном скрипте коммиты изображены в обратном порядке нежели в git log. С помощью squash вы объедините коммит 750f5ae с 716eb99, а 750f5ae с 2748cb4. В итоге получая один коммит содержащий изменения всех трёх.
2.5 Просмотр истории
вы можете просматривать историю коммитов вашего репозитория. Есть также куча параметров для сортировки и поиска определённого коммита.
Полезные параметры команды git log:
Также вы можете настроить свои формат вывода коммитов с помощью
покажет список коммитов состоящий из хэша времени и сообщения коммита.
2.6 Работа с удалённым репозиторием
Так как git это распределённая СКВ вы можете работать не только с локальными но и с внешними репозиториеми.
Удалённые репозитории представляют собой версии вашего проекта, сохранённые на внешнем сервере.
Для работы с внешними репозиториями используйте:
Если вы с клонировали репозитории через http URL то у вас уже имеется ссылка на внешний. В другом случае вы можете добавить её с помощью
Для загрузки данных с внешнего репозитория используйте git pull [rep] [branch]. Если ваши ветки отслеживают внешние, то можете не указывать их при выполнение git pull. По умолчанию вы получите данные со всех отслеживаемых веток.
Для отправки данных на сервер используйте
Для удаления внешних веток используйте
Для получения подробной информации о внешнем репозитории (адреса для отправки и получения, на что указывает HEAD, внешние ветки, локальные ветки настроенные для git pull и локальные ссылки настроенные для git push)
Для переименования названия внешнего репозитория используйте
Для удаления ссылки на внешний репозитории используйте
3. Ветвление в git
Ветвление это мощные инструмент и одна из главных фич git’а поскольку позволяет вам быстро создавать и переключатся между различным ветками вашего репозитория. Главная концепция ветвления состоит в том что вы можете откланяться от основной линии разработки и продолжать работу независимо от нее, не вмешиваясь в основную линию. Ветка всегда указывает на последний коммит в ней, а HEAD указывает на текущую ветку (см. Указатели в git).
3.1 Базовые операций
Для создания ветки используйте
Здесь branch_name это название для новой ветки, а start_commit это коммит на который будет указывать ветка (то есть последний коммит в ней). По умолчанию ветка будет находится на последнем коммите родительской ветки.
3.2 Слияние веток
Полезные параметры для git merge:
При разрешении конфликта вам необходимо выбрать какую часть изменений из двух веток вы хотите оставить. При открытии конфликтующего файла, в нём будет содержатся следующее: >>>>>> Тут название ветки с которой сливаем
Разрешив конфликт вы должны завершить слияния выполнив коммит.
3.3 Rerere
Rerere — «reuse recorded resolution” — “повторное использование сохраненных разрешений конфликтов». Механизм rerere способен запомнить каким образом вы разрешали некую часть конфликта в прошлом и провести автоматическое исправление конфликта при возникновении его в следующий раз.
Что бы включить rerere выполните
Используйте git rerere status для того что бы посмотреть для каких файлов rerere сохранил снимки состояния до начала слияния.
Используйте git rerere diff для просмотра текущего состояния конфликта.
Если во время слияния написано: Resolved ‘nameFile’ using previous resolution. Значит rerere уже устранил конфликт используя кэш.
4. Указатели в git
в git есть такие указатели как HEAD branch. По сути всё очень просто HEAD указывает на текущую ветку, а ветка указывает на последний коммит в ней. Но для понимания лучше представлять что HEAD указывает на последний коммит.
4.1 Перемещение указателей
В книге Pro git приводится очень хороший пример того как вы можете управлять вашим репозиторием поэтому я тоже буду придерживается его. Представите что Git управляет содержимым трех различных деревьев. Здесь под “деревом” понимается “набор файлов”. В своих обычных операциях Git управляет тремя деревьями:
Используя различные опций этой команды вы можете:
В общем думаю вы сможете придумать намного больше примеров чем я. В заключение скажу, что с помощью git reset можно творить магию…
До этого момента мы описывали основы того, как Git работает и как его использовать, а так же мы познакомились с некоторыми инструментами Git, которые делают его использование простым и эффективным. В этой главе мы рассмотрим некоторые настройки Git и систему хуков, что позволяет настроить поведение Git. Таким образом, вы сможете заставить Git работать именно так как нужно вам или вашей компании.
Конфигурация Git
Сейчас вы познакомитесь с несколькими наиболее интересными опциями, которые можно установить для настройки поведения Git.
Следующее место, куда смотрит Git — это файл
Конфигурация Git это обычные текстовые файлы, поэтому можно вручную установить необходимые значения используя соответствующий синтаксис. Как правило, это проще чем вызывать команду git config для каждого параметра.
Базовая конфигурация клиента
Конфигурационные параметры Git разделяются на две категории: настройки клиента и настройки сервера. Большая часть — клиентские, для настройки ваших личных предпочтений в работе. Существует много, очень много настроек, но подавляющее большинство из них применимо только в конкретных случаях; мы рассмотрим только самые основные и самые полезные из них. Для просмотра полного списка настроек, поддерживаемых вашей версией Git, выполните команду:
Эта команда выведет список доступных настроек с довольно подробным описанием. Так же, соответствующую документацию можно найти здесь https://git-scm.com/docs/git-config.html.
core.editor
Теперь, вне зависимости от того, какой редактор является основным для вашего окружения, Git будет вызывать Emacs для редактирования сообщений.
commit.template
Если указать путь к существующему файлу, то он будет использован как сообщение по умолчанию при создании коммита. Смысл создания шаблона сообщения коммита в том, чтобы лишний раз напомнить себе (или другим) о требованиях к формату или стилю оформления сообщения коммита.
Например, предположим что вы создали файл
Теперь, при создании коммита, в вашем редакторе будет отображаться сообщение изменённого вида:
Если ваша команда придерживается требований к сообщениям коммитов, то создание шаблона такого сообщения и настройка Git на его использование увеличит вероятность соответствия заданным требованиям.
core.pager
В таком случае, Git будет выводить весь текст полностью, вне зависимости от его длины.
user.signingkey
Если вы создаёте подписанные аннотированные теги (как описано в разделе Подпись главы 7), то установка GPG ключа в настройках облегчит вам задачу. Установить ключ можно следующим образом:
Теперь, вам не нужно указывать ключ для подписи каждый раз при вызове команды git tag :
core.excludesfile
/.gitignore_global с содержанием:
help.autocorrect
Если вы ошибётесь в написании команды, Git покажет вам что-то вроде этого:
Git старается угадать, что вы имели ввиду, но при этом команду не выполняет. Если вы установите help.autocorrect в значение 1, то Git будет выполнять эту команду:
Обратите внимание, что команда выполнилась через «0.1» секунды. help.autocorrect — это число, указываемое в десятых долях секунды. Поэтому, если вы установите значение 50, то Git даст вам 5 секунд изменить своё решение перед тем, как выполнить скорректированную команду.
Цвета в Git
Git полностью поддерживает цветовой вывод в терминале, что позволяет быстро и легко визуально анализировать вывод команд. Существует несколько опций для настройки цветов.
color.ui
Git автоматически подсвечивает большую часть своего вывода, но это можно отключить, если вам не нравится такое поведение. Для отключения цветового вывода в терминал, выполните следующую команду:
color.*
Каждая из них имеет вложенную конфигурацию, которую можно использовать для настройки отдельных частей вывода при желании переопределить их цвет. Например, чтобы установить для метаинформации вывода команды diff синий цвет, чёрный фон и полужирный шрифт, выполните команду:
Внешние программы слияния и сравнения
Хоть в Git и есть встроенная программа сравнения, которая описывается в этой книге, вы можете установить вместо неё другую. Вы также можете настроить графический инструмент разрешения конфликтов слияния вместо того, чтобы разрешать конфликты вручную. Мы покажем как настроить Perforce Visual Merge Tool (P4Merge) для разрешения конфликтов слияния, так как это прекрасный и бесплатный инструмент.
Если у вас есть желание попробовать P4Merge, то она работает на всех основных платформах, так что у вас должно получиться. В примерах мы будем использовать пути к файлам, которые работают в системах Linux и Mac; для Windows вам следует изменить /usr/local/bin на путь к исполняемому файлу у вас в системе.
Скрипт вызова программы сравнения проверяет наличие 7 аргументов и передаёт 2 из них в скрипт вызова программы слияния. По умолчанию, Git передаёт следующие аргументы программе сравнения:
Так же следует убедиться, что созданные скрипты могут исполняться:
или вручную отредактировать файл
/.gitconfig добавив соответствующие строки:
После этого, вы можете запускать команды diff следующим образом:
Вместо отображения вывода diff в терминале Git запустит P4Merge, выглядеть это будет примерно так:
Если при слиянии двух веток у вас возникнут конфликты, выполните команду git mergetool ; она запустит P4Merge чтобы вы могли разрешить конфликты используя графический интерфейс.
Используя скрипт обёртку для вызова внешних программ, вы можете легко изменить вызываемую программу. Например, чтобы начать использовать KDiff3 вместо P4Merge, достаточно изменить файл extMerge :
Теперь, Git будет использовать программу KDiff3 для сравнения файлов и разрешения конфликтов слияния.
Git изначально настроен на использование ряда других инструментов для разрешения конфликтов слияния, поэтому вам не нужно дополнительно что-то настраивать. Для просмотра списка поддерживаемых инструментов, выполните команду:
Если вы хотите использовать KDiff3 только для разрешения конфликтов слияния, но не для сравнения, выполните команду:
Форматирование и пробелы
Проблемы форматирования и пробелов являются одними из самых неприятных и незаметных проблем, с которыми сталкивают разработчики при совместной работе, особенно используя разные платформы. Это легко может произойти с патчами или с любой другой совместной работой, так как редакторы молча исправляют несоответствия, и если ваши файлы когда либо касаются систем Windows, то переносы строк могут быть заменены. В Git есть несколько настроек, чтобы справиться с этими проблемами.
core.autocrlf
Если вы программируете в Windows и работаете с людьми, которые не используют её (или наоборот), рано или поздно, вы столкнётесь с проблемами переноса строк. Это происходит потому, что Windows при создании файлов использует для обозначения переноса строки два символа «возврат каретки» и «перевод строки», в то время как Mac и Linux используют только один — «перевод строки». Это незначительный, но невероятно раздражающий факт кроссплатформенной работы; большинство редакторов в Windows молча заменяют переносы строк вида LF на CRLF или вставляют оба символа, когда пользователь нажимает клавишу ввод.
Если у вас система Linux или Mac, то вам не нужно автоматически конвертировать переносы строк при извлечении файлов; однако, если файл с CRLF окончаниями строк случайно попал в репозиторий, то Git может его исправить. Можно указать Git конвертировать CRLF в LF во время коммита, но не наоборот, установив настройке core.autocrlf значение input :
Такая конфигурация позволит вам использовать CRLF переносы строк в Windows, при этом в репозитории и системах Mac и linux будет использован LF.
core.whitespace
Git поставляется настроенным на обнаружение и исправление некоторых проблем с пробелами. Он в состоянии найти шесть основных проблем, обнаружение трёх из них включено по умолчанию, а трёх других — выключено.
Или можно указать только часть проверок:
Так же можно указать Git автоматически исправлять эти проблемы перед применением патча:
Конфигурация сервера
Для серверной части Git не так много настроек, но есть несколько интересных, на которые стоит обратить внимание.
receive.fsckObjects
Теперь, Git будет проверять целостность репозитория до принятия новых данных для уверенности, что неисправные или злонамеренные клиенты не смогут отправить повреждённые данные.
receive.denyNonFastForwards
Для запрета перезаписи истории установите receive.denyNonFastForwards :
Сделать то же самое можно другим способом — используя хук на стороне сервера, мы рассмотрим его немного позже. Этот подход позволяет более гибко настроить ограничения, например, запретить перезапись истории определённой группе пользователей.
receive.denyDeletes
Политику denyNonFastForwards можно обойти, удалив ветку и создав новую с таким же именем. Для предотвращения этого, установите receive.denyDeletes в значение true :
Эта команда запретит удаление веток и тегов всем пользователям. Чтобы удалить ветку, придётся удалить все соответствующие ей файлы на сервере вручную. Куда более интересный способ — это настроить права пользователей, с ним вы познакомитесь в разделе Пример принудительной политики Git.
