При работе с этим справочником полезно помнить про порядок появления новых полей. Изменения в командной строке нередко выходят раньше, чем обновляется статическая документация, и раньше, чем печатается любая книга. Поэтому если поле не находится в справочнике, это не всегда означает, что его нет: стоит посмотреть текущую конфигурацию через встроенную команду и заметки к версиям. Обратное правило тоже действует: неизвестное поле обычно просто игнорируется, и файл при этом выглядит рабочим - поэтому наличие строки в конфигурации не доказывает, что она что-то делает.

Поле может и исчезнуть или изменить смысл, и это опаснее. Именно поэтому в общей конфигурации команды стоит держать только то, что вы понимаете и проверили. Скопированный чужой файл с двадцатью полями работает ровно до обновления, после которого никто не помнит, зачем половина из них была нужна. Проверка простая и дешёвая: снять поле, увидеть изменение поведения, вернуть. Если разницы нет, поле не нужно.

Из ограничения проектного слоя следует практический вывод, который часто узнают поздно. Уровень автономности и настройки песочницы живут в личном файле, а значит, репозиторий не может задать их за коллегу. Требование все работают с проверкой каждого действия через этот файл не реализуется - оно держится только на договорённости, а договорённость не является контролем. Если требование обязательное, ему нужен другой механизм: списки разрешённого и запрещённого в проектном слое либо административная политика, которую нельзя ослабить снизу.

Полезно знать и про поля атрибуции, потому что у них разумное значение по умолчанию и неочевидные последствия при выключении. По умолчанию к коммитам и запросам на слияние, сделанным агентом, добавляется пометка авторства. Выключать её ради чистоты истории - плохой обмен: через полгода при разборе странного изменения именно эта пометка отвечает на вопрос, писал это человек или агент, и стоит ли искать промпт, а не автора. Один служебный след в сообщении коммита дешевле, чем час археологии.

Практический подход прост: начинать с минимума и добавлять поле только тогда, когда можете назвать проблему, которую оно решает. Такой файл легко ревьюить, легко объяснять новому человеку и легко чинить - потому что каждая строка в нём отвечает на конкретный вопрос эксплуатации.

Инженерный вывод простой: конфигурация - это не место для полноты. Полнота живёт в документации, а в вашем файле живут решения. Чем меньше решений, тем меньше поверхности для расхождений между машинами и для сюрпризов при обновлении.

Типичные провалы предсказуемы. Положить личные предпочтения в проектный файл, где поддерживаются только разрешения. Ожидать от личного файла, что он задаст автономность всей команде. Скопировать чужую конфигурацию целиком. Выключить пометки авторства и потерять след при разборе. И добавлять поля впрок, не имея проблемы, которую они решают.