TL;DR: тестировщику GitHub/etc. необходим для локального тестирования, обновления документации в репозитории, написания автотестов.

Начало: гит или гитхаб? Гит это распределеная система контроля версий приложения или репозитория с тестами. Создал Линус Торвальдс в 2005 как open source альтернативу существовавшей тогда BitKeeper. Работает без интернета.

GitHub это удаленный репозиторий, сервис, использующий git с расширенным функционалом. Когда просят ссылку с тест кейсами на гите часто имеют в виду ссылку с публичного репозитория GitHub. Аналогичные сервисы - Bitbucket и GitLab.

Зачем нужен:

кейс 1: представьте в команде 3 разработчика. Каждый пишет код и вносит правки. Исправления будут в одних и тех же файлах. Возникает вопрос: и кто же прав и чья версия главнее? Для этого вводят понятие главная ветка и от нее уже делают ответвления.

Выглядит это так:

                      (feature - новая ветка с фичей)

                                       D ---- E

                                     /        

(main - главная ветка) A —- B

Ответвление начинается с коммита «A», это «состояние» системы в определенный момент времени. На выбранный коммит можно вернуться или перенести сам коммит на другую ветку, если его не удалить конечно. «A» коммит является стартом для новой ветки. Технически коммит «D» наследуется от «A» и включает уже новые изменения, не учтенные на основной ветке. Так как и коммит «E». Соответственно коммит «B» не появится на выделенной ветке без мержа (объединения изменений) из основной ветки.

Когда фича будет готова, создается мерж реквест (запрос на слияние). После подтверждения и объединения веток - мерж коммит (коммит слияния). Из дополнительной ветки изменения перетекают в главную. Дополнительная ветка «отмирает» и разработка ведется дальше с коммита «C».

            (feature)

          D —- E —--+

          /                  \

(main) A —– B ——-C —– F

кейс 2: когда поймали баг который ранее не заметили - гит позволяет «откатиться» на нужные изменения для расследования причины происшествия.

кейс 3: задача к нам поступает на тест. Как определить задетые участки кода? Как понять что по коду было сделано, это если мы можем и умеем покопошиться в кишочках MR? Идеально покажет разницу веток в запросе на слияние интерфейс удаленного репозитория. Точно ли наш разработчик выполнил все тех задание?

кейс 4: портфолио! Да-да, некоторые рекрутеры смотрят ваш гит или по крайне мере просят ссылку на него. Может хотят предложить свой запрос на слияние?(:

кейс 5: мы автотестер. Пишем новые тесты, ревьюим код, локально испытаем новые инструменты. Для всего этого идеально подходит гит.

Как использовать тестеру? Если тестирование выполняется локально, то тестировщику необходимо обновлять локальную ветку - стягивать изменения из удаленного репозитория и мержить со своей локальной веткой.

При наличии установленного локально гита и подключенного проекта это делается так:

git pull При этом можно отдельно запросить и скачать обновления:

git fetch И по необходимости их смержить (объединить);

git merge Собственно:

git pull = git fetch + git merge Частый вопрос на собеседованиях - чем отличается гит пулл от гит фетч 😅

Переключение на ветку для теста или написания кода происходит подобной командой:

git checkout feature/super-puper-mega-feature На ней аналогично стягиваются изменения при обновлении разработчиком. Не забываем, что гит это про распределение работы и контроль версий.

Или, если такой ветки еще нет, то создать ее локально:

git checkout -b feature/super-puper-mega-feature Если мы вносим изменения в тесты, то сперва добавляем все измения в файлы для наблюдения и подготовки гитом:

git add . И затем запечатываем их, сохраняем «слепок» на конкретный момент времени всей системы:

git commit -m “feat: add new awesome tests!” Затем это пушим в удаленный репозиторий - делимся наработками:

git push Теперь нашу ветку с изменениями могут стянуть к себе и другие люди. А как вы используете git?