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, тогда подобные вопросы не возникали бы.
Pull request’ы на GitHub или Как мне внести изменения в чужой проект
По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub’а Fork A Repo и Send pull requests.
Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:
Pull request’ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.
Немного о моделях совместной разработки
Делаем копию репозитория
Рассматривая первую модель разработки, необходимо иметь свою копию изначального репозитория, в которой и будет вестись работа, и изменения из которой и будут предлагаться затем автору изначального репозитория.
В рамках руководства, будем считать, что мы работаем над репозиторием Spoon-Knife пользователя octocat, а ваше имя пользователя — username.
Сделать это очень просто: на странице репозитория имеется кнопочка «Fork», которую и следует нажать. 
После чего, эту свою копию уже можно «стянуть» на свой компьютер:
Склонированный репозиторий имеет одну привязку к удалённому репозиторию, названную origin, которая указывает на вашу копию на GitHub, а не на оригинальный репозиторий, чтобы отслеживать изменения и в нём, вам нужно будет добавить другую привязку, названную, например, upstream.
Делаем работу
Итак, в этой точке мы уже можем править код и делать коммиты. Если вы сделали все предыдущие шаги, чтобы потом вернуть ваши изменения в оригинальный репозиторий, то я настоятельно советую делать всю работу в отдельной тематической ветви разработки. Полезность этого станет ясна на этапе посылки pull request’а. Пускай она будет называться feature.
Вот, теперь творите добро (и пусть оно будет выражаться в коммитах).
Как только вы сделали работу (или её часть), отправьте её в свою копию репозитория на GitHub:
Возвращаем изменения: Pull request
Итак, всё сделано. Вы написали код, он у вас в ветви feature как у вас на компьютере, так и на GitHub’е. Осталось только «заслать» его в оригинальный репозиторий.
Идите на страницу вашей копии репозитория на GitHub, выбирайте ветвь feature и жмите кнопку Pull Request. 
Далее вы попадёте на предпросмотровую страницу, на которой сможете ввести название и описание ваших изменений (название потом попадёт в описание мёрдж-коммита и станет достоянием общественности, учтите это).
Там же вы можете посмотреть, какие коммиты попали в пулл реквест:
А так же общий diff всех изменений в пулл реквесте:
По умолчанию, пулл реквесты считаются основанными на самой часто интегрируемой ветви родительского репозитория. В этом случае username/Spoon-Knife был скопирован с octocat/Spoon-Knife, так что pull request считается основанным на ветке master репозитория octocat/Spoon-Knife. В большинстве случаев, это будет корректно, но если не так, то вы можете нажать на кнопку «Change Commits»
Вы попадёте в форму выбора базовой и исходной ветвей:
Слева выбираете в какую ветку будут вливаться изменения в родительском репозитории, справа — какие изменения будут браться с вашего репозитория. По примеру: справа octocat/Spoon-Knife/master, слева username/Spoon-Knife/feature. Здесь вы можете указывать не только ветки, но так же теги и id отдельных коммитов в соответствующем репозитории.
ВАЖНО: Договоритесь с владельцем «родительского» репозитория, в какую ветку будете вливать изменения (он может написать это в README)
Изменение базового репозитория меняет и список людей, кто получит уведомление о пулл реквесте. Каждый, кто имеет право «на запись» в базовый репозиторий, получит письмо и увидит уведомление на главной GitHub’а, в следующий раз, как на него зайдёт.
Как только список коммитов вас удовлетворит, нажмите кнопку Update Commit Range.
Когда вы ввели название и описание и перепроверили список коммитов и изменения в файлы, попавшие в пулл реквест, нажмите кнопку Send pull request. Пулл реквест будет создан незамедлительно.
Что дальше?
Следите за вашим пулл-реквестом. Что прокомментируют люди, что скажет мэйнтэйнер, примет или нет ваш пулл реквест.
Когда ваш pull request примут, не забудьте слить изменения в свой репозиторий (или удалить его, если больше не нужен):
Так же можно удалить ветку, в которой велась разработка:
Что следует делать, если работа заняла большое время и оригинальный репозиторий успел уйти вперёд?
Можно просто влить изменения из оригинального репозитория к себе:
Однако хозяину оригинального репозитория или, может быть, даже вам, не понравится наличие мёрж-коммитов и коммитов из master’а в списке коммитов на пулл. В таком случае вам стоит воспользоваться git rebase.
Прочитать про то, как работает rebase можно в официальном руководстве. Там имеются и очень понятные иллюстрации. Так же есть статья в помощи GitHub.
ВНИМАНИЕ: Пожалуйста, учтите, что git rebase меняет id коммитов! Поэтому, все действия с этой командой стоит выполнять только на локальном репозитории, до того, как эти коммиты станут общедоступны, т.е. до того, как вы их push’нули на гитхаб.
Если вы хозяин: Как принять pull request
Если пулл реквест удовлетворяет всем условиям, то кто-либо с правом «на запись» (т.е. может сделать push) в целевой репозиторий, должен принять pull request одним из многих методов. Ниже описаны три наиболее популярных метода:
Auto Merge (автослияние)
Во многих случаях можно попросить github автоматически принять пулл реквест, используя большую зелёную кнопку Merge Pull Request, которая сама вольёт изменения, создаст мёрж-коммит и закроет пулл реквест.
Подробнее можно почитать в этом хабратопике: Кнопка слияния на GitHub.
Fetch and Merge (скачать и слить)
Основной метод вливания изменений. Он требует добавления remote, ведущего к репозиторию человека, отправившего pull request, скачивания изменений с этого репозитория, объединения нужной ветви, исправления конфликтов и выгрузки обновлённой ветви обратно в исходный репозиторий:
Patch and Apply (пропатчить и принять)
Предыдущий метод работает хорошо, когда вы работаете в команде или постоянно принимаете изменения от одной и той же группы людей. Другой метод немного быстрее в единичных случаях при использовании git-am.
Закрытие пулл реквеста
Запросы на пулл автоматически закрываются, когда запрошенные коммиты вливаются в репозиторий назначения. При этом генерируется событие, информирующее всех участников разработки, что пулл реквест был принят и влит в основную ветвь.
Так же возможно вручную закрыть пулл реквест в случае, если он был отклонён. Иногда это необходимо в случаях, когда изменения были приняты с помощью git-cherry-pick или другого механизма, который не позволяет обнаружить факт слияния (merge).
Cloning and forking repositories from GitHub Desktop
In this article
You can use GitHub Desktop to clone and fork repositories that exist on GitHub.
About local repositories
Repositories on GitHub are remote repositories. You can clone or fork a repository with GitHub Desktop to create a local repository on your computer.
You can create a local copy of any repository on GitHub that you have access to by cloning the repository. If you own a repository or have write permissions, you can sync between the local and remote locations. For more information, see «Syncing your branch.»
When you clone a repository, any changes you push to GitHub will affect the original repository. To make changes without affecting the original project, you can create a separate copy by forking the repository. You can create a pull request to propose that maintainers incorporate the changes in your fork into the original upstream repository. For more information, see «About forks.»
When you try to use GitHub Desktop to clone a repository that you do not have write access to, GitHub Desktop will prompt you to create a fork automatically. You can choose to use your fork to contribute to the original upstream repository or to work independently on your own project. Any existing forks default to contributing changes to their upstream repositories. You can modify this choice at any time. For more information, see «Managing fork behavior».
You can also clone a repository directly from GitHub or GitHub Enterprise. For more information, see «Cloning a repository from GitHub to GitHub Desktop».
Cloning a repository
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.
Forking a repository
If you clone a repository that you do not have write access to, GitHub Desktop will create a fork. After creating or cloning a fork, GitHub Desktop will ask how you are planning to use the fork.
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.
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.
Managing fork behavior
You can change how a fork behaves with the upstream repository in GitHub Desktop.
Click Fork behavior, then select how you want to use the fork.
Click Save.
Creating an alias for a local repository
You can create an alias for a local repository to help differentiate between repositories of the same name in GitHub Desktop. Creating an alias does not affect the repository’s name on GitHub. In the repositories list, aliases appear in italics.
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
Как сделать первый пул-реквест на GitHub
Перевод статьи «How to make your first pull request on GitHub».
Что такое форк?
Когда нам нравится чей-то репозиторий и мы хотели бы иметь его в собственном аккаунте на GitHub, мы делаем форк («вилку») этого репозитория, чтобы иметь возможность работать с ним отдельно.
Когда мы делаем форк репозитория, мы получаем экземпляр всего репозитория, со всей его историей. После форка мы можем делать с ним все, что угодно: оригинальная версия при этом не будет задета.
Что такое пул-реквест?
Пул-реквесты нужны. Когда мы хотим принять участие в групповой разработке проектов с открытым исходным кодом.
Например, пользователь Павел делает форк репозитория ThanoshanMV (автора статьи, — прим. перев.) и вносит изменения в свой экземпляр. После этого Павел отсылает пул-реквест ThanoshanMV, который может либо принять его, либо отклонить. По сути это что-то вроде письма «Не будете ли вы так любезны, уважаемый ThanoshanMV, внести мои изменения в свой оригинальный репозиторий?»
Как можно стать контрибьютором проекта?
Участие в проекте с открытым исходным кодом не обязательно предполагает работу именно с кодом. Контрибьютором (участником) можно стать и другими способами, некоторые из них описаны ниже.
Давайте создадим наш первый пул-реквест!
1. Форк репозитория
Чтобы сделать форк репозитория, нужно нажать кнопку «Fork» в верху страницы. Таким образом вы создадите экземпляр всего этого репозитория в своем аккаунте.
2. Клонирование репозитория
Когда репозиторий уже есть в вашем аккаунте, вы можете клонировать его на свою машину и в дальнейшем работать с ним локально.
Чтобы клонировать репозиторий, нажмите кнопку «clone» и скопируйте ссылку.
Откройте терминал и запустите следующую команду. С ее помощью репозиторий будет клонирован на вашу машину.
Теперь у вас есть копия ветки master основного онлайн-репозитория проекта.
Переходим в клонированную директорию:
3. Создание ветки
При работе с репозиторием хорошей практикой считается создание отдельной ветки для внесения изменений, причем это не зависит от размеров проекта.
Имя ветки должно быть коротким и отражать те изменения, которые вы вносите.
Создадим ветку при помощи команды git checkout:
4. Внесение изменений и коммит
Внесите необходимы изменения в проект и сохраните их. Затем запустите команду git status: вы увидите внесенные изменения.
Добавьте эти изменения в только что созданную ветку при помощи команды git add:
Теперь вы можете сделать коммит этих изменений при помощи команды git commit:
5. Отправка изменений на GitHub
Чтобы отправить изменения на GitHub (сделать push), нужно определить имя удаленного репозитория.
Имя данного удаленного репозитория — «origin».
После определения имени можно безопасно отправить изменения на GitHub.
6. Создание пул-реквеста
Перейдите в свой репозиторий на GitHub. Там есть кнопка «Compare & pull request» — кликните ее.
Введите необходимые детали относительно того, что именно вы сделали (чтобы поставить ссылку на issues, возмользуйтесь знаком «решетки»). После этого можно нажать кнопку подтверждения внизу.
Поздравляю! Вы создали свой первый пул-реквест. Если его примут, вы получите уведомление по электронной почте.
7. Синхронизация вашего форка с основной веткой
Прежде чем создавать пул-реквест в оригинальный репозиторий, нужно синхронизировать свой экземпляр этого репозитория с оригинальным.
Даже если вы не собираетесь отправлять пул-реквест в оригинальный репозиторий, все равно лучше синхронизироваться с ним. Со времени создания форка в оригинальном репозитории могли добавиться новые фичи, а также могли быть исправлены какие-то баги.
Проделайте следующие действия, чтобы обновить свой репозиторий и внести соответствующие изменения в свою ветку master:
1. Для начала, проверьте, в какой ветке вы находитесь.
Вы получите список всех веток, причем активная будет подсвечена зеленым.
2. Переключитесь в ветку master.
3. Добавьте оригинальный репозиторий в качестве upstream-репозитория.
Чтобы вытащить изменения из оригинального репозитория и перенести их в свою версию, нужно добавить оригинальный git-репозиторий в качестве upstream-репозитория.
Здесь [HTTPS] это url, который нужно скопировать из основного репозитория.
4. Fetch репозитория
Заберите (fetch) все изменения из оригинального репозитория. Коммиты, сделанные в оригинальном репозитории, будут сохранены в локальной ветке под названием upstream/master.
5. Слейте изменения
Слейте (merge) изменения из upstream/master с вашей локальной веткой master. Таким образом главная ветка вашего форка репозитория синхронизируется с upstream-репозиторием без потери ваших локальных изменений.
6. Отправьте изменения на GitHub
На этом этапе ваша локальная ветка синхронизирована с веткой master оригинального репозитория. Если вы хотите обновить свой GitHub-репозиторий, нужно отправить в него изменения.
Примечание. После синхронизации ветки master вашего форка вы можете при желании удалить remote. Но в будущем вам еще придется обновлять/синхронизировать ваш репозиторий, поэтому лучше его сохранить.
8. Удаление ненужной ветки
Ветки создаются с какими-то конкретными целями. Когда цель достигнута, необходимость в ветке отпадает, поэтому ее можно удалить.
Вы можете удалить и версию этой ветки на GitHub.
Итоги
GitHub это мощный инструмент для контроля истории версий. Каждый может стать контрибьютором проекта с открытым исходным кодом. Делается это путем отправки пул-реквестов.
Чтобы стать контрибьютором, не обязательно писать код: есть и другие способы принять участие в проекте.
Наконец, я хотел бы также сказать, что не стоит переживать, если ваши пул-реквесты отклонят. Мейнтейнеры тратят много времени на улучшение своих проектов и они, безусловно, лучше знают эти проекты, чем вы. Поэтому не стоит переживать, если они решат не вливать в свой проект ваши изменения.
