Слияние с мастером взлома кода без конфликтов

Question

Мы работаем с большим количеством веток, и перед каждым слиянием с мастером> 1 ч автоматических тестов (например, travis) необходимо передавать запросы на извлечение. Это означает, что не каждая ветка может быть обновлена ​​до последней версии перед слиянием. Теперь рассмотрим код, включающий функцию f в библиотеке L.

1. Запрос на извлечение A удаляет f из L
2. Запрос на извлечение B использует f из L в другом файле
3. A объединен с мастером
4. B не имеет git конфликтов, но основан на мастере до объединения A, поэтому тесты проходят и B объединен

Теперь у нас явно есть сломанный мастер, потому что мы используем функцию, которая не существует. В связи с этим у меня есть два вопроса:

1. Есть ли название для этого сценария, я попытался найти его без удачи, и молчаливый конфликт, кажется, означает что-то еще.

2. Как решить эту проблему в целом, не нарушая существующий рабочий процесс (может быть, внедрить что-то новое, но не отнять)?

Answer 1

Если вы хотите узнать, соответствует ли определенное дерево файловой системы некоторым критериям (включая его компиляцию), вы должны выполнить какой-то тест, который он делает.

В этом случае Git Дерево, которое вы хотите протестировать, - это дерево, созданное путем слияния определенной ветки объектов и последней версии мастера. Хотя га sh коммита будет меняться в зависимости от меток времени, дерево Git останется неизменным, если вы выполните идентичные слияния. Вы можете использовать эту оптимизацию при выполнении тестов, пропуская тесты, которые, как вы знаете, уже пройдены для данного дерева.

Вы можете настроить систему CI для выполнения какого-либо теста быстрой компиляции, если ваш код скомпилирован, и зарезервировать углубленное тестирование только для начального pu sh. Тем не менее, нет никакого способа избежать выполнения какого-либо теста для вашего кода, если вы хотите знать, будет ли определенное состояние (в данном случае данное дерево) соответствовать вашим требованиям (работает ли оно). Разбор различий вряд ли будет здесь плодотворным, поскольку он не обнаружит много видов ошибок.

Как уже упоминали другие, можно улучшить скорость тестов. Многие крупные организации со сложными кодовыми базами распараллеливают свои тесты, чтобы их можно было запустить за разумное время. Если существует избыточное состояние (например, настройка ОС), которое стоит дорого, вы можете создать базовый образ (например, с помощью Vagrant или Docker), а затем построить свои тесты поверх этого, сэкономив время.

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