Fork на GitHub — что это такое
Продолжаю увлекательное знакомство новичка с сервисом GitHub и с системой контроля версий Git.
Так как имею учетную запись на GitHub, которую регулярно использую, то у меня возник вопрос, который не мог не возникнуть, рано или поздно. Касается он такой темы, как fork.
Не знаю даже, как правильно поступить дальше — попытаться самому описать вопрос, своими словами; или же попытаться сделать вольный перевод статьи на эту тему — Fork A Repo. Но лучше все же расскажу своими словами.
Fork — это копия репозитория
Fork — это вcего навсего копия репозитория. Это тоже самое, что branch в Git. Только на GitHub такой branch называется
fork
— присутствует своя терминология. Само слово fork в переводе означает ответвление. Для того, чтобы воспользоваться
fork
, нужно иметь свою собственную учетную запись на GitHub; и нужно войти под ней на GitHub в момент выполнения
fork
fork
? Для тех же целей, что и branch в Git. С помощью него создается точная копия оригинального репозитория, только на сервисе GitHub. В копии репозитория можно вносить свои собственные изменения, редактировать файлы или удалять директории.
Как только все изменения будут внесены, то можно поделиться ими — отправить авторам оригинального репозитория запрос на слияние вашего измененного репозитория с их оригинальным репозиторием. Такой запрос называется
pull request
Если авторам оригинального репозитория ваши изменения понравятся, то они могут внести их в свой собственый оригинальный репозиторий — принять запрос и выполнить слияние.
Существование fork полностью отвечает идеологии OpenSource и GitHub, в частности. Идеология OpenSource заключается в свободном обмене исходным кодом программ и fork однозначно помогает в этом деле. С помощью fork можно одним движением получить копию любого исходного кода, выложенного на GitHub в свободном доступе.
Fork — создание копии репозитория
Давайте от слов перейдем к делу и на практике выполним хотя бы один fork на GitHub. К слову сказать, в приведенной выше статье-оригинале Fork A Repo дается ссылка на репозиторий Spoon-Knife, созданный авторами статьи для учебных целей — научиться работать с fork на GitHub. Вы, уважаемый читатель, также можете свободно воспользоваться им для себя, чтобы научиться пользоваться fork.
Я воспользуюсь другим репозиторием, который выложен в свободном доступе достаточно известным верстальщиком Юрием Артюхом (akella). Ниже привожу шаги по созданию Fork на GitHub.
- захожу на GitHub под своей учетной записью
- перехожу по ссылке github/akella/sass, по которой расположен репозиторий akella/sass
Фактически, теперь я нахожусь в репозитории akella/sass пользователя akella (Юрий Артюх). Об этом красноречиво говорит надпись akella/sass в левом верхнем углу окна браузера. В правом верхнем углу окна браузера нахожу кнопку Fork.
И нажимаю на нее:
Может случиться, что вы, уважаемый читатель, ничего и не заметите. Но это не так на самом деле. Приглядитесь к “главной” надписи — она изменилась с
About forks
A fork is a new repository that shares code and visibility settings with the original “upstream” repository.
About forks
Forks let you make changes to a project without affecting the original repository, also known as the «upstream» repository. After you fork a repository, you can fetch updates from the upstream repository to keep your fork up to date, and you can propose changes from your fork to the upstream repository with pull requests. A fork can be owned by either a personal account or an organization.
When you view a forked repository on GitHub, the upstream repository is indicated below the name of the fork.
In open source projects, forks are often used to iterate on ideas or changes before incorporating the changes into the upstream repository. If you fork a public repository to your personal account, make changes, then open a pull request to propose your changes to the upstream repository, you can give anyone with push access to the upstream repository permission to push changes to your pull request branch (including deleting the branch). This speeds up collaboration by allowing repository maintainers to make commits or run tests locally to your pull request branch from a user-owned fork before merging. You cannot give push permissions to a fork owned by an organization. For more information, see «Allowing changes to a pull request branch created from a fork.»
Deleting a fork will not delete the original upstream repository. You can make any changes you want to your fork, and there will be no effect on the upstream. For example, you can add collaborators, rename files, or generate GitHub Pages on the fork without affecting the upstream. After a fork is deleted, you cannot restore the fork. For more information, see «Restoring a deleted repository.» If you delete a private repository, all forks of the repository are deleted.
You can view, sort, and filter the forks of a repository on the repository’s forks page. For more information, see «Understanding connections between repositories.»
About creating forks
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 instructions for forking a repository, see «Fork a repository.» For more information about when you can create forks, and the permission and visibility settings of forks, see «About permissions and visibility of forks.»
Tip: You can use GitHub Desktop to fork a repository. For more information, see «Cloning and forking repositories from GitHub Desktop.»
Forking a repository versus duplicating a repository
If you want to create a new repository from the contents of an existing repository but don’t want to merge your changes to the upstream in the future, you can duplicate the repository or, if the repository is a template, you can use the repository as a template. For more information, see «Duplicating a repository» and «Creating a repository from a template».
Forking a repository is similar to duplicating a repository, with the following differences.
- You can use a pull request to suggest changes from your fork to the upstream repository.
- You can bring changes from the upstream repository to your fork by synchronizing your fork with the upstream repository.
- Forks have their own members, branches, tags, labels, policies, issues, pull requests, discussions, actions, projects, and wikis.
- Forks inherit the restrictions of their upstream repositories. For example, branch protection rules cannot be passed down if the upstream repository belongs to an organization on a GitHub Free plan.
Further reading
- «About collaborative development models»
- «Creating a pull request from a fork»
- Open Source Guides
- GitHub Skills
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.
Git fork. Зачем нужны форки и как с ними работать
Как и в случае с ребейзом, с форками в гите я разобрался не сразу. Вроде ничего особенного там нет, это просто копия репозитория, но натыкаешься на какие-то подводные камни и не сразу понимаешь, как их обойти. Да и вообще, зачем нужны эти форки, тоже осознаешь не сразу. Когда врубаешься, все становится просто, ну это как всегда.
Я не сторонник подхода «чо тут не понимать, тупой штоле» и попробую рассказать человеческими словами, что вообще такое форки, зачем они нужны и как с ними работать. А вы оцените, как получилось. Синьор git девелоперам статья покажется банальщиной, но тем, кто еще не успел обрести такой титул, будет полезно.
Начнем с примера.
Ты работаешь в компании Company в какой-то команде и со своими ребятами пишешь код, например, блога вашего сайта. Рядом сидят ребята из другой команды, которые занимаются админкой. У каждой команды отдельный репозиторий, вы работаете и друг другу не мешаете.
Вам приходит задача — дать возможность разрешать или запрещать комментировать статьи блога отдельным пользователям. Сами вы это сделать не можете. Такие данные о пользователях хранятся не на вашей стороне, а у ребят, занимающихся админкой. У них есть списки пользователей и все данные по ним. А вы тянете эти данные по апи. Прямо микросервисы, все как положено.
Доступа к их репозиторию нет, поэтому идете договариваться. Обсуждаете вместе детали. Так, нужно завести поле в базе, какое-нибудь булево isAllowedComments, соответственно, подготовить миграцию, вывести это поле отдельной колонкой в таблице пользователей, там поставить чекбокс и уметь сохранять это в базу. А еще в апи, которое вы дергаете, нужно добавить в респонсе это самое поле. Вроде немного, ребята говорят, окей, через пару дней сделаем. И на самом деле делают, все хорошо.
Небольшие просьбы вроде этой появляются все чаще. То вам нужно накатить миграцию и разбанить всех пользователей, которые зарегались больше года назад. То в апи в респонсе вам понадобилось количество комментов пользователя. И каждый раз вы идете с такой мелочью к соседям и просите это сделать.
Рано или поздно ребятам из админки это надоедает, потому что у них хватает и своей работы. Они предлагают вам дать права на репозиторий и пробовать такие небольшие задачи делать самим. Говорят, мол, с такой фигней типа добавления поля в респонс вы и сами справитесь. Если что, зовите, поможем. Прав на пуш в мастер, конечно, никто не даст, но свои ветки создавайте и присылайте мердж-реквесты. Мы смотрим, если все хорошо, то мерджим в мастер и выкладываем в прод. Все довольны. И нам работы меньше, и вам не ждать, пока у нас руки дойдут до вашей задачи.
Вы с командой соглашаетесь. Ты клонируешь их репозиторий и пилишь фичи. Примерно так
git clone git@bitbucket.org:company/adminka.git cd adminka git checkout -b vasya/blog-comments . git commit -m 'Added isAllowedComments for users' git push origin vasya/blog-comments
Дальше идешь в битбакеты-гитхабы, в репозиторий админки, делаешь мердж-реквест и ждешь, когда его примут. Обычная схема. Мердж-реквест примерно везде делается одинаково: ищешь кнопку «Создать мердж-реквест» или пулл-реквест, выбираешь свою ветку, затем выбираешь, куда сливать (обычно уже по умолчанию будет мастер) и жмешь «Отправить».
Проходит пара месяцев. Ты случайно замечаешь в репозитории админки ветку petya/update-email. Спрашиваешь ребят из админки, а что за Петя вам коммитит? Те говорят, а, это чувак из отдела емейлов, мы им тоже доступ дали, как и вам. Они тоже приходили к нам по 3 раза в месяц, мы задолбались и теперь с ними работаем по вашей схеме. Ничего, все довольны.
Проходит год. Команд, которые работают по такой схеме, уже десяток. В репозитории появляются ветки
- vasya/blog-user-ban
- petya-ivanov/email_new_field
- email/migration
- blog/hotfix
- petrov/srochno-v-prod
Эти ветки множатся, мерджатся между собой и вообще живут своей жизнью. Называются они как попало, коммиты подписывают кто во что горазд, старые ветки не удаляются после мерджей. Надвигается хаос.
Конечно, ребятам из админки не очень нравится такой мусор в их репозитории. Сначала они пытаются с этим бороться и проводить разъяснительные работы. Пытаются рассказать о правилах приличия в их репозитории. Пишут доку и официальное письмо всем программистам, где все подробно рассказывают. Как именовать ветки, как подписывать коммиты, не забывать удалять старые ветки, не заводить лишние ветки без надобности и прочее.
Это дело хорошее, но бесполезное. В компании полсотни разрабов, у каждого своя команда и свои правила работы с репозиторием. Люди приходят и уходят, эти правила уже никто не помнит, да и всем пофигу, главное фичу сделать, чего там заморачиваться с ветками и коммитами. Пусть у команды админки об этом голова болит. Главное, у нас все хорошо, в своем командном проекте, потому что мы никого к себе не пускаем, ахаха. Поэтому и ветки красиво называются, и коммиты адекватно подписаны. Нас тут 5 человек работают, уж между собой-то договоримся.
А между тем в репозитории админки образуется все больший трэш. То злодеи опять пушат ветки с названиями не по ГОСТу, и тимлида бесят. То сам тимлид с похмелья выдал новому чуваку доступы на пуш в мастер, а тот на радостях запушил миграцию, которая пол-сайта уронила. То по ошибке смерджили petya/hotfix вместо vasya/hotfix. В общем весело всем, кроме ребят из админки.
И вот однажды что-то изменилось. Тебе понадобилось запилить новую фичу и ты привычно набиваешь
git checkout master git pull --rebase origin master git checkout -b vasya/fix-comments . git push origin vasya/fix-comments waiting. Rejected
Опа, что за фигня? Пробуешь еще раз на всякий случай — снова rejected. Пишешь команде админки
- репца, привет, я чот запушить вам не могу, вы права сняли?
- привет, Петя, да, мы убрали права на пуш для всех не-членов нашей команды
- эээ, ну во-первых, я Вася, а во-вторых, как мне теперь делать?
- теперь все мердж-реквесты принимаются из форков
- окей, а на фига это надо? Все равно же в мастер нельзя было запушить, все и так через мердж-реквесты было.
- видишь ли, Вася, у нас тут столько народа, что мы уже не понимаем, кто Вася, а кто Петя, а кто вообще мимо проходил. И в ваших ветках мы тут просто тонем, git fetch невозможно сделать. Мы пытались донести до коллег, что это наш репозиторий и мы просим соблюдать простые правила работы с ним. Но народа много и все решили, что наш проект это помойка, в которой можно делать, что угодно. Все равно ж в мастер не попадет, а там разберутся. Ну и пара инцидентов с неправильно выданными правами. Да, наш косяк, но вас слишком много, чтобы за каждым уследить. Короче, форкайте репозиторий и резвитесь там, как хотите. А нам отправляйте только мердж-реквесты. Вам без разницы, а нам спокойней и в репозитории чище.
- окей, понятно
Понятно-то оно понятно, но ты с форками не работал. Ладно, думаешь, разберешься же, не тупой. Мердж-реквест что ли из форка не отправишь? К тому же ты читал git-scm и знаешь, что форк — это просто копия репозитория. Начинаешь разбираться.
Сначала идешь в гитхаб-битбакет и ищешь там в нужном репозитории кнопку Fork. Обычно она недалеко от кнопки clone. Жмешь на fork и для тебя создается проект. Если исходный был company/adminka.git, то твой будет примерно vasya/adminka.git. Ну или примерно так. Дальше клонируешь его как обычно
git clone git@bitbucket.org:vasya/adminka.git
Естественно, свой форк клонируешь, а не оригинальный. Затем там создаешь привычно ветку и пушишь ее.
git checkout -b blog/new-field . git push origin blog/new-field
Заходишь в гитхаб-битбакет исходного репозитория, жмешь «Создать мердж-реквест», выбираешь свою ветку, она будет называться примерно vasya/adminka/blog/new-field, и ждешь, пока мердж-реквест примут.
Пока все ровно так, как ты привык, ничего нового. Мердж-реквест принимают и все хорошо.
Через месяц тебе нужно сделать еще одну задачу. Ты привычно подтягиваешь мастер и настораживаешься
git pull --rebase origin master From bitbucket.org:vasya/adminka Current branch master is up to date.
За месяц нет новых коммитов в мастере? Да не верю. Идешь в репозиторий админки, смотришь, там до фига коммитов, чуть не каждый день в мастер пушат. В чем дело?
Присматриваешься, откуда ты пулишься и видишь, что это vasya/adminka. Это твой репозиторий, твой форк. Конечно, ты его месяц не трогал и он ничего не знает о новых коммитах в исходном проекте. Их нужно подтянуть и только тогда создавать новую ветку. Можно сделать это так
git pull --rebase git@bitbucket.org:company/adminka.git master
То есть вместо origin указываешь адрес нужного репозитория. И вот теперь-то подтянется мастер именно исходного проекта, а не твоего. А еще лучше сделать так, чтобы не набивать каждый раз длинный адрес
git remote add upstream git@bitbucket.org:company/adminka.git
Теперь у тебя есть origin — твой репозиторий, твой форк, а есть upstream — оригинальный репозиторий. И ты можешь пулиться, указывая сразу upstream
git pull --rebase upstream master
Вот теперь твой мастер актуален, можешь создавать ветку и пушить в репозиторий. Пушить уже в origin, то есть свой, потому что в upstream, исходный, тебе пушить никто не даст. То есть еще раз, пулишь мастер так
git pull --rebase upstream master
а пушишь свою ветку так
git push origin branch-name
По сути это все, что нужно знать о работе с форками. После этого идешь создавать мердж-реквест, твоя ветка уже видна в исходном репозитории. Если ты работал над веткой, а за это время в мастер накидали еще коммитов, то перед отправкой мердж-реквеста стоит отребейзиться от мастера
git checkout master git pull --rebase upstream master git checkout branch-name git rebase master git push -f origin branch-name
Тут можешь делать, как хочешь, твой форк, твои правила. Можешь пушить с форсом, как у меня в примере. Если не хочешь с форсом, то можешь создать отдельную ветку и положить коммит в нее. Как угодно. Главное, чтобы твои коммиты лежали поверх свежих коммитов из мастера. Тогда никто не будет возникать при рассмотрении мердж-реквеста, а ты будешь уверен, что у тебя самые свежие обновления.
Подробнее почитать про ребейз можно здесь — git merge и rebase.
И на этом все. Главное, что нужно сделать, это добавить upstream и четко понимать, в чем его отличие от origin.
С форками можно работать и в компании на полсотни разработчиков, но особенно это популярно в опенсорсе. Возьмите какой-нибудь проект, например, vuejs, у него больше 20 тысяч форков и 3 сотни контрибьюторов. Представьте, что бы творилось в репозитории, пусти всех этих энтузиастов пушить свои правки. А так они спокойно работают со своими форками и присылают пулл-реквесты, не засоряя проект.
Всем удачи. Любите гит, он совсем не страшный 🙂
P.S. Пожалуй, это самая большая статья про форки, которую можно было написать =))
P.P.S. И небольшой опрос напоследок
Все статьи о git
- Курс «Git для начинающих». Видеоуроки
- Git merge vs rebase для начинающих
- Git fork. Что такое форки и как с ними работать
- Как я перестал бояться и полюбил git
- Git bisect. Ищем баги с помощью гита
- 12 причин работать с гитом в командной строке
- Как склеить коммиты в git
- Мой набор команд при работе с git
- Как работать с git в Modx
- Как установить git в Linux Mint
- Визуализация истории git с помощью Gource
Fork a repository
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.
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.
gh repo fork REPOSITORY To create the fork in an organization, use the —org flag.
gh repo fork REPOSITORY --org "octo-org" 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.
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.
- 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.
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.
-
To clone the repository using HTTPS, under «HTTPS», click
.
git clone https://github.com/YOUR-USERNAME/Spoon-Knife $ git clone https://github.com/YOUR-USERNAME/Spoon-Knife > Cloning into `Spoon-Knife`. > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remote: Total 10 (delta 1), reused 10 (delta 1) > Unpacking objects: 100% (10/10), done. To learn more about GitHub CLI, see «About GitHub CLI.»
To create a clone of your fork, use the —clone flag.
gh repo fork REPOSITORY --clone=true
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.
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.
-
To clone the repository using HTTPS, under «HTTPS», click
.
- 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 .. .
$ git remote -v > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) git remote add upstream https://github.com/ORIGINAL_OWNER/Spoon-Knife.git $ git remote -v > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) > upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch) > upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push) 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.
gh repo fork REPOSITORY --remote=true To specify the remote repository’s name, use the —remote-name flag.
gh repo fork REPOSITORY --remote-name "main-remote-repo" 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 “Quickstart for repositories.»»
- 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 «Finding inspiration on GitHub.»
- 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.