Форкнуть репозиторий что это
Код в чужой репозиторий или помогаем другу
Рассмотрим как нам присылать код в чужой репозиторий и как мы можем помогать другим в сервисе контроля версий 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 из основного репозитория. И теперь сможем работать и вносить изменения на локальной машине.
Внесение собственного вклада в проекты
Теперь наша учётная запись создана и настроена, давайте же пройдёмся по деталям, которые будут полезны при внесении вклада в уже существующие проекты.
Создание ответвлений (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# если ссылаетесь на другой репозиторий.
Рассмотрим это на примере. Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос слияния для неё и сейчас хотим сослаться на предыдущий запрос слияния из нового. Так же мы хотим сослаться на проблему, находящуюся в ответвлённом репозитории, и на проблему из совершенно другого проекта. Мы можем составить описание как указано на Перекрёстные ссылки в запросе слияния.
Когда мы отправим запрос на слияние, то увидим что-то вроде Отображение перекрёстных ссылок в запросе слияния.
Форкнуть репозиторий что это
Разберемся с терминами
Потому что это пугает больше всего.
Git — это распределенная система контроля версий кода. Она помогает разработчикам сохранять все изменения, внесённые в код, отслеживать изменения в файлах и работать совместно с командой.
Github — это cервис для хостинга (то есть хранения) репозиториев. На Github есть возможность контролировать разные версии кода, управлять исходным кодом и работать вместе с командой. То есть делать то же, что и Git.
И вот в чем разница между ними: Git — это инструмент, который просто впервые позволил одновременно команде править код и работать над одним проектом вместе, а GitHub — это платформа для проектов, использующих Git.
Open Source — это прозрачный подход к созданию проектов. Разработчики открывают код продуктов, над которыми работают — над ним можно вместе работать, а ещё — копировать. И всё это на Github.
Коммит (commit) — это публичное сохранение, фиксация (в архиве, репозитории и др.) изменений в коде.
Репозиторий (repo) — это хранилище версий кода какого-то проекта**.** В репозитории есть журнал коммитов, которые были добавлены в него. У репозитория могут быть разные ветки — у каждого своя история и происхождение. По умолчанию основная ветвь называется «мастер». Как правило, весь готовый код объединяется в мастер.
Форк (fork) — клон репозитория. В копии репозитория можно вносить свои собственные изменения, редактировать файлы. Например, вы решили внести изменения в чей-то репозиторий, внесли, а теперь можете поделиться им и отправить автору оригинального репозитория. Это будет считаться запросом на слияние и называться pull request.
Вот, смотрите, справа от Scala иконка форкнутого репозитория.
Issue — это условные карточки-задачи, которые вы можете создавать, чтобы отслеживать работу над багами, внедрение новых функций или других запросов. Как тикеты в Trello.
Readme — это файл, который в первую очередь нужно прочитать, когда вы открываете репозиторий. У хорошего проекта с открытым исходным кодом обычно есть файл Readme с объяснением того, для чего он предназначен, где он опубликован, и некоторой документацией по его использованию.
Contribution — это действия пользователя Github, по которым считается его активность на платформе:
Что ещё важно знать?
Давайте вернемся к вопросу: что такое Github в принципе. Это платформа, где разработчики и компании (да, в том числе) могут хранить проекты, редактировать их вместе. Но мы видим только часть репозиториев — те, что доступны всем.
Итак, пример. Разработчик, который активен на Github (у него регулярно что-то появляется), является автором или участником крупного проекта с открытым исходным кодом (open source). Делаем вывод, что, скорее всего, у него большой разработки на языке проекта. То есть активность и ценность вклада разработчика в целом рассказывает нам об уровне его навыков.
Но! Не каждый разработчик использует Github, и не каждый может — есть много компаний, которые запрещают ребятам участвовать в open source проектах.
На что обратить внимание в профиле?
1. Стек
Github — идеальный инструмент, чтобы узнать больше про технологический стек. Вы можете просто посмотреть, репозиториев с какой технологией больше всего или над чем он работал в последнее время.
И тут вам пригодятся вот эти инструменты: