Мы продолжаем изучать систему контроля версий 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.