Что такое Git Fork?
Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт (разветвление в Git с помощью Git Fork), чтобы внести изменения или использовать хранилище для наших собственных целей.
Что такое Git Fork?
Fork — это копия репозитория. Раздвоение репозитория позволяет свободно экспериментировать с изменениями, не затрагивая исходный проект.
Разветвление в GitHub — это процесс создания копии полного репозитория для учетной записи пользователя на GitHub из другой учетной записи. Когда пользователь разветвляет репозиторий, все файлы в нем автоматически копируются в учетную запись пользователя на GitHub, и это выглядит как собственный репозиторий пользователя. Этот процесс похож на копирование папки с одного диска на другой диск компьютера. Затем пользователь может свободно использовать этот репозиторий либо для своих целей, либо экспериментировать с изменениями в коде. С помощью разветвления git пользователи могут разрабатывать свои собственные модификации кода, который принадлежит кому-то другому.
Следует отметить, что этот процесс не оказывает никакого влияния на исходный код репозитория (также называемый восходящим репозиторием).
Раздвоение Git через GitHub — это процесс, который изолирован от GitHub. Это означает, что всякий раз, когда происходит fork git, репозиторий и код остаются ограниченными учетной записью пользователя на GitHub. Нет никакого влияния на локальную машину пользователя или участие Git в этом процессе.
Зачем развлетвлять репозиторий на GitHub?
Разветвление репозитория GitHub предоставляет пользователю копию вышестоящего репозитория для его учетной записи. Но зачем нам понадобилось раскошеливаться на репозиторий, разработанный кем-то другим? Ответ на этот вопрос содержится в самой концепции GitHub. GitHub был разработан, чтобы обеспечить платформу для всех разработчиков по всему миру, чтобы они могли внести свой вклад в проект друг друга и сделать лучшее, более надежное программное обеспечение. Очевидно, что никто не захочет видеть сотни изменений без их согласия в исходном репозитории. Таким образом, возникает понятие копии хранилища или раздвоенного хранилища.
Разветвление репозитория на GitHub выполняется для двух основных целей:
Примечание: разветвление разрешено для публичных репозиториев без разрешения. Но если хранилище является частным, то «форкнуть» его можно только с разрешения владельца хранилища.
Git Fork-это простой процесс в GitHub, и он не требует использования какой-либо команды git. Процесс Git Fork выполняется следующим образом:
Пришло время посмотреть, как это сделать.
Как создать ветку репозитория на GitHub?
Чтобы создать ветку одного из репозиториев на GitHub для практики, войдите в свою учетную запись.
Найдем имя учетной записи — harishrajora, а имя репозитория-ToolsQA. Вы можете использовать любой из следующих параметров или оба из них для поиска репозитория.
Если вы используете имя в качестве параметра, введите его в строке поиска. Нажмите All GitHub после ввода имени, чтобы выполнить поиск везде в GitHub.
Появится сообщение о том, что репозитория с таким именем нет.
Это происходит потому, что если вы посмотрите на левую колонку страницы, то по умолчанию в ней будут выбраны репозитории. Поскольку никакого хранилища с именем harishrajora не существует, оно показало это сообщение. Мы знаем, что harishrajora-это имя пользователя, поэтому выберите пользователей в списке.
Если вы используете имя+репозиторий в качестве параметра поиска, то введите в строке поиска следующее и нажмите All GitHub.
Продолжая поиск по имени пользователя, который мы сделали сначала, как только вы выберете пользователя, откроется его профиль. В профиле будут показаны популярные репозитории. Выберите ToolsQA среди репозиториев.
Нажатие ToolsQA откроет страницу репозитория. Вы также можете пропустить все вышеперечисленные шаги и перейти на страницу репозитория непосредственно по этой ссылке. Но, лучше знать, как ориентироваться.
Нажмите кнопку Fork, чтобы начать процесс раздвоения git.
Репозиторий ToolsQA будет разветвлен на ваш аккаунт мгновенно. Это можно увидеть по вашему имени пользователя после разветвления репозитория.
Теперь, когда у вас есть копия репозитория с помощью Git fork, вы можете изменить и улучшить код в соответствии с вашими потребностями. Также будут случаи, когда вы захотите удалить раздвоенный репозиторий.
Как Удалить Раздвоенный Репозиторий?
Пользователь может удалить раздвоенный репозиторий по любой причине. К счастью, это очень простой процесс. Просто имейте в виду, что не следует удалять репозиторий до тех пор, пока изменения не будут объединены в исходный репозиторий или пользователь не будет слишком уверен в удалении репозитория, так как после удаления вы потеряете все изменения.
Давайте удалим тот же самый репозиторий, который мы разветвляли выше. Для этого перейдите на страницу репозитория (ToolsQA), с которой мы разошлись в последнем разделе. Вы можете перейти на страницу репозитория из списка, расположенного в левом столбце панели мониторинга.
На странице репозитория перейдите в раздел Настройки, расположенный в верхней строке.
На странице настроек прокрутите вниз до нижней части страницы, и появится раздел под названием Опасная зона.
Нажмите Удалить этот репозиторий в этом разделе, как показано на рисунке выше.
На экране появится отказ от ответственности с просьбой переписать имя репозитория. Напишите имя репозитория, как показано на рисунке, и нажмите кнопку I understand the consequences, delete this repository button.
Это приведет к успешному удалению репозитория.
В последнем уроке мы познакомились с командой Git fetch и Read more
В одной из последних статей мы узнали о команде Git Read more
Мы уже знаем, как вносить изменения в локальное хранилище и Read more
Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more
«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more
Все данные, доступные в локальном репозитории, могут быть загружены в Read more
Код в чужой репозиторий или помогаем другу
Рассмотрим как нам присылать код в чужой репозиторий и как мы можем помогать другим в сервисе контроля версий Git.
Мы не можем просто так клонировать чужой проект, внести изменения и запушить их в чужой репозиторий, т.к. изменения могут попасть в проект только с согласия автора.
Открываем в GitHub нужный нам проект, репозиторий. И находим кнопку Fork.
Теперь у нас в Гитхабе есть полная копия данного проекта со всеми коммитами и ветками. Также теперь можно клонировать любой репозиторий, но пуш можно делать будет только в свой проект, а не в проект с которого сделан форк.
Сначала мы клонируем репозиторий командой:
После чего проверяем, так называемые ремоуты:
Получаем примерно такой ответ:
Теперь мы можем спокойно работать над проектом. После того как мы закончим работу и внесем нужные изменение мы сможем сформировать запрос на вливание или pull request.
Сначала мы делаем пуш (пример):
Дальше мы переходим в GutHub и видим, что гитхаб видит наш пуш и предлагает сделать pull request. Мы жмем зеленую кнопку Compare & Pull Request.
Жмем кнопку Create Pull Request:
Теперь можно сказать, что пулл риквест открыт. Автор изначального репозитория, с которого мы делали форк, сможет посмотреть изменения и принять их или отклонить.
Открытые pull request всегда показывают актуальную разницу между ветками.
Важно понимать, что форк на Github не синхронизирован с оригиналом автоматически. Но что если в оригинальном репозитории производились какие-либо изменения?
Теперь мы можем ввести локально такую команду:
Далее переключаемся в master:
И забираем изменения:
Теперь можно это всё отправить в свой Гитхаб:
Бывают ситуации, когда появляется конфликт между изменениями pull request и изменениями в оригинальном репозитории. Это происходит если автор оригинального репозитория внес какие-то изменения в ветку master. Сообщение о конфликте мы увидим на странице пулл риквеста.
Этот кофликт очень похож на конфликт, который мы разбирали в уроке про конфликты при слиянии веток или мёрдже.
Конфликт можно решить у себя. Для этого мы должны влить изменения мастера автора к себе и внести изменения у себя локально. После этого, если мы сделаем push, то конфликт должен исчезнуть и можно будет сделать pull request.
Итак, если есть репозиторий с которым нужно будет работать в компании, то сперва мы должны его скопировать, т.е. сделать форк. Таким образом у нас будет полная копия репозитория и она будет полностью принадлежать нам.
С этим своим репозиторием мы можем теперь спокойно работать и вносить в него изменения.
Далее нам нужно его (форк) клонировать на свою локальную машину.
Схематично во время обучения в HTMLAcademy процесс выглядел так:
Или так немного нагляднее:
Т.е. мы сделали форк и дальше клонируем репозиторий на локальный компьютер:
Далее мы создаем отдельную ветку:
В этой ветке мы вносим нужные нам изменения, далее индексируем изменения и делаем коммит.
Дальше, мы делаем пуш, т.е. отправляем изменения на Гитхаб:
После чего GitHub предложит сделать pull request.
Что делаем дальше, если дается новое задание? Возвращаемся в Git и переключаемся на ветку master.
Дальше нужно установить связь (ремоут) не только с личным репозиторием, но и с репозиторием от которого делали форк.
Добавим основной репозиторий:
Эту команду мы уже использовали выше:
Как видим, у нас теперь есть дополнительные ремоуты:
Теперь обновляемся и делаем pull изменений:
Делаем pull из основного репозитория. И теперь сможем работать и вносить изменения на локальной машине.
Работа с Git через консоль
Другие материалы по Git
Итак, вы получили задание: сделать форк вашего репозитория в GitHub, создать ветку и начать работу. Что за GitHub, какие команды, зачем, а главное, как всем этим пользоваться? Давайте разбираться.
Система контроля версий Git
Для начала определим, что такое система контроля версий.
Так называют программу, которая позволяет хранить разные версии одного и того же документа, легко переключаться между ранними и поздними вариантами, вносить и отслеживать изменения.
Систем контроля версий много и все они работают по принципу компьютерной игры, где вы можете вернуться к месту сохранения, если что-то пошло не так.
Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.
В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.
В мире разработки такие программы называют «терминал» или «консоль». А работает это так: мы вводим команду и получаем реакцию машины: сообщение об ошибке, запрос на подтверждение информации, результат выполненных действий.
Git — важный навык веб-разработчика
А лучший способ научиться программировать — профессия «React-разработчик». В программе три интенсива, прокачка навыков и оплачиваемая стажировка.
Устанавливаем Git
Если раньше вы не работали с Git, сперва его нужно установить. Способы зависят от операционной системы вашего компьютера.
Установка в Windows
Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.
Установка на macOS
Установка в Linux
Используйте обычный менеджер пакетов вашего дистрибутива. Откройте терминал и введите подходящие команды.
Полный список команд для различных дистрибутивов можно посмотреть здесь.
Проверим, что Git установлен
Настройка Git
После того как Git появился на компьютере, нужно ввести свои данные, а именно имя и адрес электронной почты. Ваши действия в Git будут содержать эту информацию.
Регистрация на GitHub
GitHub — веб-сервис, который основан на системе Git. Это такая социальная сеть для разработчиков, которая помогает удобно вести коллективную разработку IT-проектов. Здесь можно публиковать и редактировать свой код, комментировать чужие наработки, следить за новостями других пользователей. Именно в GitHub работаем мы, команда Академии, и студенты интенсивов.
Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.
Теперь у вас есть профиль на GitHub.
Устанавливаем SSH-ключи
Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.
Что такое SSH-ключ и зачем он нужен?
Чтобы работать со своего компьютера с GitHub, иметь доступ к проектам, хранящимся на сервисе, выполнять команды в консоли без постоянного подтверждения пароля, нужно пройти авторизацию у сервера. В этом помогают SSH-ключи.
Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.
Вы отправляете какую-то информацию на сервер, где хранится ваш публичный ключ, сервер понимает, что вы это вы, то есть идентифицирует именно вас, и даёт вам какой-то ответ. И только вы можете расшифровать этот ответ, потому что только у вас есть подходящий закрытый ключ. Получается что-то вроде связки логин-пароль только намного безопасней. Ваш пароль кто-то может узнать или подобрать, а чтобы получить ваш приватный SSH-ключ, злоумышленнику придётся взломать ваш компьютер.
Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.
Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге
Если проблема осталась, рекомендуем работать в Git Bash.
/.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.
/.ssh права доступа командой chmod 700
Можно пойти другим путём, открыть файл id_rsa.pub прямо в папке и просто скопировать содержимое оттуда.
Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).
Добавляем в свой профиль SSH-ключ.
Если всё сделано верно, в списке появится новый ключ.
Успешно добавленный ключ.
Теперь, наконец-то, мы можем начать работу с самим проектом.
Работа с репозиториями
Для начала определим, что такое репозиторий
Это рабочая директория с вашим проектом. По сути, это та же папка с HTML, CSS, JavaScript и прочими файлами, что хранится у вас на компьютере, но находится на сервере GitHub. Поэтому вы можете работать с проектом удалённо на любой машине, не переживая, что какие-то из ваших файлов потеряются — все данные будут в репозитории при условии, что вы их туда отправите. Но об этом позже.
Если над проектом трудится команда разработчиков, как правило, создаётся общий репозиторий, в котором находится рабочая версия проекта (назовём его мастер-репозиторий). При этом каждый пользователь клонирует себе в профиль оригинальный репозиторий и работает именно с копией. Такая копия называется форком. Так как форк — ваша персональная версия мастер-репозитория, в нём вы можете пробовать разные решения, менять код и не бояться что-то сломать в основной версии проекта.
Как сделать форк мастер-репозитория?
Заходим в нужный репозиторий, нажимаем на «вилку» с надписью fork. Форк репозитория создан и находится в вашем профиле на GitHub.
Теперь нужно склонировать форк себе на компьютер, чтобы вести работу с кодом локально. Тут нам и пригодится SSH.
Открываем консоль, переходим в директорию, где хотим сохранить папку с проектом, и вводим команду:
Кстати, если вы хотите, чтобы название папки с проектом у вас на компьютере отличалось от имени репозитория, можете дополнить команду клонирования, добавив в конце другое название:
Теперь, на вашем компьютере, в папке your_project или в той, название которой вы указали самостоятельно, находится полная копия репозитория c GitHub.
Сделали копию репозитория.
Новая ветка.
Эта команда позволяет переключаться между существующими ветками в проекте, после git checkout надо указать название нужной ветки.
Переключаемся между ветками.
После того как вы создали ветку, поработали в ней у себя локально — нужно сохранить результат, чтобы он не пропал и в итоге оказался в репозитории.
Состояние ветки.
Делаем коммит.
Сохранения зафиксированы, всё? Они теперь в репозитории и видны коллегам? Пока нет. Те изменения, которые мы внесли и сохранили, пока локальны. Их нужно послать на GitHub.
Отправляем изменения.
Теперь заходим на страницу нашего форка и создаём пулреквест, чтобы слить свой код с данными в мастер-репозитории. Что такое пулреквест? Это предложение изменить код в репозитории.
Вы исправили код, наставник или техлид одобрил ваши правки и принял пулреквест. Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.
Готово, теперь форк и оригинальный репозиторий находятся в актуальном состоянии.
Внесение собственного вклада в проекты
Теперь наша учётная запись создана и настроена, давайте же пройдёмся по деталям, которые будут полезны при внесении вклада в уже существующие проекты.
Создание ответвлений (fork)
Если вы хотите вносить свой вклад в уже существующие проекты, в которых у нас нет прав на внесения изменений путём отправки (push) изменений, вы можете создать своё собственное ответвление (fork) проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем пространстве имён и вы сможете легко делать изменения путём отправки (push) изменений.
Исторически так сложилось, что англоязычный термин «fork» (создание ветвления проекта) имел негативный контекстный смысл, данный термин означал, что кто-то повёл или ведёт проект с открытым исходным кодом в другом, отличном от оригинала, направлении, иногда данный термин так же означал создание конкурирующего проекта с раздельными авторами. В контексте GitHub, «fork» (создание ветвления проекта) просто означает создание ветвления проекта в собственном пространстве имён, что позволяет вносить публичные изменения и делать свой собственный вклад в более открытом виде.
Таким образом, проекты не обеспокоены тем, чтобы пользователи, которые хотели бы выступать в роли соавторов, имели право на внесение изменений путём их отправки (push). Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесённые изменения в оригинальный репозиторий проекта путём создания запроса на принятие изменений (Pull Request), сами же запросы на принятие изменений (Pull Request) будут описаны далее. Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект.
Для того, чтобы создать ответвление проекта, зайдите на страницу проекта и нажмите кнопку «Создать ответвление» («Fork»), которая расположена в правом верхнем углу.
Через несколько секунд вы будете перенаправлены на собственную новую проектную страницу, содержащую вашу копию, в которой у вас есть права на запись.
Рабочий процесс с использованием GitHub
GitHub разработан с прицелом на определённый рабочий процесс с использованием запросов на слияния. Этот рабочий процесс хорошо подходит всем: и маленьким, сплочённым вокруг одного репозитория, командам; и крупным распределённым компаниям, и группам незнакомцев, сотрудничающих над проектом с сотней копий. Рабочий процесс GitHub основан на тематических ветках, о которых мы говорили в главе Ветвление в Git.
Вот как это обычно работает:
Создайте форк проекта.
Создайте один или несколько коммитов с изменениями, улучшающих проект.
Отправьте эту ветку в ваш проект на GitHub.
Откройте запрос на слияние на GitHub.
Обсуждайте его, вносите изменения, если нужно.
Владелец проекта принимает решение о принятии изменений, либо об их отклонении.
Получите обновлённую ветку master и отправьте её в свой форк.
Очень напоминает подход, описанный в разделе Диспетчер интеграции главы 5, но вместо использования электронной почты, команда сотрудничает через веб-интерфейс.
Давайте посмотрим, как можно предложить изменения в проект, размещённый на GitHub.
В большинстве случаев можно использовать официальный инструмент GitHub CLI вместо веб-интерфейса GitHub. Инструмент доступен в системах Windows, MacOS и Linux. Посетите страницу GitHub CLI homepage для получения инструкций по установке и использованию.
Создание запроса на слияние
Тони ищет, чего бы запустить на своём новеньком Arduino. Кажется, он нашёл классный пример на https://github.com/schacon/blink.
Единственная проблема в том, что светодиод моргает слишком быстро; нам кажется, лучше установить задержку в три секунды, не одну. Так давайте исправим это и предложим изменения автору.
Клонируем нашу копию
Создаём тематическую ветку
Вносим свои изменения
Фиксируем изменения в тематической ветку
Отправляем новую ветку в нашу копию на GitHub
Теперь, если мы зайдём на страничку нашей копии на GitHub, мы увидим, что GitHub заметил наши изменения и предлагает открыть запрос на слияние с помощью большой зелёной кнопки.
Также можно зайти на страницу «Branches», по адресу https://github.com/ /
Если нажать на эту кнопку, появится экран ввода заголовка и описания предлагаемых изменений на рассмотрение владельцу проекта. Рекомендуется серьёзно подойти к составлению описания и сделать его максимально информативным, чтобы владелец проекта понимал, зачем эти изменения и какую пользу они принесут.
Также мы видим список коммитов в нашей тематической ветке, «опередивших» ветку master (в данном случае всего один коммит) и предпросмотр всех изменений, вносимых этими коммитами.
После создания запроса на слияние (путём нажатия кнопки «Create pull request» на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе.
Запросы на слияние широко используются для публичных проектов типа описанного выше, когда участник уже подготовил все изменения для слияния с основным репозиторием. Тем не менее, часто можно встретить использование запросов на слияние во внутренних проектах в самом начале цикла разработки. Обьяснение простое: вы можете обновлять тематическую ветку после открытия запроса на слияние, поэтому сам запрос открывается как можно раньше чтобы отслеживать прогресс разработки.
Обработка запроса на слияние
На этом этапе, владелец проекта может просмотреть предложенные изменения, принять, отклонить или прокомментировать их. Предположим, ему импонирует идея, но он предпочёл бы большую задержку перед включением или выключением света.
В то время как в главе Распределенный Git обсуждение изменений может производится через электронную почту, на GitHub всё происходит онлайн. Владелец проекта может просмотреть суммарные изменения, вносимые запросом, и прокомментировать любую отдельно взятую строку.
Как только владелец прокомментирует изменения, автор запроса на слияние (а также все подписавшиеся на этот репозиторий) получат уведомления. Далее мы рассмотрим как настроить уведомления, но сейчас, если Тони включил уведомления через электронную почту, он получит следующее письмо:
Кто угодно может оставлять комментарии к запросу на слияние. На Страница обсуждения запроса на слияние можно увидеть пример, где владелец проекта оставил комментарии как к строке кода, так и в основной секции обсуждения. Как вы могли заметить, комментарии к коду так же приведены в виде обсуждения.
Теперь участник может видеть что ему необходимо сделать для того, чтобы его изменения были приняты. К счастью, это тоже легко сделать. Используя почту, вам потребуется заново отправить свои изменения в список рассылки, а при использовании GitHub вы просто делаете коммит в тематическую ветку и повторяете push, что автоматически обновляет запрос на слияние. На рисунке Финальная стадия запроса на слияние также видно, что в обновленном запросе на слияние старый комментарий к коду был свёрнут, так как он относится к строке, которая с тех пор изменилась.
Когда участник сделает это, владелец проекта снова получит уведомление, а на странице запроса будет отмечено, что проблема решена. Фактически, как только строка кода имеющая комментарий будет изменена, GitHub заметит это и удалит устаревшее отличие.
Примечательно, что если вы перейдёте на вкладку «Files Changed» в этом запросе на слияние, то увидите «унифицированную» разницу — это суммарные изменения, которые будут включены в основную ветку при слиянии тематической ветки. В терминологии git diff это эквивалентно команде git diff master…
для ветки, на которой основан этот запрос на слияние. В Определение применяемых изменений детальнее описан данный тип отличий.
GitHub так же проверяет может ли запрос на слияние быть применён без конфликтов и предоставляет кнопку для осуществления слияния на сервере. Эта кнопка отображается только если у вас есть права на запись в репозиторий и возможно простейшее слияние. По нажатию на неё GitHub произведёт «non-fast-forward» слияние, что значит даже если слияние может быть осуществлено перемоткой вперед, всё равно будет создан коммит слияния.
При желании, можно стянуть ветку и произвести слияние локально. Если эта ветка будет слита в master ветку и отправлена на сервер, то GitHub автоматически закроет запрос на слияние.
Это основной рабочий процесс, который используется большинством проектов на GitHub. Создаются тематические ветки, открываются запросы на слияние, производится обсуждение, при необходимости производятся доработки в ветке и, наконец, запрос либо закрывается, либо сливается.
Важно отметить, что можно открывать запросы на слияние между двумя ветками в одном репозитории. Если вы работаете над функционалом с кем-то ещё и у вас обоих есть права записи, то вы можете отправить свою тематическую ветку в репозиторий и открыть запрос на слияние в master ветку в рамках одного проекта, что позволит инициировать процедуру проверки кода и его обсуждения. Создание ответвлений проекта не является обязательным.
Продвинутые запросы на слияние
На текущий момент мы рассмотрели основы участия в проекте на GitHub, давайте рассмотрим некоторые интересные секреты и уловки касательно запросов слияния, чтобы вы могли более эффективно их использовать.
Запросы слияния как Патчи
Важно понимать, что многие проекты не воспринимают запросы слияния как очередь идеальных патчей, которые должны применяться аккуратно и по порядку, как и большинство проектов, участие в которых основывается на отправке набора патчей через списки почтовых рассылок. Большинство проектов на GitHub понимают ветки запросов на слияние как беседу относительно предлагаемого изменения, завершающуюся слиянием унифицированных изменений.
Это важное различие, так как изменение предлагается до того, как код станет считаться идеальным, что гораздо реже происходит с распространяемыми наборами патчей через списки рассылок. Обсуждение происходит на более раннем этапе и выработка правильного решения происходит за счёт усилий сообщества. Когда код предлагается через запрос на слияние и сопровождающий проекта или сообщество предлагает изменения, то не применяется набор патчей, а отправляются результирующие изменения как новый коммит в ветку, двигая обсуждение вперёд и сохраняя уже проделанную работу нетронутой.
Например, если вы вернётесь и посмотрите на Финальная стадия запроса на слияние, то увидите, что участник не делал перебазирование своего коммита и не отправлял новый запрос на слияние. Вместо этого были сделаны новые коммиты и отправлены в существующую ветку. Таким образом, если вы в будущем вернётесь к этому запросу слияния, то легко найдёте весь контекст принятого решения. По нажатию кнопки «Merge» целенаправленно создаётся коммит слияния, который указывает на запрос слияния, оставляя возможность возврата к цепочке обсуждения.
Следование за исходным репозиторием
Если ваш запрос на слияние устарел или не может быть слит без конфликтов, то вам нужно изменить его, чтобы сопровождающий мог просто его слить. GitHub проверит это за вас и под каждым из запросов на слияние отобразит уведомление, можно ли его слить без конфликтов или нет.
Если вы видите что-то вроде Запрос имеет конфликты слияния, то вам следует изменить свою ветку так, чтобы исключить конфликты и сопровождающий не делал лишнюю работу.
Существует два основных варианта это сделать. Вы можете либо перебазировать свою ветку относительно целевой ветки (обычно, относительно master ветки исходного репозитория), либо слить целевую ветку в свою.
Большинство разработчиков на GitHub выбирают последний вариант по тем же причинам, что и мы в предыдущем разделе. Важна история и окончательное слияние, а перебазирование не принесёт вам ничего, кроме немного более чистой истории, при этом оно гораздо сложнее и может стать источником ошибок.
Если вы хотите сделать запрос на слияние применяемым, то следует добавить исходный репозиторий как новый удалённый, слить изменения из его основной ветки в вашу тематическую, если имеются исправить все проблемы и, наконец, отправить все изменения в ту ветку, на основании которой был открыт запрос на слияние.
Предположим, что в примере «tonychacon», который мы использовали ранее, основной автор сделал изменения, которые конфликтуют с запросом на слияние. Рассмотрим это пошагово.
Получаем последние изменения из него.
Сливаем основную ветку в нашу тематическую.
Исправляем указанный конфликт.
Отправляем изменения в ту же тематическую ветку.
Как только это будет сделано, запрос на слияние будет автоматически обновлён и перепроверен на возможность слияния.
Если вы очень хотите перебазировать ветку, чтобы её почистить, то, конечно, вы можете это сделать, но настоятельно не рекомендуется переписывать ветку, к которой уже открыт запрос на слияние. Если другие люди уже стянули её и проделали много работы, то вы столкнётесь со всеми проблемами, описанными в разделе Опасности перемещения главы 3. Вместо этого, отправьте перебазированную ветку в новую на GiHub и откройте новый запрос на слияние, который указывает на предыдущий, затем закройте исходный.
Ссылки
Возможно, ваш следующий вопрос будет: «Как мне сослаться на предыдущий запрос слияния?» Оказывается, существует много способов ссылаться на другие вещи практически везде, где у вас есть права записи на GitHub.
Давайте начнём с перекрёстных ссылок для запросов слияния или проблем. Всем запросам слияния и проблемам присваиваются уникальные номера в пределах проекта. Например, у вас не может быть запроса на слияние с номером #3 и проблемы с номером #3. Если вы хотите сослаться на любой запрос слияния или проблему из другого места, просто добавьте # в комментарий или описание. Так же можно указывать более конкретно, если проблема или запрос слияния находятся где-то ещё; пишите username# если ссылаетесь на проблему или запрос слияния, находящиеся в ответвлённом репозитории, или username/repo# если ссылаетесь на другой репозиторий.
Рассмотрим это на примере. Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос слияния для неё и сейчас хотим сослаться на предыдущий запрос слияния из нового. Так же мы хотим сослаться на проблему, находящуюся в ответвлённом репозитории, и на проблему из совершенно другого проекта. Мы можем составить описание как указано на Перекрёстные ссылки в запросе слияния.
Когда мы отправим запрос на слияние, то увидим что-то вроде Отображение перекрёстных ссылок в запросе слияния.
