Git и GitHub для тестировщика: основные команды, коммиты и ветки

Что такое Git и GitHub и нужен ли Git тестировщику

Система контроля версий хранит историю всех изменений, которые когда-либо вносили в проект. Коммитом становится любое изменение, будь то новый файл, строка кода или удаление, и на линии развития проекта он выглядит отдельной точкой. Если на свежем коммите нашли критичную ошибку, а на предыдущем всё работало стабильно, проект откатывают к стабильной точке, и переписывать код заново не приходится. Поэтому коммиты лучше делать небольшими: при откате теряется меньше работы.

Git называют распределённой системой, потому что репозиторий со всеми ветками и историей любой участник копирует на свой компьютер и работает с ним локально, даже без интернета. Если с главным репозиторием что-то случится, рабочая версия продукта останется на машинах разработчиков. Устроено это по схеме клиент-сервер. Клиент – Git на вашем компьютере, а сервером служит GitHub или внутреннее хранилище кода компании, через которое команда обменивается изменениями.

Нужен ли Git тестировщику, зависит от компании. Где-то с ним не сталкиваются вовсе, а где-то в репозитории лежат автотесты и тестовая документация. На моём проекте там хранились тест-кейсы: их правили в локальном репозитории и отправляли в общий. Если в вакансии указано знание Git на уровне базовых команд, перед собеседованием их стоит повторить. Обычно просят рассказать, что такое Git и GitHub, а потом спрашивают основные команды и сущности вроде репозитория, коммита и ветки.

• Репозиторий

  Весь проект с файлами, ветками и историей изменений. Репозиториев бывает несколько, например отдельные для веб-версии, Android и iOS.

• Коммит

  Сохранённое изменение с автором, датой, сообщением и уникальным хешем. По хешу коммит находят в истории и смотрят, что в нём поменялось.

• Ветка

  Отдельная линия коммитов. Главная ветка (master или main) хранит эталонный код, а разработчик заводит себе ветку под задачу, чтобы не мешать остальным.

• Merge и merge request

  Merge – слияние ветки с главной. Перед ним отправляют запрос на слияние (на GitHub он называется pull request), и другой разработчик проводит ревью кода, проверяя, нет ли лишних строк и опечаток.

• Конфликт

  Изменения, которые Git не может объединить сам, например когда два человека поменяли одну и ту же строку. Такой конфликт решают вручную.

• Клонирование

  Копия удалённого репозитория на своём компьютере. С неё начинается работа с любым проектом, и делается она командой git clone.

Установка, настройка и первый коммит

Git скачивают с официального сайта git-scm.com, там есть версии для Windows, macOS и Linux. Я работаю на Windows и при установке оставляю настройки по умолчанию, в том числе Git Bash и Git GUI. Git Bash – отдельная командная строка, где работают те же команды, что и в терминале Linux, и дальше уроки идут в ней. Её открывают правой кнопкой мыши в папке репозитория. Если после установки команда git выводит список команд, всё встало правильно.

Затем Git сообщают имя и почту. Они попадут в каждый коммит, и по ним видно, кто и когда вносил изменения. В папке пользователя создают файл .gitconfig с разделом [user], где указаны email и name. То же самое делают две команды: git config --global user.name "Artem" и git config --global user.email "artem@example.com". Проверить настройки можно командой git config --list --global.

Удалённый репозиторий заводят на GitHub. После регистрации и подтверждения почты создают новый репозиторий, придумывают название, выбирают публичный или приватный доступ и при желании добавляют файл README с описанием проекта. GitHub покажет ссылку на репозиторий, она понадобится для клонирования. В новых репозиториях GitHub главная ветка называется main, а в моих уроках она называется master. Команды от этого не меняются, подставляется только имя ветки.

Первый коммит в уроке проходит такие шаги.

• 1. Клонировать репозиторий

  Перейти командой cd в папку для проекта, выполнить git clone со ссылкой из GitHub, затем cd test, чтобы оказаться внутри репозитория.

• 2. Создать файл

  Создать file1.txt и выполнить git status. Файл попадёт в раздел Untracked files: он лежит в папке, но Git его пока не отслеживает.

• 3. Добавить в индекс

  git add file1.txt говорит Git, что файл нужно отслеживать. В git status он теперь числится как new file и готов к коммиту.

• 4. Изменить ещё раз

  Если после git add дописать в файл строку, git status покажет его дважды: как new file со старой версией и как modified с новой. Повторный git add берёт в коммит свежую версию.

• 5. Сделать коммит

  git commit -m "test commit one" сохраняет изменения в локальном репозитории. Сообщение после -m коротко описывает, что изменилось, чтобы следующему человеку было понятно.

