6.2 GitHub — Внесение собственного вклада в проекты
Теперь наша учётная запись создана и настроена, давайте же пройдёмся по деталям, которые будут полезны при внесении вклада в уже существующие проекты.
Создание ответвлений (fork)
Если вы хотите вносить свой вклад в уже существующие проекты, в которых у нас нет прав на внесения изменений путём отправки (push) изменений, вы можете создать своё собственное ответвление (fork) проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем пространстве имён и вы сможете легко делать изменения путём отправки (push) изменений.
Исторически так сложилось, что англоязычный термин «fork» (создание ветвления проекта) имел негативный контекстный смысл, данный термин означал, что кто-то повёл или ведёт проект с открытым исходным кодом в другом, отличном от оригинала, направлении, иногда данный термин так же означал создание конкурирующего проекта с раздельными авторами. В контексте GitHub, «fork» (создание ветвления проекта) просто означает создание ветвления проекта в собственном пространстве имён, что позволяет вносить публичные изменения и делать свой собственный вклад в более открытом виде.
Таким образом, проекты не обеспокоены тем, чтобы пользователи, которые хотели бы выступать в роли соавторов, имели право на внесение изменений путём их отправки (push). Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесённые изменения в оригинальный репозиторий проекта путём создания запроса на принятие изменений (Pull Request), сами же запросы на принятие изменений (Pull Request) будут описаны далее. Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект.
Для того, чтобы создать ответвление проекта, зайдите на страницу проекта и нажмите кнопку «Создать ответвление» («Fork»), которая расположена в правом верхнем углу.
Через несколько секунд вы будете перенаправлены на собственную новую проектную страницу, содержащую вашу копию, в которой у вас есть права на запись.
Рабочий процесс с использованием GitHub
GitHub разработан с прицелом на определённый рабочий процесс с использованием запросов на слияния. Этот рабочий процесс хорошо подходит всем: и маленьким, сплочённым вокруг одного репозитория, командам; и крупным распределённым компаниям, и группам незнакомцев, сотрудничающих над проектом с сотней копий. Рабочий процесс GitHub основан на тематических ветках, о которых мы говорили в главе Ветвление в Git.
Вот как это обычно работает:
Создайте форк проекта.
Создайте тематическую ветку на основании ветки master .
Создайте один или несколько коммитов с изменениями, улучшающих проект.
Отправьте эту ветку в ваш проект на GitHub.
Откройте запрос на слияние на GitHub.
Обсуждайте его, вносите изменения, если нужно.
Владелец проекта принимает решение о принятии изменений, либо об их отклонении.
Получите обновлённую ветку master и отправьте её в свой форк.
Очень напоминает подход, описанный в разделе Диспетчер интеграции главы 5, но вместо использования электронной почты, команда сотрудничает через веб-интерфейс.
Давайте посмотрим, как можно предложить изменения в проект, размещённый на GitHub.
В большинстве случаев можно использовать официальный инструмент GitHub CLI вместо веб-интерфейса GitHub. Инструмент доступен в системах Windows, MacOS и Linux. Посетите страницу GitHub CLI homepage для получения инструкций по установке и использованию.
Создание запроса на слияние
Тони ищет, чего бы запустить на своём новеньком Arduino. Кажется, он нашёл классный пример на https://github.com/schacon/blink.
Единственная проблема в том, что светодиод моргает слишком быстро; нам кажется, лучше установить задержку в три секунды, не одну. Так давайте исправим это и предложим изменения автору.
Для начала, нажмите кнопку «Fork», как было сказано выше, чтобы заполучить собственную копию проекта. Мы зарегистрированы на GitHub под именем «tonychacon», так что наша копия окажется по адресу https://github.com/tonychacon/blink , где мы сможем редактировать её. Мы клонируем его, создадим тематическую ветку, внесём необходимые изменения и, наконец, отправим их на GitHub.
Клонируем нашу копию
Создаём тематическую ветку
Вносим свои изменения
Фиксируем изменения в тематической ветку
Отправляем новую ветку в нашу копию на GitHub
Теперь, если мы зайдём на страничку нашей копии на GitHub, мы увидим, что GitHub заметил наши изменения и предлагает открыть запрос на слияние с помощью большой зелёной кнопки.
Также можно зайти на страницу «Branches», по адресу https://github.com/<user>/<project>/branches , найти интересующую ветку и открыть запрос оттуда.
Если нажать на эту кнопку, появится экран ввода заголовка и описания предлагаемых изменений на рассмотрение владельцу проекта. Рекомендуется серьёзно подойти к составлению описания и сделать его максимально информативным, чтобы владелец проекта понимал, зачем эти изменения и какую пользу они принесут.
Также мы видим список коммитов в нашей тематической ветке, «опередивших» ветку master (в данном случае всего один коммит) и предпросмотр всех изменений, вносимых этими коммитами.
После создания запроса на слияние (путём нажатия кнопки «Create pull request» на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе.
Запросы на слияние широко используются для публичных проектов типа описанного выше, когда участник уже подготовил все изменения для слияния с основным репозиторием. Тем не менее, часто можно встретить использование запросов на слияние во внутренних проектах в самом начале цикла разработки. Объяснение простое: вы можете обновлять тематическую ветку после открытия запроса на слияние, поэтому сам запрос открывается как можно раньше чтобы отслеживать прогресс разработки.
Обработка запроса на слияние
На этом этапе, владелец проекта может просмотреть предложенные изменения, принять, отклонить или прокомментировать их. Предположим, ему импонирует идея, но он предпочёл бы большую задержку перед включением или выключением света.
В то время как в главе Распределённый Git обсуждение изменений может производится через электронную почту, на GitHub всё происходит онлайн. Владелец проекта может просмотреть суммарные изменения, вносимые запросом, и прокомментировать любую отдельно взятую строку.
Как только владелец прокомментирует изменения, автор запроса на слияние (а также все подписавшиеся на этот репозиторий) получат уведомления. Далее мы рассмотрим как настроить уведомления, но сейчас, если Тони включил уведомления через электронную почту, он получит следующее письмо:
Кто угодно может оставлять комментарии к запросу на слияние. На Страница обсуждения запроса на слияние можно увидеть пример, где владелец проекта оставил комментарии как к строке кода, так и в основной секции обсуждения. Как вы могли заметить, комментарии к коду так же приведены в виде обсуждения.
Теперь участник может видеть что ему необходимо сделать для того, чтобы его изменения были приняты. К счастью, это тоже легко сделать. Используя почту, вам потребуется заново отправить свои изменения в список рассылки, а при использовании GitHub вы просто делаете коммит в тематическую ветку и повторяете push, что автоматически обновляет запрос на слияние. На рисунке Финальная стадия запроса на слияние также видно, что в обновлённом запросе на слияние старый комментарий к коду был свёрнут, так как он относится к строке, которая с тех пор изменилась.
Когда участник сделает это, владелец проекта снова получит уведомление, а на странице запроса будет отмечено, что проблема решена. Фактически, как только строка кода имеющая комментарий будет изменена, GitHub заметит это и удалит устаревшее отличие.
Примечательно, что если вы перейдёте на вкладку «Files Changed» в этом запросе на слияние, то увидите «унифицированную» разницу — это суммарные изменения, которые будут включены в основную ветку при слиянии тематической ветки. В терминологии git diff это эквивалентно команде git diff master…<branch> для ветки, на которой основан этот запрос на слияние. В Определение применяемых изменений детальнее описан данный тип отличий.
GitHub так же проверяет может ли запрос на слияние быть применён без конфликтов и предоставляет кнопку для осуществления слияния на сервере. Эта кнопка отображается только если у вас есть права на запись в репозиторий и возможно простейшее слияние. По нажатию на неё GitHub произведёт «non-fast-forward» слияние, что значит даже если слияние может быть осуществлено перемоткой вперед, всё равно будет создан коммит слияния.
При желании, можно стянуть ветку и произвести слияние локально. Если эта ветка будет слита в master ветку и отправлена на сервер, то GitHub автоматически закроет запрос на слияние.
Это основной рабочий процесс, который используется большинством проектов на GitHub. Создаются тематические ветки, открываются запросы на слияние, производится обсуждение, при необходимости производятся доработки в ветке и, наконец, запрос либо закрывается, либо сливается.
Важно отметить, что можно открывать запросы на слияние между двумя ветками в одном репозитории. Если вы работаете над функционалом с кем-то ещё и у вас обоих есть права записи, то вы можете отправить свою тематическую ветку в репозиторий и открыть запрос на слияние в master ветку в рамках одного проекта, что позволит инициировать процедуру проверки кода и его обсуждения. Создание ответвлений проекта не является обязательным.
Продвинутые запросы на слияние
На текущий момент мы рассмотрели основы участия в проекте на GitHub, давайте рассмотрим некоторые интересные секреты и уловки касательно запросов слияния, чтобы вы могли более эффективно их использовать.
Запросы слияния как Патчи
Важно понимать, что многие проекты не воспринимают запросы слияния как очередь идеальных патчей, которые должны применяться аккуратно и по порядку, как и большинство проектов, участие в которых основывается на отправке набора патчей через списки почтовых рассылок. Большинство проектов на GitHub понимают ветки запросов на слияние как беседу относительно предлагаемого изменения, завершающуюся слиянием унифицированных изменений.
Это важное различие, так как изменение предлагается до того, как код станет считаться идеальным, что гораздо реже происходит с распространяемыми наборами патчей через списки рассылок. Обсуждение происходит на более раннем этапе и выработка правильного решения происходит за счёт усилий сообщества. Когда код предлагается через запрос на слияние и сопровождающий проекта или сообщество предлагает изменения, то не применяется набор патчей, а отправляются результирующие изменения как новый коммит в ветку, двигая обсуждение вперёд и сохраняя уже проделанную работу нетронутой.
Например, если вы вернётесь и посмотрите на Финальная стадия запроса на слияние, то увидите, что участник не делал перебазирование своего коммита и не отправлял новый запрос на слияние. Вместо этого были сделаны новые коммиты и отправлены в существующую ветку. Таким образом, если вы в будущем вернётесь к этому запросу слияния, то легко найдёте весь контекст принятого решения. По нажатию кнопки «Merge» целенаправленно создаётся коммит слияния, который указывает на запрос слияния, оставляя возможность возврата к цепочке обсуждения.
Следование за исходным репозиторием
Если ваш запрос на слияние устарел или не может быть слит без конфликтов, то вам нужно изменить его, чтобы сопровождающий мог просто его слить. GitHub проверит это за вас и под каждым из запросов на слияние отобразит уведомление, можно ли его слить без конфликтов или нет.
Если вы видите что-то вроде Запрос имеет конфликты слияния, то вам следует изменить свою ветку так, чтобы исключить конфликты и сопровождающий не делал лишнюю работу.
Существует два основных варианта это сделать. Вы можете либо перебазировать свою ветку относительно целевой ветки (обычно, относительно master ветки исходного репозитория), либо слить целевую ветку в свою.
Большинство разработчиков на GitHub выбирают последний вариант по тем же причинам, что и мы в предыдущем разделе. Важна история и окончательное слияние, а перебазирование не принесёт вам ничего, кроме немного более чистой истории, при этом оно гораздо сложнее и может стать источником ошибок.
Если вы хотите сделать запрос на слияние применяемым, то следует добавить исходный репозиторий как новый удалённый, слить изменения из его основной ветки в вашу тематическую, если имеются исправить все проблемы и, наконец, отправить все изменения в ту ветку, на основании которой был открыт запрос на слияние.
Предположим, что в примере «tonychacon», который мы использовали ранее, основной автор сделал изменения, которые конфликтуют с запросом на слияние. Рассмотрим это пошагово.
Добавляем исходный репозиторий как удалённый с именем upstream .
Получаем последние изменения из него.
Сливаем основную ветку в нашу тематическую.
Исправляем указанный конфликт.
Отправляем изменения в ту же тематическую ветку.
Как только это будет сделано, запрос на слияние будет автоматически обновлён и перепроверен на возможность слияния.
Одна из замечательных особенностей Git — это то, что вы можете делать это постоянно. Если у вас очень длительный проект, вы можете легко сливать изменения из целевой ветки снова и снова и иметь дело только с конфликтами, возникшими с момента вашего последнего слияния, что делает процесс очень управляемым.
Если вы очень хотите перебазировать ветку, чтобы её почистить, то, конечно, вы можете это сделать, но настоятельно не рекомендуется переписывать ветку, к которой уже открыт запрос на слияние. Если другие люди уже стянули её и проделали много работы, то вы столкнётесь со всеми проблемами, описанными в разделе Опасности перемещения главы 3. Вместо этого, отправьте перебазированную ветку в новую на GitHub и откройте новый запрос на слияние, который указывает на предыдущий, затем закройте исходный.
Ссылки
Возможно, ваш следующий вопрос будет: «Как мне сослаться на предыдущий запрос слияния?» Оказывается, существует много способов ссылаться на другие вещи практически везде, где у вас есть права записи на GitHub.
Давайте начнём с перекрёстных ссылок для запросов слияния или проблем. Всем запросам слияния и проблемам присваиваются уникальные номера в пределах проекта. Например, у вас не может быть запроса на слияние с номером #3 и проблемы с номером #3. Если вы хотите сослаться на любой запрос слияния или проблему из другого места, просто добавьте #<num> в комментарий или описание. Так же можно указывать более конкретно, если проблема или запрос слияния находятся где-то ещё; пишите username#<num> если ссылаетесь на проблему или запрос слияния, находящиеся в ответвлённом репозитории, или username/repo#<num> если ссылаетесь на другой репозиторий.
Рассмотрим это на примере. Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос слияния для неё и сейчас хотим сослаться на предыдущий запрос слияния из нового. Так же мы хотим сослаться на проблему, находящуюся в ответвлённом репозитории, и на проблему из совершенно другого проекта. Мы можем составить описание как указано на Перекрёстные ссылки в запросе слияния.
Когда мы отправим запрос на слияние, то увидим что-то вроде Отображение перекрёстных ссылок в запросе слияния.
Заметьте, что указанная полная ссылка на GitHub была сокращена до необходимого минимума.
Если Тони сейчас вернётся назад и закроет оригинальный запрос слияния, то мы это увидим, так как он упомянут в новом, а GitHub автоматически создаст отслеживающее событие в хронике запроса слияния. Это значит, что все, кто просматривает закрытый запрос слияния, могут легко перейти к запросу слияния, который его заменил. Ссылка будет выглядеть как указано на Отображение перекрёстных ссылок в закрытом запросе слияния.
Кроме идентификационных номеров, можно ссылаться на конкретный коммит используя SHA-1. Следует указывать полный 40 символьный хеш SHA-1, но если GitHub увидит его в комментарии, то автоматически подставит ссылку на коммит. Как было сказано выше, вы можете ссылаться на коммиты как в других, так и в ответвлённых репозиториях точно так же, как делали это с Проблемами.
GitHub-версия разметки Markdown
Ссылки на другие Проблемы — это лишь часть интереснейших вещей, которые вы можете делать в текстовых полях на GitHub. Для «проблемы» или «запроса слияния» в полях описания, комментария, комментария кода и других вы можете использовать так называемую «GitHub-версию разметки Markdown». Разметка похожа на обычный текст, который основательно преобразуется.
Смотрите Пример написания и отображения текста с разметкой для примера как использовать разметку при написании комментариев и текста.
GitHub расширил возможности обычной разметки. Эти возможности могут быть очень полезными при создании запросов слияния или комментариев и описаний к проблемам.
Списки задач
Список задач — это первая действительно важная возможность специфической разметки GitHub, особенно для запросов слияния. Список задач представляет собой список флажков для задач, которые вы хотите выполнить. Размещение его в описании Проблемы или запроса на слияние обычно указывает на то, что должно быть сделано до того, как проблема будет считаться решённой.
Список задач можно добавить следующим образом:
Если добавить этот список в описание запроса на слияние или проблемы, то он будет отображён следующим образом Отображение списка задач в комментарии
Он часто используется в запросах на слияние для отображения списка того, что вы хотите сделать до того, как запрос будет готов к слиянию. Вы можете просто кликнуть по флажку, чтобы обновить комментарий — не нужно редактировать комментарий вручную, чтобы пометить задачу как выполненную.
Так же GitHub ищет списки задач в запросах на слияние и проблемах и отображает их как метаданные на страницах, где они упоминаются. Например, если в вашем запросе на слияние есть задачи и вы просматриваете список всех запросов, то можно увидеть на сколько готов каждый из них. Это позволяет разбивать запрос на слияние на несколько подзадач и помогает другим людям отслеживать прогресс ветки. Пример приведён на Статистика задач в списке запросов слияния.
Такая возможность невероятно полезна когда вы открываете запрос на слияние на раннем этапе реализации и отслеживаете прогресс с помощью него.
Отрывки кода
В комментарии так же можно вставлять отрывки кода. Это особенно полезно когда вы хотите показать что-нибудь, что вы собираетесь попробовать сделать, до того, как включить это в вашу ветку. Так же часто применяется для добавления примеров кода, который не работает или мог быть добавлен в запрос на слияние.
Для добавления отрывка кода следует обрамить его обратными кавычками.
Если вы укажете название языка, как показано на примере, GitHub попробует применить к нему подсветку синтаксиса. Для приведённого примера код будет выглядеть как на Отображение обрамлённого кода.
Цитирование
Если вы отвечаете только на часть большого комментария, то можно цитировать только выбранную часть, предваряя её символом > . Это настолько часто используется, что даже существует комбинация клавиш для этого. Если в комментарии выделить текст, на который вы собираетесь ответить, и нажать клавишу r , то выделенный текст будет включён как цитата в ваш комментарий.
Цитаты выглядят примерно так:
После обработки комментарий будет выглядеть как Пример отображения цитаты.
Смайлики
Наконец, вы можете использовать смайлики. На GitHub вы можете часто встретить их в комментариях или запросах на слияние. Для них есть даже помощник. Например, если при наборе комментария ввести символ двоеточия : , то будут предложены варианты автодополнения.
Смайлы имеют вид :<name>: и могут располагаться в любом месте комментария. Например, вы можете написать что-нибудь вроде этого:
Такой комментарий будет выглядеть как на Перегруженный смайликами комментарий.
Не то чтобы это невероятно полезно, но добавляет немного веселья и эмоций там, где трудно выразить какие-то эмоции.
На текущий момент существует много интернет сервисов, где используются смайлики. Отличную шпаргалку по поиску смайликов, которые выражают нужную вам эмоцию, можно найти здесь:
Картинки
Технически, картинки не относятся к разметке GitHub, но их использование очень полезно. В дополнение к ссылкам на картинки в комментариях, GitHub позволяет встраивать картинки в комментарии.
Если вернуться немного назад к Перекрёстные ссылки в запросе слияния, то над областью редактирования вы увидите небольшую подсказку «Parsed as Markdown». Нажав не неё, вы получите полную подсказку по использованию GitHub разметки.
Поддержание GitHub репозитория в актуальном состоянии
После создания форка, ваш репозиторий будет существовать независимо от оригинального репозитория. В частности, при появлении в оригинальном репозитории новых коммитов GitHub информирует вас следующим сообщением:
При этом GitHub никогда не обновляет ваш репозиторий — это вы должны делать сами. К счастью, это очень просто сделать.
Первый способ не требует конфигурации. Например, если вы сделали форк репозитория https://github.com/progit/progit2.git , то актуализировать ветку master можно следующим образом:
Если вы находитесь на другой ветке — перейти на ветку master .
Получить изменения из репозитория https://github.com/progit/progit2.git и слить их с веткой master .
Отправить локальную ветку master в ваш форк origin .
Каждый раз писать URL репозитория для получения изменений достаточно утомительно. Этот процесс можно автоматизировать слегка изменив настройки:
Добавить исходный репозиторий как удалённый и назвать его progit .
Получить ветки репозитория progit , в частности ветку master .
Настроить локальную ветку master на получение изменений из репозитория progit .
Установить origin как репозиторий по умолчанию для отправки.
После этого, процесс обновления становится гораздо проще:
Если вы находитесь на другой ветке — перейти на ветку master .
Получить изменения из репозитория progit и слить их с веткой master .
Отправить локальную ветку master в ваш форк origin .
Данный подход не лишён недостатков. Git будет молча выполнять указанные действия и не предупредит вас в случае, когда вы добавили коммит в master , получили изменения из progit и отправили всё вместе в origin — все эти операции абсолютно корректны. Поэтому вам стоит исключить прямое добавление коммитов в ветку master , поскольку эта ветка фактически принадлежит другому репозиторию.
What is Git Forking, And How Do You use it on Github?
A fork is a copy of a repository. Forking a repository allows to freely experiment with changes without affecting the original project.
Confused? let me try again. Forking in GitHub is the process of creating a copy of a complete repository to the user’s GitHub Account from another account. When a user forks a repository, all the files in the repository are automatically copied to the user’s account on GitHub and it feels like the user’s own repository. This process is similar to copying a folder from one drive to another drive on a computer. The user is then free to use this repository either for their purpose or experiment with changes in the code. Through git forking, the users can develop their own modifications to the code that belongs to someone else.
To be noted, that this process does not have any effect on the original repository (also called an upstream repository) code.
Git forking through GitHub is a process that is isolated to GitHub. This means that whenever a git fork happens, the repository and the code remain confined to the user’s GitHub account. There is no effect on the local machine of the user or the involvement of Git in the process.
Why Fork a Repository on GitHub?
Forking a GitHub repository provides an individual with a copy of the upstream repository to their account. But why would we need to fork a repository which is developed by someone else? The answer to this question is in the concept of GitHub itself. GitHub was developed to provide a platform to all the developers around the world so that they can contribute to each other’s projects and make better, more reliable software. It is obvious no one would want to see hundreds of changes without their consent on the original repository. Hence, the concept of a copy of the repository or a forked repository comes into the picture.
Forking a repository on GitHub is done for two main purposes:
- Improving someone’s code/software: Improving someone’s code does not necessarily mean fixing the bugs and improving the execution time. Improving can be adding a new feature to the existing software/repository. For example, I navigate to a repository and liked the concept of the software. Now I have something else in mind that could be useful for the same software. I can fork the repository, develop the feature on my machine and send the changes to the owner of the repository.
- Reusing the code in a project: A user can also make use of git fork to fork the repository of another user to use in their own project. The idea here is “why to reinvent the wheel”. The popularity of Git is also because people add their code, project, module, software, etc… on GitHub as a public repository. Now other people are allowed to use that open source code to their project, which helps them to save their efforts and time.
Note: Forking is allowed for public repositories without permission. But if the repository is private, one can only be able to fork if he or she has permission from the owner of the repository.
How does Forking (Git Fork) work?
Git Fork is a simple process in GitHub and it does not require to use any git command. The process of Git Fork follows the below steps:
- Fork a Repository: User creates a copy of the repository to their own GitHub account, the steps for the same are covered in the next section.
- Code changes: This involves git cloning, which is the next chapter of the Git Tutorial series. But on a high level, the user makes the changes and push back to their own forked repository.
- Send changes to Original Repository: This process is called as Pull Request in Git. At this step, the user sends the changes to the owner of the repository as a request. Now it is up to the owner to accept the changes or reject. Pull request is a request to the owner of the upstream repository to accept the user changes.
Alright then, I hope it is clear about the concept of forking a repository on GitHub. It is time we see how to do that.
Git Fork
In this section, we will see how to fork a GitHub repository. A user can fork any public repository and add it to their own account. But, for simplicity, we will be forking a small repository that I created on my other account.
How to Fork a Repository on GitHub?
To fork one of my repositories on GitHub for practice, Login to your account.
Now, my account name (from which we will fork the repo) is paulmooredev while the repository name is ToolsQA. You can use any one of the following parameters or both of them to search for the repository.
If you are using the name as a parameter, type the name in the search bar. Press All GitHub after entering the name to search everywhere in GitHub.
A message will appear telling there is no repository by this name.
This is because if you look at the left column of the page, Repositories is selected on that by default. Since there is no repository by the name paulmooredev1, it showed that message. We know that paulmooredev is a user name, so, select Users in the list.
The number in front of users denotes there are two users available by that name. Select the first one with the name paulmooredev only.
If you are using the name+repository as the search parameter, then type the following in the search bar and press All GitHub.
Continuing with the search by user name that we did first, once you choose a user, his profile will open up. The profile will show popular repositories. Select ToolsQA among the repositories.
Press Fork button to initiate the git forking process.
The repository ToolsQA will be forked to your account instantly. This can be seen by your username after forking the repository.
Now that you have a copy of the repository using git fork, you can modify and improve the code according to yourself. There will also be cases when you would want to delete the forked repository. The next section will help you out in this regard.
How To Delete A Forked Repository?
A user can delete the forked repository for any reason. Maybe the requirement is over, or maybe the user wants to have a lesser mess in the repository section when the changes are done. Deleting a forked repository also helps in memory saving since GitHub creates a pointer of the original repository to the forked repository (along with the changes that take extra memory). These are just a few reasons, there can be any number of reasons for deleting a forked repository.
Fortunately, this is a very simple process. Just keep in mind not to delete the repository until the changes have been merged into the original repository or the user is too sure about deleting the repository since after deleting, you will lose all the changes.
Alright, let’s delete the same repository that we forked above. For this, go to the repository page (ToolsQA) from which we forked in the last section. You can navigate to the repository page from the repository list located in the left column of the dashboard.
1.On the repository page, go to Settings located on the top row.
- On the settings page, scroll down to the bottom of the page and a section called Danger Zone will appear.
- Press Delete this repository in this section as shown in the image above.
- A disclaimer will popup on the screen asking you to rewrite the repository name. Write the repository name as shown in the image and press I understand the consequences, delete this repository button.
- This will successfully delete the repository.
GitHub’s heart is Git repositories. It is meant to share them all across the world. Forking a repository in GitHub is one of the most common actions on GitHub. How will you contribute if you won’t fork the original repository onto your account? Forking the repository and deleting it is an easy process and I hope you got the understanding it.
Now it may seem that git fork and git clone are the same things, they are not. You might hear people sometimes get confused over these two things. But no developer working on GitHub will get confused because they have their own importance and differences. This we will learn in our next tutorial about cloning and how it differs from forking.
Fork a repo
A fork is a new repository that shares code and visibility settings with the original “upstream” repository.
Platform navigation
Tool navigation
About forks
A fork is a new repository that shares code and visibility settings with the original “upstream” repository. Forks are often used to iterate on ideas or changes before they are proposed back to the upstream repository, such as in open source projects or when a user does not have write access to the upstream repository. For more information, see «Working with forks.»
Propose changes to someone else’s project
For example, you can use forks to propose changes related to fixing a bug. Rather than logging an issue for a bug you have found, you can:
- Fork the repository.
- Make the fix.
- Submit a pull request to the project owner.
Use someone else’s project as a starting point for your own idea.
Open source software is based on the idea that by sharing code, we can make better, more reliable software. For more information, see the «About the Open Source Initiative» on the Open Source Initiative.
For more information about applying open source principles to your organization’s development work on GitHub.com, see GitHub’s white paper «An introduction to innersource.»
When creating your public repository from a fork of someone’s project, make sure to include a license file that determines how you want your project to be shared with others. For more information, see «Choose an open source license» at choosealicense.com.
For more information on open source, specifically how to create and grow an open source project, we’ve created Open Source Guides that will help you foster a healthy open source community by recommending best practices for creating and maintaining repositories for your open source project. You can also take a free GitHub Skills course on maintaining open source communities.
Prerequisites
If you haven’t yet, first set up Git and authentication with GitHub.com from Git. For more information, see «Set up Git.»
Forking a repository
You might fork a project to propose changes to the upstream repository. In this case, it’s good practice to regularly sync your fork with the upstream repository. To do this, you’ll need to use Git on the command line. You can practice setting the upstream repository using the same octocat/Spoon-Knife repository you just forked.
On GitHub.com, navigate to the octocat/Spoon-Knife repository.
In the top-right corner of the page, click Fork.
Under «Owner,» select the dropdown menu and click an owner for the forked repository.
By default, forks are named the same as their upstream repositories. Optionally, to further distinguish your fork, in the «Repository name» field, type a name.
Optionally, in the «Description» field, type a description of your fork.
Optionally, select Copy the DEFAULT branch only.
For many forking scenarios, such as contributing to open-source projects, you only need to copy the default branch. If you do not select this option, all branches will be copied into the new fork.
Click Create fork.
Note: If you want to copy additional branches from the upstream repository, you can do so from the Branches page. For more information, see «Creating and deleting branches within your repository.»
To learn more about GitHub CLI, see «About GitHub CLI.»
To create a fork of a repository, use the gh repo fork subcommand.
To create the fork in an organization, use the —org flag.
You can fork a repository on GitHub.com or in GitHub Desktop. For information about forking on GitHub.com, see the web browser version of this article.
In GitHub Desktop, if you attempt to clone a repository that you don’t have write access to, a fork is automatically created for you.
In the File menu, click Clone Repository.
Click the tab that corresponds to the location of the repository you want to clone. You can also click URL to manually enter the repository location.
From the list of repositories, click the repository you want to clone.
To select the local directory into which you want to clone the repository, next to the «Local Path» field, click Choose. and navigate to the directory.
At the bottom of the «Clone a Repository» window, click Clone.
Read the information in the «How are you planning to use this fork?» window.
- If you plan to use this fork for contributing to the original upstream repository, click To contribute to the parent project.
- If you plan to use this fork for a project not connected to the upstream, click For my own purposes.
Click Continue.
Cloning your forked repository
Right now, you have a fork of the Spoon-Knife repository, but you do not have the files in that repository locally on your computer.
On GitHub.com, navigate to your fork of the Spoon-Knife repository.
Above the list of files, click
Code.
Copy the URL for the repository.
To clone the repository using HTTPS, under «HTTPS», click
To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click SSH, then click
To clone a repository using GitHub CLI, click GitHub CLI, then click
Open Terminal Terminal Git Bash .
Change the current working directory to the location where you want the cloned directory.
Type git clone , and then paste the URL you copied earlier. It will look like this, with your GitHub username instead of YOUR-USERNAME :
Press Enter. Your local clone will be created.
To learn more about GitHub CLI, see «About GitHub CLI.»
To create a clone of your fork, use the —clone flag.
In the File menu, click Clone Repository.
Click the tab that corresponds to the location of the repository you want to clone. You can also click URL to manually enter the repository location.
From the list of repositories, click the repository you want to clone.
To select the local directory into which you want to clone the repository, next to the «Local Path» field, click Choose. and navigate to the directory.
At the bottom of the «Clone a Repository» window, click Clone.
Configuring Git to sync your fork with the upstream repository
When you fork a project in order to propose changes to the upstream repository, you can configure Git to pull changes from the upstream repository into the local clone of your fork.
On GitHub.com, navigate to the octocat/Spoon-Knife repository.
Above the list of files, click
Code.
Copy the URL for the repository.
To clone the repository using HTTPS, under «HTTPS», click
To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click SSH, then click
To clone a repository using GitHub CLI, click GitHub CLI, then click
Open Terminal Terminal Git Bash .
Change directories to the location of the fork you cloned.
- To go to your home directory, type just cd with no other text.
- To list the files and folders in your current directory, type ls .
- To go into one of your listed directories, type cd your_listed_directory .
- To go up one directory, type cd .. .
Type git remote -v and press Enter. You will see the current configured remote repository for your fork.
Type git remote add upstream , and then paste the URL you copied in Step 3 and press Enter. It will look like this:
To verify the new upstream repository you have specified for your fork, type git remote -v again. You should see the URL for your fork as origin , and the URL for the upstream repository as upstream .
Now, you can keep your fork synced with the upstream repository with a few Git commands. For more information, see «Syncing a fork.»
To learn more about GitHub CLI, see «About GitHub CLI.»
To configure a remote repository for the forked repository, use the —remote flag.
To specify the remote repository’s name, use the —remote-name flag.
Editing a fork
You can make any changes to a fork, including:
- Creating branches:Branches allow you to build new features or test out ideas without putting your main project at risk.
- Opening pull requests: If you want to contribute back to the upstream repository, you can send a request to the original author to pull your fork into their repository by submitting a pull request.
Find another repository to fork
Fork a repository to start contributing to a project. You can fork any public repository to your personal account, or to an organization where you have permission to create repositories. If you have access to a private repository and the owner permits forking, you can fork the repository to your personal account, or to an organization on GitHub Team where you have permission to create repositories. You cannot fork a private repository to an organization using GitHub Free. For more information about GitHub Team and GitHub Free, see «GitHub’s plans.» For more information about when you can fork a repository, see «About permissions and visibility of forks.»
You can browse Explore GitHub to find projects and start contributing to open source repositories. For more information, see «Finding ways to contribute to open source on GitHub.»
Next Steps
You have now forked a repository, practiced cloning your fork, and configured an upstream repository.
For more information about cloning the fork and syncing the changes in a forked repository from your computer, see «Set up Git.»
You can also create a new repository where you can put all your projects and share the code on GitHub. Creating a repository for your project allows you to store code in GitHub. This provides a backup of your work that you can choose to share with other developers. For more information, see “Create a repository.»»
Each repository on GitHub is owned by a person or an organization. You can interact with the people, repositories, and organizations by connecting and following them on GitHub. For more information, see «Be social.»
GitHub has a great support community where you can ask for help and talk to people from around the world. Join the conversation on GitHub Community.
Help and support
Help us make these docs great!
All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.
Рабочий процесс Forking Workflow
Рабочий процесс с форками принципиально отличается от других популярных рабочих процессов Git. В этом рабочем процессе каждый разработчик получает собственный репозиторий на сервере, вместо того чтобы использовать единый репозиторий на стороне сервера в качестве «центральной» базы кода. Таким образом, каждый автор имеет не один, а два репозитория Git: один закрытый локальный и один публичный на сервере. Рабочий процесс с форками чаще всего встречается в публичных проектах с открытым исходным кодом.
Основное преимущество рабочего процесса с форками заключается в том, что поступивший код можно интегрировать, не отправляя его в единый центральный репозиторий. Разработчики отправляют коммиты в собственные репозитории на сервере, в то время как официальный репозиторий обновляется только силами пользователя, ответственного за поддержку проекта. В итоге такой пользователь может принимать коммиты от любых разработчиков, не предоставляя им доступ для записи в официальную базу кода.
В рабочем процессе с форками обычно используется модель ветвления, принятая в Git-flow. То есть для завершенных функциональных веток выполняется слияние в исходный репозиторий пользователя, ответственного за поддержку проекта. В результате мы получаем распределенный рабочий процесс для гибкой и безопасной совместной работы крупных органичных команд (включая недоверенных третьих лиц). Кроме того, этот рабочий процесс оптимален для проектов с открытым исходным кодом.
Порядок действий
Подобно другим рабочим процессам Git, рабочий процесс с форками начинается с создания официального публичного репозитория, хранящегося на сервере. Однако когда к работе над проектом приступает новый разработчик, он не клонирует официальный репозиторий напрямую.
Вместо этого он делает форк официального репозитория, чтобы создать его копию на сервере. Эта новая копия становится его собственным публичным репозиторием: другим разработчикам не разрешается отправлять туда коммиты, но они могут извлекать оттуда изменения (вы скоро поймете, почему это важно). Создав копию официального репозитория на сервере, разработчик выполняет команду git clone , чтобы скопировать его на локальную машину. Как и в случае с другими рабочими процессами, этот репозиторий становится закрытой средой разработки.
Чтобы опубликовать локальный коммит, разработчик отправляет его не в официальный репозиторий, а в собственный публичный. После этого он создает запрос pull для переноса кода в главный репозиторий, чтобы сообщить пользователю, ответственному за поддержку проекта, что обновление готово к интеграции. Запрос pull также выступает в качестве удобной ветки обсуждения в тех случаях, когда с поступившим кодом возникают проблемы. Ниже приводится пошаговый пример этого рабочего процесса.
- Разработчик делает форк «официального» репозитория, расположенного на сервере, и в результате получает собственную копию репозитория на сервере.
- Разработчик клонирует созданную копию на сервере в локальную систему.
- В локальный клон добавляется удаленный путь к «официальному» репозиторию Git.
- Создается новая локальная функциональная ветка.
- Разработчик вносит изменения в новую ветку.
- Для изменений создаются новые коммиты.
- Разработчик отправляет ветку в собственную копию репозитория на сервере.
- Разработчик открывает запрос pull для переноса кода из новой ветки в «официальный» репозиторий.
- Запрос pull на слияние утверждается, после чего выполняется слияние с исходным репозиторием на сервере.
Чтобы интегрировать функцию в официальную базу кода, пользователь, ответственный за поддержку проекта, помещает изменения автора в свой локальный репозиторий, проверяет, не нарушают ли они работу проекта, выполняет их слияние со своей локальной главной веткой ( main ), после чего отправляет main ветку в официальный репозиторий на сервере. После этого поступивший код становится частью проекта, и другие разработчики должны получить его из официального репозитория, чтобы синхронизировать свои локальные репозитории.
Важно понимать, что понятие «официальный репозиторий» в рабочем процессе с форками — простая условность. Официальным его можно назвать лишь по той причине, что он выступает публичным репозиторием пользователя, ответственного за поддержку проекта.
Сравнение создания форков и клонирования
Важно отметить, что репозитории с форками и создание форков не требуют специальных операций. Форки репозиториев создаются стандартной командой git clone . В большинстве случаев форки репозиториев являются «клонами на сервере», а для их размещения и управления ими обычно используют сторонний сервис Git, такой как Bitbucket. Отдельной команды Git для создания форков репозиториев не существует. При клонировании, по сути, происходит копирование репозитория и его истории.
Ветвление в рабочем процессе с форками
Собственные публичные репозитории — это просто удобный способ поделиться ветками с другими разработчиками. Пользователям все равно следует отделять функции с помощью веток, как это происходит в рабочем процессе с функциональными ветками и в Git-flow. Разница заключается лишь в том, как этими ветками можно поделиться. В рабочем процессе с форками их помещают в локальный репозиторий другого разработчика, а в рабочих процессах с функциональными ветками и Git-flow — в официальный репозиторий.
Форк репозитория
В проекте, где используется рабочий процесс с форками, каждому новому разработчику нужно создать форк официального репозитория. Как уже говорилось ранее, создание форка — это обычная операция git clone . Для создания форка нужно установить SSH-соединение с сервером и выполнить команду git clone , чтобы скопировать репозиторий в другое место на сервере. В популярных сервисах размещения Git, таких как Bitbucket, предусмотрены функции создания форков репозитория, с помощью которых можно автоматизировать этот шаг.
Клонирование форка
Затем каждому разработчику нужно клонировать собственный публичный форк репозитория. Это можно сделать с помощью знакомой команды git clone .
Если для размещения таких репозиториев используется Bitbucket, разработчику, занятому в проекте, потребуется создать аккаунт Bitbucket и клонировать свой форк репозитория с помощью следующей команды:
Добавление удаленного подключения
В то время как в других рабочих процессах Git используется одно удаленное подключение, которое указывает на центральный репозиторий, рабочему процессу с форками требуется связь с официальным репозиторием и личным репозиторием разработчика на сервере. Хотя эти удаленные подключения можно назвать как угодно, обычно подключение к форку репозитория называется origin (создается автоматически при выполнении команды git clone ), а подключение к официальному репозиторию — upstream.
Вам потребуется самостоятельно создать удаленное подключение upstream с помощью указанной выше команды. Это позволит вам без труда поддерживать актуальность локального репозитория по мере выполнения официального проекта. Обратите внимание: если в вышестоящем (upstream) репозитории включена аутентификация (т. е. он не является репозиторием открытого исходного кода), вам нужно будет указать имя пользователя, например:
При этом перед клонированием или получением изменений из официальной базы кода пользователь должен будет указать действительный пароль.
Работа в ветке: внесение и отправка изменений
В локальной копии форка репозитория разработчик может редактировать код, делать коммиты изменений и создавать ветки так же, как и в других рабочих процессах Git:
Все изменения будут полностью закрытыми, пока разработчик не отправит их в свой публичный репозиторий. А если кто-то внес изменения в официальный проект, можно получить доступ к новым коммитам с помощью команды git pull :
Разработчики должны писать код в отдельной функциональной ветке, поскольку такой подход обычно приводит к ускоренному слиянию.
Выполнение запроса pull
Когда разработчик готов поделиться новой функцией, ему нужно сделать две вещи. Во-первых, он должен открыть другим разработчикам доступ к своему коду, поместив его в свой публичный репозиторий. Поскольку удаленное подключение origin, скорее всего, уже настроено, ему остается только выполнить следующую команду:
В отличие от других рабочих процессов, здесь удаленное подключение origin указывает на личный репозиторий разработчика на сервере, а не на основную базу кода.
Во-вторых, разработчик должен сообщить пользователю, ответственному за поддержку проекта, что он хочет выполнить слияние функции с официальной базой кода. В Bitbucket имеется кнопка запроса pull, при нажатии которой появляется форма, в которой нужно указать ветку для ее слияния с официальным репозиторием. Как правило, разработчику нужно интегрировать свою функциональную ветку в главную ветку вышестоящего (upstream) удаленного репозитория.
Резюме
Напомним, что рабочий процесс с форками обычно используется в публичных проектах с открытым исходным кодом. Форк создают с помощью операции git clone с участием серверной копии репозитория проекта. Рабочий процесс с форками часто используется в сочетании с сервисом размещения Git, например Bitbucket. Вот общий пример рабочего процесса с форками:
- Вы хотите включить свой код в библиотеку с открытым исходным кодом, размещенную по адресу bitbucket.org/userA/open-project
- С помощью Bitbucket вы создаете форк репозитория по адресу Bitbucket.org/yourName/Open-project
- В локальной системе вы выполняете команду git clone для https://bitbucket.org/YourName/open-project, чтобы получить локальную копию репозитория
- Вы создаете новую функциональную ветку в локальном репозитории
- Вы создаете новую функцию и выполняете команду git commit для сохранения изменений
- Затем вы отправляете новую функциональную ветку в свой удаленный форк репозитория
- С помощью Bitbucket вы открываете запрос pull для слияния новой ветки с исходным репозиторием по адресу bitbucket.org/userA/open-project
Рабочий процесс с форками помогает пользователю, ответственному за поддержку проекта, открыть репозиторий и начать принимать код от любых разработчиков. При этом ему не приходится вручную управлять настройками авторизации каждого отдельного автора. Он использует рабочий процесс в стиле pull. Чаще всего рабочий процесс с форками используется в проектах с открытым исходным кодом, однако его можно применять и в рабочих процессах частного бизнеса, чтобы обеспечить строгий контроль над слиянием с веткой релиза. Он может быть полезен командам, которые используют диспетчеры развертывания или имеют четкие циклы релизов.
Не знаете, какой рабочий процесс вам подходит? Ознакомьтесь с нашей подробной страницей сравнения рабочих процессов Git.