В процессе разработки ПО значимая роль отводится сотрудничеству. В большинстве случаев деятельность разработчика включает работу в команде и совместное использование проекта с другими специалистами. Практический опыт использования системы контроля версий не просто важен, а ВАЖЕН для всех, кто намерен заниматься разработкой ПО. В то же время будет сложно привить навык использования контроля версий тем начинающим программистам, которые во время рабочего процесса позволяют коду изливаться из них бурным потоком, вместо того чтобы придержать обороты и размещать его по частям.
Время и целеустремленность все расставляют на свои места, и соблюдение всех правил использования контроля версий постепенно входит в привычку. Предлагаю разбить процесс написания кода на последовательные этапы.
Git послужит в качестве системы контроля версий, а Github — веб-сервиса для хостинга репозиториев Git. Осуществление этого проекта предполагает предварительное создание копии или нового репозитория. Если же вы этого еще не сделали, но хотите научиться, то добро пожаловать на этот ресурс.
Приступим!
Этап 1. Проверка ветки
Итак, у вас есть собственный репозиторий на локальном компьютере. Прекрасно! И вам уже не терпится написать код, но прошу вас немного подождать и кое-что сделать. Проверьте ветку, на которой вы находитесь. Для этого введите следующую команду в терминал:
git branch
Если увидели этот результат, то притормозите!
Можно написать новый код непосредственно в ветку master при условии, что вы не работаете с директорией приложения, содержащей несколько папок и файлов. Но если вы планируете работу над большим проектом, то лучше этого не делать.
Написание кода прямо в ветку master может повлечь за собой его отправку в онлайн-репозиторий без каких-либо мер предосторожности, а мы же, наоборот, хотим убедиться, что отправленный код работает должным образом.
Итак, что же следует делать, если вы находитесь на ветке master?
Этап 2. Переключение на новую ветку
Во избежание сложностей, связанных с написанием кода прямо в ветку master, следует создать новую ветку на своем локальном компьютере. Для этого введите следующее в терминал:
git checkout -b <your-new-branch-name>
Имя ветки <your-new-branch-name> должно отражать проблему, ради решения которой она и создается. Если вы намерены создать базу данных, то в качестве имени ветки следует указать create-database.
Этап 3. Написание кода
Приступаем к основной части статьи: непосредственно процесс создания кода!
Будет целесообразно сосредоточиться только на решении задачи, указанной в имени текущей ветки. Основываясь на нашем примере, код в create-database должен способствовать созданию базы данных. Как только вы его написали и он заработал согласно вашему замыслу, самое время им поделиться!
Этап 4. Просмотр статуса
Используя команду git status, мы сможем увидеть все файлы, которые были добавлены, изменены или удалены во время нашего искрометного сеанса программирования.
Если все в полном порядке, то для индексации этих изменений просто введите в терминал следующую команду:
git add .
Зеленый цвет файлов означает, что изменения были проиндексированы:
Этап 5. Создание коммита
Проиндексировав изменения, мы переходим к их фиксации в коде. Git commit сохраняет эти изменения и готовит их для отправки в онлайн-репозиторий. Но не будем спешить — с этой командой мы еще не закончили.
Git предлагает написать комментарий к коммиту. А так как гордое звание программиста (и человека) обязывает развивать в себе коммуникационные навыки, то мы с вами сейчас это сделаем:
git commit -m “useful info about the code I wrote”.
Флаг -m указывает команде git commit, что вы добавляете полезный комментарий о коде. Итак, его уже можно отправлять, но прежде немного задержимся еще на одном этапе.
Этап 6. Проверка ветки
Догадываюсь, что вас не обрадует предложение по нескольку раз вводить в терминал команду git branch. Но так надо. Проверим дважды — от нас не убудет. Затовы избавите себя от необходимости запоминать имена веток, поскольку за вас это сделает инструмент!
Этап 7. Отправка
Итак, код написан, коммиты изменений созданы — пора отправлять их в онлайн-репозиторий, чтобы ваши коллеги-разработчики получили к ним доступ и добавили их на свои локальные компьютеры. Вводим следующую команду:
git push origin <your-branch-name>
Вы увидите нечто подобное:
Если вы используете VScode, то эта команда + клик на http-адрес перенесут вас на этап 8. И вот ваша ветка запущена в эфир!
Этап 8. Запросы на слияние
На этом этапе мы готовы, можно сказать сгораем от нетерпения, написать дополнительный код. Но прежде посмотрим, что же мы отправили. Перейдите на онлайн-репозиторий Github и сделайте запрос на слияние ветки:
Таким образом вы даете понять, что содержимое ветки безопасно для слияния с веткой master.
Если все идет по плану, то произойдет успешное слияние веток и другие разработчики получат доступ к написанному вами коду.
Этап 9. Лицом к лицу с master
На данный момент ветка master в онлайн-репозитории содержит больше кода, чем в локальном. Надо бы это исправить. Вернитесь на ветку master и введите в терминал следующую команду:
git pull origin master
Если все сработало, то вы увидите эти зеленые строки плюсов:
Этап 10. Итоги
На этом этапе вы должны определиться с функциональностями, которые хотели бы разрабатывать в дальнейшем. Начинайте процесс с этапа 2, и пусть осознание того, что вы четко выполняете все правила работы с Git, бережет ваш покой!
Читайте также:
- Создание и отслеживание первого рабочего потока Github Actions
- Автоматизированное семантическое управление версиями с помощью GitVersion
- Используй git-команды, как senior developer
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Alex Mata: Introduction to Git Workflow