• 6. Отправить на сервер

  git push отправляет коммит в удалённый репозиторий. В первый раз откроется окно входа в GitHub, после чего файл появится на странице репозитория.

Базовые команды Git: история и синхронизация

Изменения приходят и с другой стороны: коллега отправил коммит, или файл поправили прямо на странице GitHub. Локальный репозиторий сам об этом не узнает, и git status скажет, что всё в порядке. Команда git fetch скачивает сведения о новых коммитах, и после неё git status сообщит, что ветка отстаёт от origin/master. Сами файлы обновляет git pull, который забирает изменения и вливает их в текущую ветку.

В именах веток легко запутаться. master – локальная рабочая ветка. Запись origin master через пробел означает ветку master в удалённом репозитории origin, так её пишут в командах вроде git push origin master. Запись origin/master через косую черту обозначает локальную копию того, что было на сервере при последнем git fetch.

Историю удобно смотреть и в графическом виде. Команда gitk & открывает дерево коммитов по веткам с авторами и временем. В окне, которое открывает git gui &, те же действия делают кнопками. Rescan показывает изменения, их добавляют к коммиту, пишут сообщение и нажимают Commit, а затем Push. Знак & оставляет командную строку свободной. Сам я работаю в Git Bash, а графический вид советую тем, у кого много веток и кому нужно видеть изменения глазами.

Перед регрессом релиза приложения доставки тестировщик смотрит, что в нём нового. Команда git log --oneline master..release/2.4 выводит по строке на каждый коммит релизной ветки, которого ещё нет в master, например "Расчёт стоимости доставки" и "Экран корзины", и регресс начинают с этих мест. git show с хешем коммита покажет, какие файлы в нём правили.

• git status

  Состояние файлов (untracked, new file, modified) и то, отстаёт ли ветка от удалённой. С неё удобно начинать любое действие.

• git log

  История коммитов: хеш, автор, дата и сообщение. git log --author="Artem" оставит коммиты одного автора. Выйти из просмотра можно клавишей q.

• git show

  git show с хешем коммита покажет, какие файлы и строки в нём изменились: добавленные отмечены плюсом, удалённые минусом. Без хеша выводится последний коммит. Хеш копируют правой кнопкой мыши, потому что Ctrl+C в терминале прерывает команду.

• git blame

  git blame file1.txt показывает, кто и когда менял каждую строку файла. С grep, например git blame file1.txt | grep Artem, остаются строки одного автора. Так находят, к кому обратиться при конфликте.

• git diff

  Изменения в файлах, которые ещё не добавлены через git add: какие строки дописали и какие удалили.

• echo и cat

  Команды Linux, которые работают в Git Bash. echo "new line" >> file1.txt дописывает строку в конец файла, а cat file1.txt выводит его содержимое.

• ШпаргалкаGit для тестировщика

Как отменить изменения и решить конфликт

Способ отмены зависит от того, докуда дошло изменение: осталось в файле, попало в коммит или ушло на сервер. Отправленный коммит в общей ветке через reset не отменяют, потому что переписанная история разойдётся с копиями коллег. Для этого есть git revert, он создаёт новый коммит, обратный старому.

В уроках разобраны конфликты двух видов. В первом на сервере есть коммиты, которых нет у вас, например кто-то добавил файл через GitHub. Тогда git push отвечает ошибкой, и помогает простой порядок: сначала git pull, потом снова git push. В свежих версиях Git, если способ слияния не настроен, git pull в такой ситуации останавливается с ошибкой Need to specify how to reconcile divergent branches. Тогда один раз выполняют git config --global pull.rebase false, и pull сливает изменения, как в уроке.

Во втором одну и ту же строку изменили и на сервере, и у вас. git pull сообщит о конфликте, а git status покажет файл как both modified. Git сам размечает спорное место. Между <<<<<<< HEAD и ======= стоит ваша версия, а между ======= и >>>>>>> с хешем коммита – пришедшая с сервера. Нужные строки оставляют, метки удаляют, файл сохраняют и выполняют git add, git commit и git push. Если непонятно, чья версия верна, git merge --abort отменит слияние, а решать конфликт лучше вместе с разработчиком.

• git checkout file1.txt

  Отменяет правки в файле, которые ещё не попали в коммит, а git checkout . откатывает все файлы сразу. В новых версиях Git то же самое делает git restore.

• git reset HEAD~1

  Отменяет последний коммит, но его изменения остаются в файлах. HEAD~1 означает один шаг назад от текущего коммита.

• git reset --hard HEAD~1

  Отменяет коммит вместе с изменениями в файлах. Сам коммит ещё можно найти через git reflog и вернуть, а незакоммиченные правки пропадут насовсем, поэтому перед командой стоит заглянуть в git status.

