Правило пережило свою причину
Строка-исключение для каталога с рабочими скриптами появилась по понятной причине: там когда-то лежали приватные скрипты с паролями внутри. Причина ушла, правило осталось — и продолжило прятать всё, что в каталог приезжало потом.
Замер по текущему состоянию: ни в одном найденном файле нет захардкоженного секрета. Правило защищало от того, чего в каталоге уже нет, и мешало тому, что там появилось.
Признак, по которому такое видно заранее. В общей ветке из того же каталога всё-таки лежат 580 файлов — их вносили точечно, принудительным добавлением. Люди обходили правило по одному файлу вместо того, чтобы его поправить. Регулярный ручной обход правила — это и есть сигнал, что правило пережило свою причину.
Сверять по содержимому, а не по имени
Первый прогон сверки даёт число, от которого хочется хвататься за голову: 2575 файлов каталога отсутствуют в основной ветке по своему пути. Реальная потеря оказалась в десять раз меньше — потому что «нет по этому пути» и «нет нигде» разные утверждения.
| Шаг сверки | Файлов | Что означает |
|---|---|---|
| Всего в каталоге на диске | 3937 | исходный объём |
| Нет в основной ветке по этому пути | 2575 | первое, пугающее число |
| Из них исполняемых — их и разбирали | 525 | остальное данные и выгрузки |
| Копия есть в ветке, байт в байт | 260 | ложная тревога, файл переехал |
| Копия есть, содержимое разошлось | 10 | ручной разбор, какая версия живая |
| Реально вне git | 255 | 147 — на них ссылается то, что уже в git; 108 не ссылается никто |
Строка про 147 — самая неприятная. Ссылка из файла, который лежит в общей ветке, на файл, которого в общей ветке нет: у любого, кто возьмёт репозиторий чистым, это место просто не работает, и причину он будет искать в своей среде.
Итог разбора: внесли 110 файлов, проверка компиляцией 110 из 110 зелёная; осталось вне git 145 — это 141 черновик и 4 файла с персональными данными. Последние четыре и есть та причина, ради которой исключение писали. Правило нужно было не снимать, а сузить до них.
Другая грань: «кода нигде нет», а он в неслитой ветке
Обратную сторону того же класса поймали в разборе методики. Первый вывод автора звучал так: нужного кода у нас нет нигде, надо писать с нуля. Состязательная перепроверка отдельным проходом этот вывод опровергла: код живёт в неслитой ветке, 5 файлов, и проверено не глазами, а командой сравнения предков — ветка в основную не влита.
Практический вывод простой: «в основной ветке нет» — это не «нет». Поиск по одной ветке отвечает на более узкий вопрос, чем тот, который вы задали.
Цена невидимой работы: два раза одно и то же
Параллельная сессия влила в основную ветку свой фикс того же дефекта, над которым у нас лежал черновик. Чужая версия оказалась строже. Черновик сняли целиком — не сшивали, не доказывали, что «у нас тоже есть полезное»: сшивка двух фиксов одного места дороже, чем выбросить свой.
Отчёты агентов сходятся по одному признаку: в них не бывает строки «этот плюс не мой». Пока такой строки нет, суммарная польза по всем отчётам команды всегда больше фактической — каждое улучшение посчитано столько раз, сколько сессий его видели.
Что сделать у себя
- Прогоните ignore-правила против сегодняшнего диска. Не читайте файл глазами — получите список того, что правило прячет прямо сейчас. Причина правила и его нынешнее действие расходятся молча.
- Сверяйте по содержимому, а не по пути. У нас разница между «нет по пути» и «нет нигде» составила 2575 против 255. Отчёт по путям приведёт к панике и к неделе лишней работы.
- Отдельно считайте ссылки. 147 файлов из 255 упоминались в том, что уже лежит в общей ветке. Такие места ломаются у нового человека, а не у автора.
- Вывод «такого нет» проверяйте по неслитым веткам. Командой на предков, а не поиском по основной ветке и не по памяти.
- Перед правкой смотрите, не занято ли место соседней сессией. Если чужая версия строже — снимайте свою целиком.
- Держите в отчёте строку «это не наш плюс». И обратную — «одна находка добавилась по нашей вине». Отчёт без минусов не читается как отчёт.