Вы можете создать наборы правил ветви или тегов, чтобы управлять взаимодействием пользователей с выбранными ветвями и тегами в репозитории. Вы также можете создавать наборы правил push-уведомлений для блокировки отправки в частный или внутренний репозиторий и всю сеть вилки этого репозитория.
При создании набора правил можно разрешить определенным пользователям обходить правила в наборе правил. Это могут быть пользователи с определенными ролями, определенными командами или GitHub Apps.
Для наборов правил push обхода применяются к репозиторию и всей сети вилки репозитория. Это означает, что единственными пользователями, которые могут обойти этот набор правил для любого репозитория в всей сети вилки этого репозитория, являются пользователи, которые могут обойти этот набор правил в корневом репозитории.
Дополнительные сведения о создании наборов правил и обходе разрешений см. в статье [AUTOTITLE и Создание наборов правил для репозиториев в организации](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository).
Ограничение создания
Если выбрано, только пользователи с разрешениями обхода могут создавать ветви или теги, имя которых соответствует указанному шаблону.
Ограничение обновлений
Если выбрано, только пользователи с разрешениями обхода могут отправляться в ветви или теги, имя которых соответствует указанному шаблону.
Ограничение удаления
Если выбрано, только пользователи с разрешениями обхода могут удалять ветви или теги, имя которых соответствует указанному шаблону. Это правило выбрано по умолчанию.
Требовать линейный журнал
Принудительное применение журнала линейной фиксации запрещает участникам совместной работы отправлять фиксации слиянием в целевые ветви или теги. Это означает, что любые запросы на вытягивание, объединенные в ветвь или тег, должны использовать слияние скваша или слияние повторной базы данных. Журнал строго линейной фиксации может помочь командам восстановить изменения проще. Дополнительные сведения о методах слияния см. в разделе Сведения о слиянии запросов на вытягивание.
Прежде чем требовать линейный журнал фиксаций, репозиторий должен разрешить слияние со сжатием или слияние с перемещением из одной ветви в другую. Дополнительные сведения см. в разделе Настройка слияния запросов на вытягивание.
Требовать очередь слияния
Примечание.
- Это правило недоступно для наборов правил, созданных на уровне организации. Дополнительные сведения о создании наборов правил на уровне репозитория см. в разделе Создание наборов правил для репозитория.
Вы можете требовать, чтобы слияние выполнялось с очередью слияния на уровне репозитория. Дополнительные сведения о очередях слиянием см. в разделе Слияние для запроса на вытягивание с очередью слияния.
Дополнительные параметры
Вы можете настроить различные параметры для правила очереди слияния.
-
**Метод слияния:** метод, используемый при слиянии изменений из запросов на вытягивание. -
**Параллелизм сборки:** ограничение количества запросов на вытягивание в очереди, запрашивающих проверки и выполнение рабочего процесса одновременно.- Этот параметр определяет, когда очередь слияния отправляет событие веб-перехватчика, которое активирует
merge_group.checks_requestedрабочие процессы GitHub Actions, настроенные для выполненияmerge_group. Дополнительные сведения см. в разделе События и полезные данные веб-перехватчика. - Например, если в очередь добавляются 5 запросов на вытягивание, а параметр параллелизма сборки равен 3, очередь слияния отправляет
checks_requestedсобытие для первых 3 запросов на вытягивание. Когда он получает результат для одного из этих запросов на вытягивание, очередь слияния будет отправлять событие для 4-го запроса на вытягивание и т. д.
- Этот параметр определяет, когда очередь слияния отправляет событие веб-перехватчика, которое активирует
-
**Минимальный или максимальный размер группы:** количество запросов на вытягивание, которые будут объединены в группу. -
**Время ожидания до минимального размера группы (минут).** Время ожидания очереди слияния будет ожидать после добавления первого запроса на вытягивание в очередь для выполнения минимального размера группы. По истечении этого времени минимальный размер группы будет игнорироваться, а меньшая группа будет объединена. -
**Требовать от всех записей очереди для передачи необходимых проверок:**- Если этот параметр включен, каждый элемент в группе слияния должен пройти все необходимые проверки.
- Если этот параметр отключен, то только фиксация в голове группы слияния, т. е. фиксация, содержащая изменения из всех запросов на вытягивание в группе, должна пройти необходимые проверки для слияния.
-
**Время ожидания проверки состояния (минуты):** максимальное время для обязательная проверка состояния, чтобы сообщить о выводе. После этого много времени истекло, проверки, которые не сообщили о выводе, будут предполагаться, что не удалось
Требовать успешного развертывания перед слиянием
Примечание.
Это правило недоступно для наборов правил, созданных на уровне организации.
Вы можете потребовать успешного развертывания изменений в определенные среды, прежде чем можно будет выполнить слияние ветви. Например, это правило можно использовать для успешного развертывания изменений в промежуточную среду перед слиянием изменений в ветвь по умолчанию.
Требовать подписанные фиксации
При включении обязательного подписывания фиксации в ветви участники совместной работы и боты могут отправлять в ветвь только подписанные и проверенные фиксации. Дополнительные сведения см. в разделе Сведения о проверке подписи фиксации.
Правила защиты ветви и наборы правил работают по-разному при создании ветви: с наборами правил мы проверяем только фиксации, недоступные из других ветвей, в то время как при использовании правил защиты ветви мы не проверяем подписанные фиксации, если только вы не ограничиваете отправки, которые создают соответствующие ветви. При обновлении ветви мы по-прежнему проверяем все фиксации в указанном диапазоне, даже если фиксация недоступна из других ветвей.
С обоими методами мы используем verified_signature? для подтверждения наличия допустимой подписи фиксации. Если нет, обновление не принимается.
Примечание.
- Если вы включили режим бдительности в параметрах учетной записи, которые указывают на то, что фиксации всегда будут подписаны, все фиксации, которые GitHub идентифицируются как "Частично проверенные" в ветвях, для которых требуются подписанные фиксации. Дополнительные сведения о режиме бдения см. в разделе Отображение состояний проверки для всех фиксаций.
- Если участник совместной работы отправляет неподписанную фиксацию в ветвь, требующую подписания фиксации, ему потребуется переместить изменения из одной ветви в другую, чтобы включить проверенную подпись, а затем принудительно отправить переписанную фиксацию в ветвь.
Вы всегда можете отправлять локальные фиксации в ветвь, если они подписаны и проверены. Вы также можете объединить подписанные и проверенные фиксации в ветвь с помощью запроса на вытягивание. Однако вы не можете скваш и объединить запрос на вытягивание в ветвь на GitHub, если вы не являетесь автором запроса на вытягивание. Вы можете squash и объединить запросы на вытягивание локально. Дополнительные сведения см. в разделе Локальное получение для изменения запросов на вытягивание.
Дополнительные сведения о методах слияния см. в разделе О методах слияния на GitHub.
Требовать запрос на вытягивание перед слиянием
Вы можете требовать, чтобы все изменения в целевой ветви были связаны с запросом на вытягивание. Запрос на вытягивание не обязательно должен быть утвержден, но его необходимо открыть.
Дополнительные параметры
Примечание.
Если при отправке новых фиксаций при отправке новых фиксаций и (или ) требовать утверждения последней проверяемой отправки вручную создание фиксации слияния для запроса на вытягивание и отправка ее непосредственно в защищенная ветвь завершится ошибкой, если содержимое слияния точно не соответствует слиянию, созданному GitHub для запроса на вытягивание.
Кроме того, при использовании этих параметров утверждения проверки будут отклонены как устаревшие, если база слияния вводит новые изменения после отправки проверки. База слияния — это фиксация, которая является последним общим предком между ветвью раздела и базовая ветвь. Если база слиянием изменяется, запрос на вытягивание не может быть объединен до тех пор, пока кто-то не утвердит работу снова.
Администраторы репозитория или пользовательские роли с разрешением "Изменить правила репозитория" могут требовать, чтобы все запросы на вытягивание получали определенное количество утверждений, прежде чем кто-то объединяет запрос на вытягивание в защищенная ветвь. Вы можете требовать утверждения проверок от пользователей с разрешениями на запись в репозиторий или от назначенного владельца кода.
Если включить необходимые проверки, сотрудники могут отправлять изменения в ветвь только с помощью запроса на вытягивание, утвержденного требуемым количеством рецензентов с разрешениями на запись.
Если кто-то выбирает вариант изменения запроса в проверке, то этот пользователь должен утвердить запрос на вытягивание перед объединением запроса на вытягивание. Если рецензент, требующий изменения для запроса на вытягивание, недоступен, любой пользователь с разрешениями на запись в репозиторий может отклонить блокирующую проверку.
Даже если все обязательные проверяющие одобрили запрос на вытягивание, участники совместной работы не могут выполнить слияние для запроса на вытягивание, если есть другие открытые запросы на вытягивание, имеющие главную ветвь, указывающую на ту же фиксацию с ожидающими или отклоненными проверками. Кто-то с разрешениями на запись сначала должен утвердить или закрыть блокировку проверки на другие запросы на вытягивание.
При необходимости можно закрыть утверждения устаревших запросов на вытягивание при отправке фиксаций, влияющих на дифф в запросе на вытягивание. GitHub записывает состояние диффа в момент утверждения запроса на вытягивание. Это состояние представляет набор изменений, утвержденных рецензентом. Если дифф изменяется из этого состояния (например, так как участник отправляет новые изменения в ветвь запроса на вытягивание или щелкает ветвь обновления или связанная запрос на вытягивание объединяется в целевую ветвь), утверждение отзыва закрывается как устаревший, и запрос на вытягивание не может быть объединен, пока кто-то не утвердит работу снова. Сведения о целевой ветви см. в разделе Сведения о запросах на вытягивание.
При необходимости можно требовать проведение проверок от владельцев кода. Если это сделать, любой запрос на вытягивание, который изменяет содержимое с помощью владелец кода, должен быть утвержден этим владелец кода, прежде чем запрос на вытягивание можно будет объединить в защищенная ветвь. Обратите внимание, что если код имеет несколько владельцев, утверждение от любого из владелец кода будет достаточно для удовлетворения этого требования. Дополнительные сведения см. в разделе О владельцах кода.
При необходимости вы можете требовать от кого-то другого пользователя утверждение, отличного от последнего пользователя, чтобы отправить в ветвь, прежде чем запрос на вытягивание можно объединить. Это означает, что по крайней мере один другой авторизованный рецензент одобрил любые изменения. Например, "последний рецензент" может проверить, что последний набор изменений включает отзывы от других отзывов и не добавляет новое, неосмотримое содержимое.
Для сложных запросов на вытягивание, которые требуют многих отзывов, требуя утверждения от кого-то другого, кроме последнего человека, чтобы нажать на компромисс, который избегает необходимости отклонить все устаревшие проверки: с этим вариантом", "устаревшие" проверки не отклоняются, и запрос на вытягивание остается утвержденным до тех пор, пока кто-то другой, кроме человека, который сделал последние изменения утверждает его. Пользователи, которые уже проверили запрос на вытягивание, могут повторно применить после последней отправки, чтобы выполнить это требование. Если вы обеспокоены запросами на вытягивание "угон" (где неутвержденное содержимое добавляется в утвержденные запросы на вытягивание), это безопаснее, чтобы закрыть устаревшие проверки.
При необходимости можно требовать разрешение всех примечаний к запросу на вытягивание, прежде чем его можно объединить с ветвью. Это гарантирует, что перед слиянием все комментарии будут разрешены или подтверждены.
При необходимости можно требовать тип слияния слиянием, сквош или перебазу. Это означает, что целевые ветви могут быть объединены только на основе разрешенного типа. Кроме того, если репозиторий отключил метод слияния и набор правил, необходимый другой метод, слияние будет заблокировано. См . раздел AUTOTITLE.
Обязательные рецензенты
По желанию, вы можете требовать проверку или одобрение от конкретных команд, если pull request меняет определённые файлы или каталоги. Вы можете выбрать до 15 разных команд, и для каждой команды потребуется определённое количество одобрений от членов команды.
Выпадающее меню Reviewer позволяет выбрать любую команду, которая входит в область действия правила.
-
**Правила всей организации**: команда должна принадлежать организации. -
**Правила на уровне репозитория**: команда должна принадлежать организации, которой владеет репозиторий.
Это правило недоступно в пользовательских репозиториях, так как в них нет команд.
Обязательные одобрения могут быть установлены от 0 (0) до 10. Отсутствие необходимости одобрения означает, что команда будет добавлена для видимости, но команда не обязана одобрять запрос.
Для каждой команды можно задать список шаблонов файлов, который определяет, к каким файлам применяется эта настройка. Формат этого списка файлов совпадает со стандартным .gitignore файлом:
- Узор, начинающийся с восклицательного знака (
!) — это отрицание. Это приведёт к тому, что пути, соответствующие более ранним шаблонам, не будут требовать одобрения. - Паттерны сопоставляются по порядку, поэтому отрицаемые паттерны могут «развлекать» файлы, соответствовавшие предыдущим правилам.
Обязательное прохождение проверок состояния перед слиянием
Обязательные проверки состояния убедитесь, что все необходимые тесты CI передаются, прежде чем сотрудники смогут вносить изменения в ветвь или тег, предназначенный для набора правил. Обязательные проверки состояния могут быть проверками или состояниями. Дополнительные сведения см. в разделе Сведения о проверках состояния.
С помощью API состояния фиксации можно разрешить внешним службам пометить фиксации соответствующим состоянием. Дополнительные сведения см. в разделе Конечные точки REST API для состояния фиксации.
После включения обязательная проверка состояния все обязательная проверка состояния должны передаваться, прежде чем сотрудники могут объединить изменения в ветвь или тег. При необходимости можно выбрать "Не требовать проверки состояния при создании", если вы хотите разрешить создание ветви независимо от результата проверки состояния.
Любой пользователь или интеграция с разрешениями на запись в репозиторий может задать состояние проверки состояния в репозитории, но в некоторых случаях может потребоваться только принять проверку состояния из определенного GitHub App. При добавлении правила обязательная проверка состояния можно выбрать приложение в качестве ожидаемого источника обновлений состояния. Приложение должно быть установлено в репозитории с statuses:write разрешением, должно быть недавно отправлено выполнение проверки и должно быть связано с предварительно существующим обязательная проверка состояния в наборе правил. Если состояние задано любым другим человеком или интеграцией, слияние не будет разрешено. Если выбрать "любой источник", вы по-прежнему можете вручную проверить автора каждого состояния, указанного в поле слияния.
Чтобы устранить неполадки при настройке проверки состояния в наборе правил, см. раздел AUTOTITLE.
Примечание.
Для проверки состояния уровня организации приложение должно быть установлено с разрешениемstatuses:write. При настройке наборов правил на уровне организации отображаются только приложения с этим разрешением.
Вы можете думать о обязательная проверка состояния как "свободный" или "строгий". Выбранный тип требуемой проверки состояния определяет, должна ли ваша ветвь быть обновлена в соответствии с базовой ветвью перед слиянием.
| Тип требуемой проверки состояния | Параметр | Требования к слиянию | Рекомендации |
|---|
**Строгий** | Установлен флажок **Требовать актуальность ветвей перед слиянием**. | Перед слиянием ветвь **раздела должна** быть обновлена базовая ветвь. | Это поведение по умолчанию для требуемых проверок состояния. Дополнительные сборки могут потребоваться, так как вам потребуется обновить главная ветвь после обновления целевой ветви другими участниками совместной работы.|
| Нестрогая | Флажок Требовать актуальность ветвей перед слиянием****не установлен. | Перед слиянием ветвь не должна быть обновлена в соответствии с базовой ветвью. | У вас будет меньше требуемых сборок, так как вам не нужно будет обновлять главную ветвь после того, как другие участники совместной работы объединят запросы на вытягивание. При наличии изменений, несовместимых с главной ветвью, проверки состояния могут завершиться ошибкой после слияния ветви. | | Отключен | Флажок Требовать прохождения проверок состояния перед слиянием****не установлен. | Ветвь не имеет ограничений на слияние. | Если требуемые проверки состояния не включены, участники совместной работы могут объединить ветвь в любое время независимо от того, обновлена ли она в соответствии с базовой ветвью. Это повышает вероятность возникновения несовместимых изменений.
Сведения об устранении неполадок с состоянием см. в разделе Устранение неполадок с обязательными проверками состояния.
Блокирование принудительной отправки
Вы можете запретить пользователям принудительная отправка в целевые ветви или теги. Это правило включено по умолчанию.
Если кто-то принудительная отправка в ветвь или тег, зафиксирует, что другие сотрудники на основе своей работы могут быть удалены из истории ветви или тега. Это может привести к конфликт слияния или поврежденным запросам на вытягивание. Принудительное принудительное отправку также можно использовать для удаления ветвей или указания ветви на фиксации, которые не были утверждены в запросе на вытягивание.
Включение принудительная отправка не переопределяет другие правила. Например, если ветви требуется линейный журнал фиксаций, принудительно отправлять фиксации слияния в эту ветвь невозможно.
Требуется code scanning результатов
Если репозитории настроены с помощью code scanning, можно использовать наборы правил, чтобы предотвратить объединение запросов на вытягивание при выполнении одного из следующих условий:
- Требуемый инструмент находит code scanning оповещение о тяжести, определённой в наборе правил.
- Анализ необходимого инструмента всё ещё продолжается.
- Требуемый инструмент не настроен для репозитория.
Дополнительные сведения см. в разделе Настройка защиты от сканирования кода слиянием. Дополнительные сведения о code scanningсм. в разделе Сведения о проверке кода.
Требовать передачи рабочих процессов перед слиянием
Рабочие процессы набора правил можно настроить в организации или enterprise level, чтобы требовать передачи рабочих процессов перед объединением запросов на вытягивание. Дополнительные сведения см. в разделе Создание наборов правил для репозиториев в организации.
Дополнительные сведения об устранении неполадок с параметрами конфигурации общих наборов правил см. в разделе Устранение неполадок правил.
Использование файла рабочего процесса
Чтобы использовать это правило, необходимо сначала создать файл рабочего процесса. Файл рабочего процесса должен находиться в репозитории, который соответствует видимости репозиториев, в которые требуется запустить его. В частности, общедоступный рабочий процесс может выполняться в любом репозитории в организации, внутренний рабочий процесс может выполняться только во внутренних и частных репозиториях, а частный рабочий процесс может выполняться только в частных репозиториях. Дополнительные сведения см. в разделе Рабочие процессы.
Если файл рабочего процесса находится во внутреннем или частном репозитории, и вы хотите использовать рабочий процесс в других репозиториях в организации, необходимо разрешить доступ к рабочему процессу извне репозитория. Дополнительные сведения см. в статье "Разрешение доступа к компонентам в внутреннем репозитории " или разрешение доступа к компонентам в частном репозитории.
При добавлении этого правила в набор правил в параметрах организации укажите исходный репозиторий и рабочий процесс, который требуется применить.
Использование режима "Оценка" для рабочих процессов набора правил
Если рабочий процесс набора правил выполняется в режиме "Оценка" и передается, можно задать рабочий процесс набора правил в режим "Активный" и объединить запрос на вытягивание без активации нового запуска рабочего процесса.
Если перед созданием набора правил в режиме оценки вы можете объединить запрос на вытягивание, так как набор правил не применяется.
Дополнительные сведения о состоянии применения см. в разделе Создание наборов правил для репозитория.
Поддерживаемые триггеры событий
Рабочие процессы набора правил поддерживают использование pull_request``pull_request_target событий и merge_group событий. В результате необходимо указать одно или несколько этих событий в on: разделе рабочего процесса, чтобы рабочий процесс выполнялся набором правил.
Все фильтры, указанные для поддерживаемых событий, игнорируются , например, branches, branches-ignoreи paths``types т. д. Рабочий процесс активируется только и всегда активируется по умолчанию типами действий поддерживаемых событий.
| Мероприятие | Типы действий по умолчанию |
|---|---|
pull_request | opened, , synchronize``reopened |
pull_request_target | opened, , synchronize``reopened |
merge_group | checks_requested |
Назначение конкретных ветвей с помощью рабочего процесса набора правил
Применение этого правила блокирует прямые отправки, так как рабочие процессы набора правил выполняются как часть запроса на вытягивание и процесс слияния очереди. По этой причине это правило не следует применять к набору правил, предназначенным для всех ветвей в репозитории.
Это правило следует добавить только в наборы правил, предназначенные для ветвей, в которых все изменения в ветви выполняются запросами на вытягивание.
При необходимости можно выбрать "Не требовать проверки рабочих процессов при создании", если вы хотите разрешить создание ветви независимо от результата проверки состояния.
Ограничения метаданных
Примечание.
При слиянии ветви все фиксации в этой ветви должны соответствовать любым требованиям к метаданным для базовая ветвь.
При использовании анкеров конца строки в регулярных выражениях используйте \n?$ вместо $ одиночного использования. Опциональный \n? вариант совпадает с последующей новой строкой, которая может присутствовать в потоках Git push/CLI, при этом работая для коммитов, созданных через веб-интерфейс и API.
Организации в плане GitHub Enterprise могут получить доступ к дополнительным правилам для управления форматированием метаданных фиксации. Для определения шаблона, которому должны соответствовать метаданные фиксации, можно использовать литеральные строки или синтаксис регулярных выражений. Например, можно требовать, чтобы сообщения фиксации содержали номер проблемы GitHub или что у фиксации или автора есть адрес электронной почты, заканчивающийся @octoorg.com. Кроме того, можно управлять форматом новых имен ветвей и имен тегов. Выбор полезных регулярных выражений для метаданных фиксации см. в разделе Создание наборов правил для репозитория.
Если участник пытается обновить ветвь или тег с фиксацией, которая не соответствует вашим требованиям, участник увидит ошибку, сообщающую им, что было неправильно с их фиксацией. Эта ошибка может отображаться как в командной строке, так и при отправке пользователем данных на GitHub.com, когда пользователь пытается зафиксировать или объединить запрос на вытягивание. Фиксации неизменяемы в Git: после создания фиксации участник не может изменять метаданные фиксации, поэтому, возможно, потребуется выполнить перебазу для перезаписи журнала фиксаций с новыми фиксациями, прежде чем они смогут успешно внести свой вклад в репозиторий.
Ограничения метаданных полезны для обеспечения согласованности между фиксациями в журнале ветви. Это может быть полезно для обеспечения соблюдения рекомендаций, таких как спецификация "Обычные фиксации " или для интеграции с инструментами, основанными на метаданных фиксации. Например, проще запускать скрипты на основе содержимого сообщения фиксации, если каждое сообщение соответствует предсказуемому формату.
Важные рекомендации по ограничениям метаданных
Ограничения метаданных блокируют "ref updates". Если участник отправляет работу, содержащую фиксацию, которая не соответствует требованиям, отправка не отклоняется, но ветвь или тег, на которые они нацелены, не обновляются. Технически фиксации по-прежнему входят в репозиторий: фиксации будут "извлекаемыми" (вы можете перейти к ним в репозитории), но не "доступны" (они не подключены к журналу ветви или тега). Если отправка участника также включает в себя работу с другими ветвями или тегами, с фиксациями, которые соответствуют требованиям этих ветвей или тегов, эти ссылки будут успешно обновлены.
Ограничения метаданных могут повысить трение для людей, участвующих в репозитории. Как правило, если вы налагаете ограничения метаданных, следует сделать это в ограниченном наборе ветвей, чтобы избежать влияния на повседневную работу участников. Например, вместо того, чтобы требовать согласованных сообщений о фиксации в любой ветви раздела, над которой может работать участник, необходимо требовать только согласованные сообщения main о фиксации, а затем требовать запросы mainна извлечение.
При использовании слияний скваша отдельные фиксации в запросе на вытягивание игнорируются. Вместо этого ограничения проверяются только в отношении метаданных одной результирующей фиксации слияния. Страница запроса на вытягивание проверяет эти сведения до разрешения слияния, обеспечивая соответствие окончательной фиксации. Для ограничений метаданных, которые применяются к сообщениям электронной почты фиксации, шаблон также должен включаться noreply@github.com для слияний скваш для удовлетворения ограничения.
При добавлении ограничений метаданных в существующую ветвь или тег правила применяются для новых фиксаций, отправленных в ветвь или тег из этой точки вперед, но они не применяются к существующей истории ветви или тега.
Ограничение путей к файлам
Запретить фиксации, включающие изменения в указанные пути к файлам, отправляться в репозиторий. Ограничение составляет 200 записей и до 200 символов в каждой записи.
Для этого можно использовать fnmatch синтаксис. Например, ограничение, предназначенное для test/demo/**/* предотвращения отправки в файлы или папки в test/demo/ каталоге. Ограничение, предназначенное для test/docs/pushrules.md предотвращения отправки pushrules.md в файл в каталоге test/docs/ . Дополнительные сведения см. в разделе Создание наборов правил для репозитория.
Ограничение длины пути к файлу
Запрет фиксаций, включающих пути к файлам, превышающие указанное ограничение символов, отправляется в репозиторий.
Ограничение расширений файлов
Запретить фиксации, включающие файлы с указанными расширениями файлов, отправляться в репозиторий. Ограничение составляет 200 записей и до 200 символов в каждой записи.
Ограничение размера файла
Запретить фиксации, превышающие указанное ограничение размера файла, отправляться в репозиторий.