git remotes

Fork Workflow

Работа с форками на GitHub — полный цикл от клонирования до синхронизации с upstream

Описание

Fork Workflow — стандартный способ вносить вклад в open-source проекты и работать в командах с ограниченным доступом к основному репозиторию. Форк — это полная копия репозитория в вашем аккаунте GitHub/GitLab. Вы работаете в своём форке независимо, а когда готово — открываете Pull Request в оригинальный репозиторий.

В этом workflow появляются два remote: origin — ваш форк (куда вы пушите) и upstream — оригинальный репозиторий (откуда вы получаете обновления). Такая схема позволяет работать независимо от основной кодовой базы и при этом регулярно синхронизироваться с ней.

Fork Workflow применяется везде: от крупнейших open-source проектов (Linux kernel, Python, React) до корпоративных репозиториев, где разработчики не имеют write-доступа к основному репо. Знание этого workflow — обязательный навык для любого разработчика.

Полный workflow по шагам

1

Форкнуть репозиторий на GitHub

Нажмите кнопку «Fork» в интерфейсе GitHub. GitHub создаст копию в вашем аккаунте.

# Результат: https://github.com/YOUR-USERNAME/original-repo
2

Клонировать форк локально

Клонируем наш форк (не оригинал!) на локальную машину.

git clone git@github.com:YOUR-USERNAME/original-repo.git cd original-repo # Git автоматически настроил origin на ваш форк git remote -v # origin git@github.com:YOUR-USERNAME/original-repo.git (fetch) # origin git@github.com:YOUR-USERNAME/original-repo.git (push)
3

Добавить upstream

Добавляем оригинальный репозиторий как remote с именем upstream.

git remote add upstream git@github.com:ORIGINAL-OWNER/original-repo.git # Проверить git remote -v # origin git@github.com:YOUR-USERNAME/original-repo.git (fetch) # upstream git@github.com:ORIGINAL-OWNER/original-repo.git (fetch)
4

Создать feature-ветку

Никогда не работайте напрямую в main. Создайте ветку для каждой задачи.

git checkout -b feature/add-dark-mode # или (Git >= 2.23) git switch -c feature/add-dark-mode
5

Работа и коммиты

Вносите изменения, коммитьте, работайте как обычно.

git add . git commit -m "feat: add dark mode toggle to navbar" git add . git commit -m "test: add dark mode tests"
6

Синхронизироваться с upstream перед push

Загрузить свежие изменения из оригинала и перебазировать на них вашу ветку.

git fetch upstream git rebase upstream/main # Разрешить конфликты если есть # git rebase --continue
7

Push ветки в свой форк

git push -u origin feature/add-dark-mode # После rebase может понадобиться force push git push --force-with-lease origin feature/add-dark-mode
8

Открыть Pull Request на GitHub

GitHub покажет кнопку «Compare & pull request». Откройте PR из вашей ветки в main оригинального репозитория.

Ключевые команды workflow

Команда Назначение
git clone <url> Склонировать форк на локальную машину. URL берётся со страницы вашего форка на GitHub (кнопка «Code»).
git remote add upstream <url> Добавить оригинальный репозиторий как upstream. Это позволит получать обновления от авторов проекта.
git fetch upstream Загрузить актуальное состояние оригинала без слияния. Безопасная операция, ничего не меняет в рабочих ветках.
git rebase upstream/main Перебазировать текущую ветку поверх свежего upstream/main. Сохраняет линейную историю, ваши коммиты «переигрываются» поверх новых коммитов из upstream.
git merge upstream/main Альтернатива rebase: влить upstream/main через merge-коммит. Менее чистая история, но без риска конфликтов при rebase.
git push -u origin <branch> Опубликовать ветку в своём форке и установить tracking. После этого git push без аргументов работает для этой ветки.
git push --force-with-lease Force push после rebase. Перезаписывает историю ветки в форке, сохраняя при этом защиту от случайного затирания чужих коммитов.
git remote -v Проверить настроенные remotes. В правильно настроенном fork workflow должны быть и origin (форк), и upstream (оригинал).
git log upstream/main..HEAD Показать ваши коммиты, которых ещё нет в upstream. Удобно перед открытием PR — видно, что именно войдёт в запрос.
git diff upstream/main Сравнить текущее состояние ветки с upstream/main. Хороший способ проверить изменения перед PR.

Паттерны использования

Быстрая настройка после fork

# 1. Склонировать форк
git clone git@github.com:you/project.git
cd project

# 2. Добавить upstream
git remote add upstream git@github.com:original/project.git

# 3. Проверить
git remote -v

Синхронизация main с upstream

# Переключиться на main
git checkout main

# Получить обновления
git fetch upstream

# Обновить локальный main
git merge upstream/main --ff-only

# Обновить форк на GitHub
git push origin main

Обновить feature-ветку перед PR

# Получить свежий upstream
git fetch upstream

# Перебазировать feature-ветку
git rebase upstream/main

# Разрешить конфликты и продолжить
# git add file.txt && git rebase --continue

# Force push обновлённой ветки
git push --force-with-lease origin feature/my-feature

Посмотреть PR коллеги локально

# Добавить форк коллеги как remote
git remote add colleague git@github.com:colleague/project.git

# Получить его ветку
git fetch colleague feature/his-work

# Переключиться и проверить
git checkout -b review/his-work colleague/feature/his-work

Начать новую задачу после merge PR

# После того как PR принят
# Обновить main
git checkout main
git fetch upstream
git merge upstream/main --ff-only
git push origin main

# Удалить старую feature-ветку
git branch -d feature/old-feature
git push origin --delete feature/old-feature

# Начать новую
git checkout -b feature/next-task

Cherry-pick конкретного коммита из upstream

# Взять один коммит из upstream
git fetch upstream
git log upstream/main --oneline -10

# Применить нужный коммит
git cherry-pick abc1234

Советы и подводные камни

Синхронизируйтесь перед каждым PR: Перед открытием Pull Request всегда делайте git fetch upstream && git rebase upstream/main. PR, который базируется на актуальном upstream, с большей вероятностью будет принят без конфликтов и показывает, что вы уважаете время мейнтейнеров.
Один PR — одна задача: Не смешивайте несколько несвязанных изменений в один PR. Создавайте отдельную feature-ветку для каждой задачи. Маленькие, сфокусированные PR рассматриваются быстрее и реже порождают конфликты.
Не коммитьте прямо в main форка: Работайте только в feature-ветках. Если вы закоммитили в main, а потом пытаетесь синхронизироваться с upstream через merge, история форка станет запутанной и создаст проблемы при будущих PR.
upstream — только fetch, никогда push: Никогда не пытайтесь пушить в upstream без прав доступа — это завершится ошибкой. Но даже если у вас есть права, работайте через форк и PR — это позволяет мейнтейнерам проверить изменения перед слиянием.