Fork vs clone

Два слова, легко спутать. Это разные операции, на разных уровнях.

Clone - локальная копия

git clone git@github.com:original/repo.git

Что делает: создаёт локальную копию репо на твоей машине. Удалённый репозиторий остаётся прежним. У тебя есть всё: история, ветки, теги. Но writes (push) - только если у тебя есть права в original/repo. Если нет - git push откажется.

Подробности - в clone.

Fork - копия на сервере

Делается через UI форджи: кнопка «Fork» на GitHub/GitLab/Bitbucket. Что происходит: GitHub создаёт под твоим аккаунтом полную копию репо:

Было:      github.com/original/repo

Стало:     github.com/original/repo

           github.com/you/repo        ← твоя копия

Это не локально. Это серверная операция: на GitHub теперь два репозитория, твой fork и оригинал. Ты полный владелец своего fork'а - можешь push'ить, делать ветки, удалять, что угодно. На оригинал твой fork никак не влияет.

Типичный flow в open-source

1. Fork (на GitHub UI):    original/repo → you/repo

2. Clone своего fork'а:    git clone git@github.com:you/repo.git

3. (опционально) добавить оригинал как upstream - см. [[upstream-vs-origin]]

4. Делать изменения, push в свой fork

5. На GitHub открыть PR: you:feature → original:main

Это и есть «fork-flow». В большинстве крупных open-source проектов внешним контрибьюторам нельзя пушить напрямую в оригинал - у них просто нет прав. Fork обходит это: у тебя есть права на свой fork, в нём ты делаешь работу, оригинал получает изменения только через PR.

Когда fork НЕ нужен

Если ты член команды оригинала с правами writer'а - fork не нужен. Цикл проще:

1. Clone оригинала

2. Branch внутри, push в оригинал

3. PR из ветки в main, всё внутри одного репо

В небольших командах работают именно так. Fork - это обход отсутствия прав, не «правильный способ».

Чем fork отличается от clone технически

Один fork - одна копия. Если хочешь несколько - нужен другой аккаунт или организация.

Sync fork с upstream

Со временем оригинал уходит вперёд, твой fork отстаёт. Sync:

Через UI: кнопка «Sync fork» на странице fork'а в GitHub. Сделает fast-forward, если возможно.

Через CLI:

git fetch upstream

git switch main

git rebase upstream/main

git push origin main

CLI работает в любом setup'е, UI - только когда у вас обычный flow. Подробнее в upstream-vs-origin.

Когда fork против clone - это решение

• Хочешь править свой проект: clone, ничего больше не надо.
• Хочешь править чужой open-source: fork → clone своего форка.
• Хочешь использовать чужой код, не править: clone. Fork - лишний шаг.
• Хочешь сделать свою версию чужого проекта (например, после разногласий с автором): fork (можешь использовать как hard fork, развивать независимо).

Подводные камни

• «Я форкнул, теперь push в оригинал». Нет: fork - это твоя копия, push в неё. В оригинал - через PR. См. upstream-vs-origin.
  • Fork устаревает. Через год без sync - много дней позади оригинала. Перед PR - обязательно fetch upstream + rebase.
  • Fork удалён с GitHub - все ветки и issue с ним. PR из него в оригинал тоже превратится в «invalid». Делай backup, если на форке есть незаслитые ветки.
• Private fork публичного репо. На GitHub нельзя сделать fork публичного в приватный напрямую - нужен Import через UI или зеркалирование (mirror push). С GPL это легально, пока ты держишь модификации у себя: GPL накладывает обязанности (раскрыть исходник
  • сохранить копилефт) только в момент распространения бинаря или исходника наружу, личное использование не ограничено.