Що сталося

Git зберігає коміти, дерева та вміст файлів як об'єкти. Зазвичай вони лежать у стиснених файлах пакунків; після отримання змін, надсилання гілок і службових операцій у живому сховищі таких файлів накопичується чимало.

Спільний індекс кількох пакунків допомагає швидко знайти потрібний об'єкт, але його оновлення могло вимагати переписування великого файла метаданих. У версії 2.55 команда git repack --write-midx=incremental створює ланцюг додаткових індексів і торкається насамперед нових даних.

Такий ланцюг не зростає безмежно. Разом із геометричним перепакуванням система час від часу об'єднує сусідні невеликі шари, залишаючи старі великі шари недоторканими.

Експериментальне сімейство команд git history отримало git history fixup <commit>. Воно бере зміни, уже підготовлені в індексі, додає їх до обраного раннього коміту та повторно застосовує всі наступні коміти.

Це пряміше висловлює намір, ніж створення тимчасового коміту для виправлення і запуск git rebase --autosquash. Команда поводиться обережно: за конфлікту вона зупиняється, а в сховищі без робочої копії не працює, бо потребує індексу та робочої копії.

Чому це важливо

Для великих сховищ службові операції відчутні не лише за тривалістю. Переписування великих метаданих створює помітне навантаження на диск, а поступові багатопакункові індекси дають змогу обслуговувати нові пакунки без повного оновлення опису всього сховища.

Версія 2.55 також прискорює створення бітових карт досяжності об'єктів. Вони потрібні для швидких запитів під час обходу історії; у вимірах із серії змін час побудови в одному великому сховищі зменшився приблизно з 612 до 294 секунд.

Поліпшення стосуються не тільки масштабу. Коли невелике виправлення за змістом має належати ранньому коміту в серії для перевірки, окрема команда робить потрібну дію зрозумілою та прибирає проміжний службовий коміт.

Система також дозволила водночас виконувати сумісні перевірки, задані у конфігурації. Наприклад, перевірка стилю та модульні тести можуть іти паралельно, тоді як перевірки, що використовують спільну робочу копію або індекс, залишаються послідовними.

На практиці

Почніть з оновлення локальної системи контролю версій і перегляду приміток до релізу: частина можливостей розрахована на великі сховища або часте обслуговування. Немає потреби одразу змінювати всі наявні сценарії.

Команди, які регулярно впорядковують серії комітів перед перевіркою, можуть спробувати git history fixup у копії гілки. Можливість усе ще експериментальна, тому варто перевірити її поведінку на звичних конфліктах.

1. Для великого сховища виміряйте пробний запуск git repack --write-midx=incremental; геометричний режим підключайте після таких вимірів.
2. Розділіть налаштовані перевірки на незалежні завдання та вмикайте паралельне виконання лише там, де вони не змінюють ті самі файли.
3. У Linux оцініть вбудоване спостереження за файловою системою для швидшого git status; дуже великим деревам може знадобитися вищий ліміт fs.inotify.max_user_watches.
4. Для часткових копій дослідіть git pack-objects --path-walk разом із фільтрами: у вимірі вихідного проєкту пакунок без вмісту файлів був приблизно на 16% меншим, хоча обчислення дельт тривало довше.

Є й менші, але корисні доповнення. Реліз маскує більшість керувальних символів у повідомленнях віддаленої сторони, уміє надсилати гілку до групи віддалених сховищ і обмежувати ширину графа історії через --graph-lane-limit=<n>.

Підсумок

Версія 2.55 не змінює основну модель системи контролю версій, проте прибирає кілька давніх незручностей. Великі сховища отримують ощадливіше обслуговування, а розробники — пряміший спосіб виправити серію комітів.

Для більшості команд достатньо оновитися та перевірити одну можливість локально. Додаткові багатопакункові індекси особливо корисні для важких сховищ, а паралельні перевірки — там, де очікування перед комітом уже помітне.