Цель данного материала — дать начинающему тестировщику обзорное представление касательного того, как функционирует система контроля версий продукта: от процесса клонирования репозитория до возможности создания pull-запроса.Даже если пользователь имеет существенные познания по работе с Git, все равно, данное ПО может казаться немного загадочным и интересным, в нем может происходить множество всего, что не видно на первый взгляд.
Далее поговорим о шести хитростях, которые упрощают работу с Git.
Логотип Git
Совет №1: постоянно запускайте git status
Клиенты Git часто допускают следующую ошибку: выполнить задание и зафиксировать его, оставаясь в неправильной ветке. Не нужно быть экспертом, чтобы точно понимать, как нужно исправлять подобные ошибки.
Например, можно чаще запускать специальную команду git status. Ее можно сразу запускать после открытия командной строки и перехода внутрь репозитория, для того, чтобы ветка, в который вы находитесь, не была для вас неожиданностью в будущем.
Старт git status — также неплохой вариант выяснения, какие именно файлы в определенной ветке подверглись модификациям.
Порой, пользователи могут менять файлы с желанием отладки и забывают отменить данные изменения.
Старт git status позволит узнать вам, что конкретный файл, который не планировался модифицироваться, был отредактирован.Совет №2: выкачивайтемастер-ветку, перед тем как начать работу в ней
Перед тем как приступать к модификации кода в своей ветке, стоит убедиться в том, что ее содержание — это самый свежий и актуальный программный код. Иначе клиент может менять код, которого уже нет в природе или банально, дублировать работу другого человека.
Убедившись в том, что в вашем распоряжении последний программный код, вы также сможете уберечь себя от конфликта слияния веток, при котором между клиентской веткой и master веткой могут возникнуть неразрешимые отличия, с которыми ПО контроля версий не понимает, как справиться.
По завершению выкачивания master-ветки, нужно не забыть переключиться на свою собственную.
Если пользователь очень часто прогоняет команду git status, то он сразу заметит, если забыл переключиться на нужную ветку.Совет №3: добавляйте каждый измененный файл одновременно
Если пользователь модифицировал сразу несколько файлов, ему будет очень сложно постоянно набирать на клавиатуре git add <добавить длинное название файла>.
Легкий способ добавить все пользовательские изменения в файлах одновременно — использовать специальную команду git add — A.
Перед использованием необходимо убедиться в том, что вы реально желаете добавить все эти файлы.Совет №4: каждый commit должен содержать полезное наименование
Во время фиксации изменений в файле необязательно добавлять сообщение об этом изменении, но множество компаний будет ожидать, что вы его самостоятельно добавите.
Старайтесь облегчить жизнь себе и окружающим, обозначая commit так, чтобы в будущем в нем можно было разобраться.
«Редактирование одной строки программного кода» — не очень эффективное сообщение.
«Добавка теста для конечной точки новой контактной информации» даст намного больше информации при последующем изучении документа.
Советы по работе с Git
Совет №5: помещайте каждый git-лог в одну строку
Очень легко забыть, что конкретно вы делали в Git, посколько в нем нет интерфейса, который это может продемонстрировать.
И тут на помощь приходит так называемый git лог. Лог может в своей полноте продемонстрировать пользователю сразу несколько последних коммитов, их создателей, дату и время модификации.
Очень удобно знакомится с логами, если они сжаты в одну строку. Для этого необходимо набрать команду git log—pretty=online. Для того, чтобы выйти из лога просто введите q.
Совет №6: смотрим на разницу между пользовательскими файлами перед выполнением pull-запроса
Если клиент очень часто прогоняет команду git status, то, может быть, он не зафиксирует изменения в файлах и не отправит в удаленный репозиторий те файлы, которые не нуждаются в этом.
Но случайно зафиксировать изменения в программном коде, который под эти цели не планировался, внутри файла, который содержит необходимые изменения, все-таки получится.
Это значит, что нужно просто просмотреть diff необходимых файлов перед отправкой pull-запроса и написанием просьбы просмотреть программный код.Для этого просто перейдите в GitHub и сравните файлы в вашей ветке и в мастере, для того, чтобы увидеть, какие именно строки кода могли измениться.
Если клиент отправил что-то неактуальное, он запросто может сменить файл на актуальный, а потом просто добавить его, зафиксировать изменения в нем, и отправить повторно в репозиторийю
Очень надеемся, что данные советы и рекомендации будут весьма полезны для многих тестировщиков и тем более программистов, которые ежедневно взаимодействуют с Git.
Оставить комментарий