Пока нет оценок.
Пожалуйста, подождите...

Цель данного материала — дать начинающему тестировщику обзорное представление касательного того, как функционирует система контроля версий продукта: от процесса клонирования репозитория до возможности создания pull-запроса.Даже если пользователь имеет существенные познания по работе с Git, все равно, данное ПО может казаться немного загадочным и интересным, в нем может происходить множество всего, что не видно на первый взгляд.

Далее поговорим о шести хитростях, которые упрощают работу с 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

Советы по работе с Git

Совет №5: помещайте каждый git-лог в одну строку

Очень легко забыть, что конкретно вы делали в Git, посколько в нем нет интерфейса, который это может продемонстрировать.

И тут на помощь приходит так называемый git лог. Лог может в своей полноте продемонстрировать пользователю сразу несколько последних коммитов, их создателей, дату и время модификации.

Очень удобно знакомится с логами, если они сжаты в одну строку. Для этого необходимо набрать команду git log—pretty=online. Для того, чтобы выйти из лога просто введите q.

Совет №6: смотрим на разницу между пользовательскими файлами перед выполнением pull-запроса

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

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

Это значит, что нужно просто просмотреть  diff необходимых файлов перед отправкой pull-запроса и написанием просьбы просмотреть программный код.

Для этого просто перейдите в GitHub и сравните файлы в вашей ветке и в мастере, для того, чтобы увидеть, какие именно строки кода могли измениться.

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

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

Оставить комментарий

WP Facebook Auto Publish Powered By : XYZScripts.com