Git на хакатоне: как объединять код и не потерять демо
Простой порядок работы с Git для команды хакатона: общая версия, небольшие изменения, проверка перед объединением и сохранение демо.
·4 мин чтения
На хакатоне Git помогает хранить общую историю проекта и соединять работу участников. Для небольшой команды достаточно простого порядка: основная ветка запускается, изменения делаются небольшими порциями, а перед объединением кто-то проверяет результат. Сложную модель ветвления лучше не вводить в середине соревнования.
Git хранит версии файлов. GitHub и другие сервисы добавляют совместную работу, обсуждения и управление доступом. Команда может выбрать любой разрешённый инструмент, но всем нужно знать, где находится общий репозиторий и какая версия считается готовой для демонстрации.
Проверьте доступы до первой задачи
Создайте репозиторий в аккаунте или организации, которые команда согласовала использовать. Добавьте участников с нужными правами и убедитесь, что приглашения приняты. Одно отправленное приглашение ещё не означает, что другой человек может получить и отправить изменения.
Выберите видимость по условиям события и характеру материалов. Закрытый репозиторий может потребовать отдельного доступа жюри. Открытый репозиторий не должен содержать персональные данные, закрытые наборы или секретные ключи. Если организатор требует публикацию, подготовьте проект к ней до финального часа.
Добавьте короткую инструкцию запуска и файл исключений для локальных настроек, временных файлов и установленных зависимостей. Образец конфигурации должен описывать необходимые параметры без настоящих секретов. Не полагайтесь на то, что случайно попавший в историю ключ исчезнет после удаления строки в новом изменении.
Договоритесь о рабочей основной ветке
Пусть основная ветка содержит версию, которую можно запустить по инструкции. Незавершённые эксперименты сохраняйте отдельно. Команда должна понимать, что получение последней основной версии не превращает рабочее приложение в неизвестное состояние.
Перед началом задачи получите актуальные изменения. Назовите ветку по работе, например fix-upload-error или add-results-screen. Название не обязано быть длинным; оно должно помогать связать изменение с задачей и человеком, который его делает.
Не храните один огромный набор изменений до конца события. Если задача занимает несколько часов, выделяйте законченные шаги, которые можно проверить отдельно. Так проще заметить несовместимость раньше, чем несколько участников перестроят общие файлы.
Перед объединением объясните поведение
Документация GitHub о pull requests описывает предложение, обсуждение и объединение изменений. На хакатоне описание может быть коротким: что изменилось, как проверить и какое ограничение осталось. Для экрана полезен снимок, для обработки данных пример входа и выхода.
Проверяющий проходит изменённый сценарий и смотрит, не затронуты ли общие границы. Автор лучше знает свою задачу, но другой участник может заметить недоступную переменную окружения или ошибку, которую локальные данные скрывали.
Не требуйте длинной формальной проверки для каждой подписи. Сосредоточьтесь на изменениях, которые влияют на запуск, формат данных, доступы и демонстрацию. При этом даже маленький исправленный файл должен попасть в общую версию, а не остаться только в сообщении чата.
Разделяйте работу по файлам и интерфейсам
Если двое одновременно меняют один большой компонент, конфликты вероятнее. Договоритесь о границах: один участник работает с загрузкой, другой с экраном результата. Общую схему данных согласуйте до начала параллельной работы.
Изменение общей зависимости или структуры проекта сообщайте заранее. Обновление инструмента может затронуть запуск у всех участников. Во время короткого события у такой работы должен быть конкретный повод, а не желание привести весь репозиторий к личным предпочтениям.
Когда конфликт всё же возник, не выбирайте автоматически «нашу» или «их» версию. Прочитайте обе правки и выясните, какое поведение каждая добавляла. Если смысл неясен, позовите автора. Случайно удалить чужую обработку ошибки легче, чем заметить потерю при быстром просмотре.
Проверяйте проект после соединения частей
Отдельно успешные изменения могут не работать вместе. После объединения запустите проект и выполните главный пользовательский путь. Если есть подходящие автоматические проверки, запускайте их. Не добавляйте сложную систему тестирования только ради отчёта, если команда не успеет ею воспользоваться.
Полезен короткий список ручной проверки: приложение открывается, ввод принимается, результат отображается, ошибка понятна. Список должен соответствовать вашему прототипу. Для устройства или обработки файлов понадобятся другие действия.
Назначьте человека, который следит за общей сборкой. Это не означает, что только он имеет право объединять код. Его задача замечать, когда команда перестала понимать текущее состояние, и остановить новые изменения до восстановления рабочего сценария.
Сохраните версию для защиты
Перед записью демо обозначьте готовое состояние тегом или другим понятным способом фиксации версии. Запишите, какой набор данных использовался и какие ограничения известны. Если после записи вы исправили поведение, проверьте, соответствует ли видео обновлённому проекту.
Не переписывайте общую историю без согласования с командой. Принудительная отправка изменений может нарушить работу у остальных. Если случайно добавлены секреты, ограничьтесь не только очисткой файлов: отзовите скомпрометированный доступ по правилам соответствующего сервиса и сообщите ответственному участнику.
Учебный пример сбоя: один разработчик добавил новый параметр, но не обновил инструкцию. На его компьютере всё работает, у докладчика запуск падает. Проверка на втором устройстве обнаруживает это до финала. Именно поэтому завершение задачи включает воспроизводимый запуск, а сдача проекта включает проверку доступа к нужной версии.
Перед отправкой репозитория найдите требования выбранного события через каталог Stavleak. Сверьте состав материалов и срок, до которого жюри нужен доступ.