• git stash

  Прячет незакоммиченные изменения во временное хранилище. git stash pop возвращает их, git stash list показывает, что там лежит, а git stash clear очищает хранилище навсегда. Пример: тестировщик дописывает автотест корзины, и его просят срочно проверить hotfix. git stash прячет недописанный тест, а после проверки ветки исправления git stash pop возвращает его на место.

• git merge --abort

  Отменяет слияние, на котором случился конфликт, и возвращает файлы в состояние до него.

Ветки, слияние и Git Flow

Ветку заводят, чтобы поработать над задачей и не мешать основной. Новая ветка начинается с последнего коммита текущей, а когда работа закончена, её сливают обратно, и коммиты ветки появляются в главной.

В командах ветки обычно раскладывают по схеме Git Flow, хотя детали в каждой компании свои. В master лежит рабочая версия продукта, та, что сейчас в продакшене. Разработка идёт в develop, а под каждую задачу разработчик заводит feature-ветку и потом вливает её обратно в develop. Когда в develop всё работает стабильно, от неё создают релизную ветку. Тестировщики обычно проверяют именно её: новых функций там не пишут, только исправляют найденные баги. Если критичных дефектов не осталось, релизную ветку сливают в master и develop, и слияние в master становится релизом. Для срочного исправления бага с продакшена есть hotfix-ветка.

Иногда разработчик просит проверить задачу до слияния в develop, например промокоды в интернет-магазине. Тестировщик выполняет git fetch и git checkout feature/promo-codes, и Git создаёт локальную ветку, связанную с удалённой. Приложение запускают из этой ветки и проверяют скидку, истёкший промокод и повторное применение, а найденные баги правят в той же ветке, и в develop они не попадают.

Ниже команды для работы с ветками по шагам.

• Создать и перейти

  git branch first-branch создаёт ветку, а git branch без имени выводит список, где текущая отмечена звёздочкой. git checkout first-branch переключает на неё, git checkout -b first-branch создаёт и переключает одной командой.

• Первый push ветки

  Обычный git push ответит ошибкой о том, что у ветки нет upstream, то есть пары на сервере. git push -u origin first-branch создаёт ветку в удалённом репозитории и связывает её с локальной.

• Слить в главную

  git checkout - возвращает в предыдущую ветку, здесь это master. git merge first-branch вливает изменения, а git push отправляет их на сервер. Если master за это время не менялась, слияние идёт как fast-forward, и история остаётся линейной.

• Конфликт при слиянии

  Если master успела измениться на сервере, git push после слияния откажет. Помогает git pull, а если в обеих версиях менялась одна строка, файл правят вручную, как при любом конфликте.

• Переименовать

  git branch -m old-name new-name. Если ветка уже на сервере, старое имя удаляют командой git push origin :old-name и отправляют новое через git push -u origin new-name.

• Удалить и вернуть

  git branch -d second-branch удаляет слитую локальную ветку, git branch -D удаляет любую. На сервере ветка остаётся, и её возвращают командами git fetch origin second-branch и git checkout second-branch.

• ШпаргалкаGit Flow и другие модели ветвления

Видеоуроки, шпаргалки и задания

Я разбираю Git в мини-курсе из шести уроков на YouTube, от теории и установки до веток, Git GUI, gitk и Git Flow. В 2022 году уроки вышли одним роликом, полным курсом по GitHub для тестировщика. В бесплатном базовом курсе по тестированию тема открывается уроком "Что такое git и github?", и после теории в нём есть задания. Дальше в модуле идут уроки об установке, базовых командах, git commit, reset, checkout и stash, работе с ветками и Git Flow, а завершает его урок "Создание портфолио".

Шпаргалка по Git – справочник с поиском по командам: как посмотреть, что изменил разработчик, забрать нужную ветку, разрешить конфликт и откатить свою ошибку. Шпаргалка по моделям ветвления показывает Git Flow кликабельной схемой и сравнивает его с более лёгкими моделями. В тренажёре по Git отрабатывают команды, ветки и действия после ошибки.

• Урок курсаЭтот урок с заданиями – бесплатно
• Мой видеоурокосновы Git для тестировщика
• Мой видеоурокустановка Git, регистрация в GitHub, первый репозиторий
• Мой видеоурокбазовые команды и отслеживание изменений
• Мой видеоурокgit commit, git reset, git checkout, git stash
• Мой видеоурокработа с ветками в Git
• Мой видеоурокgit gui, gitk и Git Flow
• Мой видеоурокGit и GitHub для тестировщика, полный курс
• ШпаргалкаGit для тестировщика
• ШпаргалкаGit Flow и другие модели ветвления
• Тренажёркоманды и ветки Git
• СтатьяBash для тестировщика: команды терминала
• СтатьяCI/CD для тестировщика

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441

Вопросы и ответы