Fork: своя копия чужого репозитория
Обновлено 31 июля 2026 г.
Fork - это копия чужого репозитория, сделанная на твоём аккаунте GitHub, куда у тебя есть право писать.
Разница с клоном в том, где появляется копия. git clone забирает проект к тебе на диск, fork создаёт копию на сервере под твоим именем. Одно не заменяет другое: обычно делают и то и другое, сначала форк, потом клон своего форка.
Нужен он там, где писать в оригинал тебе не дадут. Открытый проект видят все, но право отправлять коммиты есть у мейнтейнеров, и твой push в чужой репозиторий закончится отказом. В своём форке ты хозяин, а готовую правку предлагаешь через pull request.
Полный цикл
- Нажми Fork на странице оригинала. Через несколько секунд копия появится по адресу
github.com/твой-логин/some-project. - Склонируй свой форк, а не оригинал.
- Добавь оригинал вторым удалённым репозиторием под именем
upstream. - Заведи ветку под задачу, поработай, отправь ветку в свой форк.
- Открой pull request. GitHub знает, что репозиторий - форк, и сам подставит base оригинала и compare твоей ветки. Проверь эту пару глазами и нажми Create pull request.
Второй и третий шаги в терминале:
$ git clone git@github.com:my-login/some-project.git
$ cd some-project
$ git remote add upstream git@github.com:original-owner/some-project.git
$ git remote -v
origin git@github.com:my-login/some-project.git (fetch)
origin git@github.com:my-login/some-project.git (push)
upstream git@github.com:original-owner/some-project.git (fetch)
upstream git@github.com:original-owner/some-project.git (push)origin - твой форк, туда ты пишешь. upstream - оригинал, оттуда забираешь свежее. Имя upstream принято по договорённости, git на него никак не завязан, разбор связей есть в статье git remote.
Четвёртый шаг ничем не отличается от работы в собственном проекте:
$ git switch -c fix-typo-in-readme
$ git commit -am "Fix typo in the install section"
$ git push -u origin fix-typo-in-readmeПодтянуть свежее из оригинала
Форк не обновляется сам. Пока ты возишься со своей правкой, оригинал уезжает вперёд, и подтягивать его приходится вручную:
$ git fetch upstream
From github.com:original-owner/some-project
* [new branch] main -> upstream/main
$ git switch main
$ git merge upstream/main
Updating 19ab236..efab511
Fast-forward
README.md | 1 +
1 file changed, 1 insertion(+)Дальше обычный git push отправит обновлённый main в форк. На странице форка то же самое делает кнопка Sync fork.
Частые ошибки
Работать прямо в main своего форка. Пока задача одна, всё выглядит нормально, а на второй начинается путаница: обе правки лежат в одной ветке, и pull request утащит в оригинал обе сразу. Заводи ветку под каждую задачу, main в форке держи чистой копией оригинала.
Забыть про upstream. Через месяц твоя копия отстаёт на сотню коммитов, ветка отведена от старого состояния, и вместо одной аккуратной правки получается разбор конфликтов по всему проекту. Делай git fetch upstream перед тем, как отводить новую ветку.