Мы продолжаем изучать систему контроля версий git. Сегодня разбираемся, как организовать совместную работу над проектом с вашими коллегами.
Git pull
Подключить новых участников к вашему репозиторию можно в меню Settings → Collaborators → Add People.
Мы можем добавлять других участников по их email или никнеймам. Когда они примут наше приглашение, они смогут вносить изменения в проект.
Сымитируем компьютер другого человека, создав вторую папку на нашем компьютере. Назовем ее «Второй участник». Открываем терминал по адресу папки, копируем ссылку на репозиторий на git hub.
Клонируем репозиторий по ссылке: git clone <ссылка на репозиторий>.
Проверим, как называется появившаяся папка с репозиторием: ls.
Заходим в нее: cd git_tutorial.
Включаем отображение веток в терминале: source ~/.zchrc. Подробнее про отображение веток мы рассказывали в прошлом уроке.
Представим, что второй участник решил внести изменения. Он открыл файл в редакторе и добавил в начало кода импорт библиотеки datetime: from datetime import datetime. А последней строкой настроил вывод даты: print("Today: ", datetime.today().strftime('%d/%m/%Y'))
Он коммитит изменения в терминале: git commit -a -m "Add datetime".
Заливает их на Github: git push.
Представим, что мы не знаем, что такие изменения были внесены, и продолжаем работать над проектом локально. Открываем проект в редакторе, добавляем одну строку: print("Our project: Git_Tutorial").
Открываем терминал по адресу нашей основной папки Git_Tutorial, в которой начинали работать над проектом. Коммитим изменения: git commit -a -m "Project name".
Пытаемся передать изменения на удаленный репозиторий: git push. Не получается. Git пишет, что версия проекта на нашем компьютере не совпадает с версией на удаленном репозитории. Так получилось, потому что другой участник проекта уже внес какие-то изменения.
Чтобы синхронизировать локальную версию с удаленной, git предлагает команду git pull. Применяем ее: git pull.
Видим сообщение о конфликте в файле test.py.
Чтобы разрешить конфликт, переходим в редактор. Зеленым подсвечены наши изменения, синим — изменения, которые добавил в проект кто-то другой.
VSCode предлагает несколько вариантов, в каком виде сохранить код. В нашей ситуации нам подходит принять все изменения. Выбираем accept both changes. Сохраняем изменения в редакторе.
Коммитим изменения в терминале: git commit -a -m "Add project name". Отправляем на GitHub: git push.
Issues
Когда мы работаем в команде, удобно, когда каждый участник понимает, что происходит с кодом и кто какие изменения собирается вносить. Обсуждать развитие проекта, указывать на ошибки в коде, предлагать улучшения удобно во вкладке issues.
Создадим вкладку issue, чтобы обсуждать изменения в проекте с другими участниками. Нажимаем на зеленую кнопку, пишем название: delete input. Добавляем описание: предлагаю убрать input и переписать первую строку вывода, чтобы не вводить имя каждый раз. Здесь используется тот же язык markdown, как и в файле с описанием проекта README.
В описании можем ссылаться на конкретных людей и на конкретные коммиты, для этого нужно использовать их хэш-код. Можно сослаться и на куски кода. Зайдем в наш файл test.py и выберем строку с запросом информации с клавиатуры, который нам кажется неудобным. Нажмем на три точки рядом с выделенными строками, копируем permalink. Вставим ссылку в issue.
Посмотрим в режиме предпросмотре, как выглядит наш Issue. Если все устраивает, можем нажать submit.
Assignees — на кого назначаем вопрос. Можем выбрать любого участника проекта. В нашем проекте пока только мы, поэтому задача назначится на нас. Если вы назначили задачу на кого-то другого, он увидит уведомление об этом на своей странице Git Hub.
Label — тема нашего issue. Выберем bug. Labels можно настроить под себя.
Project и milestones — проекты и вехи. В рамках одного большого репозитория может быть несколько проектов и вех. Разные issue можно привязывать к этим вехам и проектам. Сейчас мы этот шаг пропускаем.
Создаем issue.
Pull Requests
В командной работе удобно объединять изменения не на локальном репозитории каждого участника, а на удаленном. Для этого существует функция Pull Request, то есть запрос на изменения. Работа выстраивается так: хотим добавить изменения — создаем в проекте на нашем компьютере ветку, в ветке вносим изменения, коммитим их, отправляем запрос на принятие этих изменений на сервер.
Предложенные изменения можно обсудить с другими участниками проекта в комментариях. Если с изменениями все согласны, запрос принимается.
Представим, что и мы решили исправить код, как написано в Issue. Откроем терминал. Создадим ветку для изменений del_input и перейдем в нее: git checkout -b del_input.
Перейдем в редактор и удалим input, изменим приветствие. Сохраним изменения.
Вернемся в терминал и закоммитим изменения: git commit -a -m "Delete input". Отправим изменения на сервер. Так как мы отправляем изменения не с основной ветки, обязательно прописать название удаленного репозиторий (origin) и название ветки, с которой отправляем изменения: git push -u origin del_input. Ветка с изменениями появилась на GitHub.
Внесем еще одно изменение. Вернемся в основную ветку: git checkout main. Создадим новую ветку update_test: git checkout -b update_test.
Перейдем в редактор и внесем новые изменения, сохраним их.
Вернемся в терминал и закоммитим изменения: git commit -a -m "Update test".
Отправим изменения на сервер: git push -u origin update_test.
Как только в удаленном репозитории появляется больше одной ветки, Git Hub предлагает объединить изменения из разных веток с помощью функции Pull Request.
Нажимаем compare and pull request. Base — куда мы переносим изменения, compare — откуда. Сначала заберем изменения из ветки del_input в main. Git Hub сам проверяет можно ли сделать слияние без конфликтов и помечает их галочкой. Если видим галочку, значит можно слить ветки без конфликтов.
Можем добавить какое-то описание к слиянию веток, reviewers — участники команды, которым мы даем доступ к этому pull request. Они могут просматривать его и комментировать. В Assignees можем указать, кому именно адресуем запрос на изменения.
Сейчас мы это пропустим и нажмем create pull request.
Нажав на сообщение о коммите, мы можем посмотреть, какие именно изменения предлагаются. Если у нас есть права на подтверждение pull request, мы можем слить две ветки сразу. Сольем две ветки: нажимаем merge pull request.
Теперь код попал в основную ветку. Ветку, которую мы создавали для изменений можно удалить.
Мы можем не сливать ветки сразу, а дождаться обсуждения с другими участниками проекта. Тогда Pull request будет висеть в соответствующей вкладке.
Попробуем теперь добавить ветку update_test. Нажимаем compare and pull request.
Ветки автоматически не сливаются, возник конфликт. Все равно создаем запрос на изменения. Решить конфликт можно на странице GitHub. Нажимаем resolve conflict.
Приводим код к нужному виду. Нажимаем mark as resolved → commit merge. Теперь ветки можно слить. Все изменения добавятся в основную ветку.
Если возникают ошибки, попробуйте найти решение в интернете. Часто достаточно вбить код ошибки в поисковик и уже в одной из первых ссылок будет решение. Если все же не получается найти ответ, пишите нам в чате в Telegram.