что значит fork github
Что такое 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 fork. Зачем нужны форки и как с ними работать
Как и в случае с ребейзом, с форками в гите я разобрался не сразу. Вроде ничего особенного там нет, это просто копия репозитория, но натыкаешься на какие-то подводные камни и не сразу понимаешь, как их обойти. Да и вообще, зачем нужны эти форки, тоже осознаешь не сразу. Когда врубаешься, все становится просто, ну это как всегда.
Я не сторонник подхода «чо тут не понимать, тупой штоле» и попробую рассказать человеческими словами, что вообще такое форки, зачем они нужны и как с ними работать. А вы оцените, как получилось. Синьор git девелоперам статья покажется банальщиной, но тем, кто еще не успел обрести такой титул, будет полезно.
Ты работаешь в компании Company в какой-то команде и со своими ребятами пишешь код, например, блога вашего сайта. Рядом сидят ребята из другой команды, которые занимаются админкой. У каждой команды отдельный репозиторий, вы работаете и друг другу не мешаете.
Доступа к их репозиторию нет, поэтому идете договариваться. Обсуждаете вместе детали. Так, нужно завести поле в базе, какое-нибудь булево isAllowedComments, соответственно, подготовить миграцию, вывести это поле отдельной колонкой в таблице пользователей, там поставить чекбокс и уметь сохранять это в базу. А еще в апи, которое вы дергаете, нужно добавить в респонсе это самое поле. Вроде немного, ребята говорят, окей, через пару дней сделаем. И на самом деле делают, все хорошо.
Небольшие просьбы вроде этой появляются все чаще. То вам нужно накатить миграцию и разбанить всех пользователей, которые зарегались больше года назад. То в апи в респонсе вам понадобилось количество комментов пользователя. И каждый раз вы идете с такой мелочью к соседям и просите это сделать.
Рано или поздно ребятам из админки это надоедает, потому что у них хватает и своей работы. Они предлагают вам дать права на репозиторий и пробовать такие небольшие задачи делать самим. Говорят, мол, с такой фигней типа добавления поля в респонс вы и сами справитесь. Если что, зовите, поможем. Прав на пуш в мастер, конечно, никто не даст, но свои ветки создавайте и присылайте мердж-реквесты. Мы смотрим, если все хорошо, то мерджим в мастер и выкладываем в прод. Все довольны. И нам работы меньше, и вам не ждать, пока у нас руки дойдут до вашей задачи.
Вы с командой соглашаетесь. Ты клонируешь их репозиторий и пилишь фичи. Примерно так
Дальше идешь в битбакеты-гитхабы, в репозиторий админки, делаешь мердж-реквест и ждешь, когда его примут. Обычная схема. Мердж-реквест примерно везде делается одинаково: ищешь кнопку «Создать мердж-реквест» или пулл-реквест, выбираешь свою ветку, затем выбираешь, куда сливать (обычно уже по умолчанию будет мастер) и жмешь «Отправить».
Проходит пара месяцев. Ты случайно замечаешь в репозитории админки ветку petya/update-email. Спрашиваешь ребят из админки, а что за Петя вам коммитит? Те говорят, а, это чувак из отдела емейлов, мы им тоже доступ дали, как и вам. Они тоже приходили к нам по 3 раза в месяц, мы задолбались и теперь с ними работаем по вашей схеме. Ничего, все довольны.
Проходит год. Команд, которые работают по такой схеме, уже десяток. В репозитории появляются ветки
Эти ветки множатся, мерджатся между собой и вообще живут своей жизнью. Называются они как попало, коммиты подписывают кто во что горазд, старые ветки не удаляются после мерджей. Надвигается хаос.
Конечно, ребятам из админки не очень нравится такой мусор в их репозитории. Сначала они пытаются с этим бороться и проводить разъяснительные работы. Пытаются рассказать о правилах приличия в их репозитории. Пишут доку и официальное письмо всем программистам, где все подробно рассказывают. Как именовать ветки, как подписывать коммиты, не забывать удалять старые ветки, не заводить лишние ветки без надобности и прочее.
Это дело хорошее, но бесполезное. В компании полсотни разрабов, у каждого своя команда и свои правила работы с репозиторием. Люди приходят и уходят, эти правила уже никто не помнит, да и всем пофигу, главное фичу сделать, чего там заморачиваться с ветками и коммитами. Пусть у команды админки об этом голова болит. Главное, у нас все хорошо, в своем командном проекте, потому что мы никого к себе не пускаем, ахаха. Поэтому и ветки красиво называются, и коммиты адекватно подписаны. Нас тут 5 человек работают, уж между собой-то договоримся.
А между тем в репозитории админки образуется все больший трэш. То злодеи опять пушат ветки с названиями не по ГОСТу, и тимлида бесят. То сам тимлид с похмелья выдал новому чуваку доступы на пуш в мастер, а тот на радостях запушил миграцию, которая пол-сайта уронила. То по ошибке смерджили petya/hotfix вместо vasya/hotfix. В общем весело всем, кроме ребят из админки.
И вот однажды что-то изменилось. Тебе понадобилось запилить новую фичу и ты привычно набиваешь
Сначала идешь в гитхаб-битбакет и ищешь там в нужном репозитории кнопку Fork. Обычно она недалеко от кнопки clone. Жмешь на fork и для тебя создается проект. Если исходный был company/adminka.git, то твой будет примерно vasya/adminka.git. Ну или примерно так. Дальше клонируешь его как обычно
Естественно, свой форк клонируешь, а не оригинальный. Затем там создаешь привычно ветку и пушишь ее.
Заходишь в гитхаб-битбакет исходного репозитория, жмешь «Создать мердж-реквест», выбираешь свою ветку, она будет называться примерно vasya/adminka/blog/new-field, и ждешь, пока мердж-реквест примут.
Пока все ровно так, как ты привык, ничего нового. Мердж-реквест принимают и все хорошо.
Через месяц тебе нужно сделать еще одну задачу. Ты привычно подтягиваешь мастер и настораживаешься
За месяц нет новых коммитов в мастере? Да не верю. Идешь в репозиторий админки, смотришь, там до фига коммитов, чуть не каждый день в мастер пушат. В чем дело?
Присматриваешься, откуда ты пулишься и видишь, что это vasya/adminka. Это твой репозиторий, твой форк. Конечно, ты его месяц не трогал и он ничего не знает о новых коммитах в исходном проекте. Их нужно подтянуть и только тогда создавать новую ветку. Можно сделать это так
То есть вместо origin указываешь адрес нужного репозитория. И вот теперь-то подтянется мастер именно исходного проекта, а не твоего. А еще лучше сделать так, чтобы не набивать каждый раз длинный адрес
Вот теперь твой мастер актуален, можешь создавать ветку и пушить в репозиторий. Пушить уже в origin, то есть свой, потому что в upstream, исходный, тебе пушить никто не даст. То есть еще раз, пулишь мастер так
а пушишь свою ветку так
По сути это все, что нужно знать о работе с форками. После этого идешь создавать мердж-реквест, твоя ветка уже видна в исходном репозитории. Если ты работал над веткой, а за это время в мастер накидали еще коммитов, то перед отправкой мердж-реквеста стоит отребейзиться от мастера
Тут можешь делать, как хочешь, твой форк, твои правила. Можешь пушить с форсом, как у меня в примере. Если не хочешь с форсом, то можешь создать отдельную ветку и положить коммит в нее. Как угодно. Главное, чтобы твои коммиты лежали поверх свежих коммитов из мастера. Тогда никто не будет возникать при рассмотрении мердж-реквеста, а ты будешь уверен, что у тебя самые свежие обновления.
И на этом все. Главное, что нужно сделать, это добавить upstream и четко понимать, в чем его отличие от origin.
С форками можно работать и в компании на полсотни разработчиков, но особенно это популярно в опенсорсе. Возьмите какой-нибудь проект, например, vuejs, у него больше 20 тысяч форков и 3 сотни контрибьюторов. Представьте, что бы творилось в репозитории, пусти всех этих энтузиастов пушить свои правки. А так они спокойно работают со своими форками и присылают пулл-реквесты, не засоряя проект.
Всем удачи. Любите гит, он совсем не страшный 🙂
Fork a repo
In this article
A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.
Most commonly, forks are used to either propose changes to someone else’s project or to use someone else’s project as a starting point for your own idea. You can fork a repository to create a copy of the repository and make changes without affecting 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’ve found, you can:
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 Learning Lab course on maintaining open source communities.
If you haven’t yet, you should first set up Git. Don’t forget to set up authentication to GitHub.com from Git as well.
Forking a repository
You might fork a project to propose changes to the upstream, or original, 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.
To learn more about GitHub CLI, see «About GitHub CLI.»
To create a fork of a repository, use the gh repo fork subcommand.
Cloning your forked repository
Right now, you have a fork of the Spoon-Knife repository, but you don’t 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
To clone the repository using HTTPS, under «Clone with HTTPS», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click Use SSH, then click
. To clone a repository using GitHub CLI, click Use GitHub CLI, then click
. 
Change the current working directory to the location where you want the cloned directory.
Press Enter. Your local clone will be created.
To learn more about GitHub CLI, see «About GitHub CLI.»
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.
Choose the repository you want to clone from the list.
Click Choose. and navigate to a local path where you want to clone the repository.
Click Clone.
Configuring Git to sync your fork with the original repository
When you fork a project in order to propose changes to the original repository, you can configure Git to pull changes from the original, or 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
To clone the repository using HTTPS, under «Clone with HTTPS», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click Use SSH, then click
. To clone a repository using GitHub CLI, click Use GitHub CLI, then click
.
Change directories to the location of the fork you cloned.
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.»
You can make any changes to a fork, including:
Find another repository to fork
Fork a repository to start contributing to a project. You can fork a repository to your user account or any organization where you have repository creation permissions. For more information, see «Roles in an organization.»
If you have access to a private repository and the owner permits forking, you can fork the repository to your user account or any organization on GitHub Team where you have repository creation permissions. You cannot fork a private repository to an organization using GitHub Free. For more information, see «GitHub’s products.»
You can browse Explore to find projects and start contributing to open source repositories. For more information, see «Finding ways to contribute to open source on GitHub.»
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. For more information see, «Create a repository.»
Each repository in 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 Support Community.
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
Fork на github. Верно ли моё понимание?
дисклеймер: гитхабом (да и вообще системой контроля версий) ни разу не пользовался, просто решил поинтересоваться.
Верно ли я понимаю, что делая fork репозитория, я делаю полную копию.
Но будет ли считаться форком изменения кода, добавление всякого и прочее.
Верно ли то, что форк нужен для вариативности (различных версий, другого внешнего вида программы, доп.функционала) форкнутого репозитория, и это никак не значит, что репозиторий-родитель будет принимать изменения вносимые в форке?
Форк — это сугубо ваша копия репозитория. С момента «форкования» вы получаете текущую копию, которая потом никак не синхронизируется с оригиналом. Иными словами, она только ваша. Изменения в форке никак не отразятся на оригинале.
В дальнейшем вы можете вручную синхронизировать форк с оригиналом, тем самым обновляя свою копию. Как правило, форки используются для подготовки изменений в оригинал: вы не можете создать ответвление в оригинальной версии т.к. у нее другой владелец (не вы) — для этого вам надо сначала сделать себе копию, в копии сделать измнения и только потом уже предложить владельцу оригинала применить их у себя.
Иногда форки используются чтобы создать отдельную «ветвь», которая кардинальным образом будет отличаться от оригинала: например, когда у вас соверешенное иное видение того, как должен выглядеть проект, и вы хотите переписать его.
а что если
1) Сделан форк
2) в моей копии я сделал много изменений/дополнений
3) в оригинале произошли изменения
4) я сделал синхронизацию.
Значит ли это, что мои изменения (сделанные на шаге 2) пропадут? или же дополниться лишь то, что добавилось в оригинале?
гитхабом (да и вообще системой контроля версий) ни разу не пользовался, просто решил поинтересоваться
Вообще-то, стоило сначала почитать про принципы работы VCS, тогда подобные вопросы не возникали бы.