📖 Теория — Git fork в контексте PR

← К оглавлению урока

⚡ Суть теории

  • Fork = копия репозитория на платформе Git. Ваша, но связана с оригиналом.
  • Issue = задача/обсуждение. Категории: bug, enhancement, documentation.
  • PR = предложение влить ваши изменения в оригинал. 6 шагов: pull → ветка → commit → push → PR → merge.
  • Upstream = оригинальный репозиторий. Синхронизация: git remote add upstream URL → git fetch upstream → git merge upstream/master

Что такое Git fork

Git fork — это операция, которая создаёт копию удалённого репозитория на платформе Git, обычно на сервере, таком как GitHub или GitLab.

Ключевые особенности git fork

  • Создание копии репозитория: git fork позволяет создать копию проекта на платформе Git. Репозиторий, который вы получаете после fork — ваш, можно делать с ним что угодно.
  • Внесение изменений изолированно: Форк позволяет вносить свои изменения в проект, а затем предложить их для интеграции в исходный репозиторий через pull request.
  • Изоляция работы: git fork позволяет изолировать вашу работу от оригинального репозитория, обеспечивая безопасное пространство для экспериментов и изменений.
  • Связь с оригиналом сохраняется: git fork оставляет связь с оригинальным репозиторием, что позволяет обновлять его содержимое, взяв коммиты из оригинального репозитория.
  • Совместная работа: git fork и последующие Pull Requests позволяют командам и сообществам сотрудничать над проектами, предлагая изменения через Pull Request, которые могут быть рассмотрены и внесены в оригинальный проект.

Пример использования git fork

На платформе GitHub перейдите на страницу исходного репозитория (например, https://github.com/aliaskov/bashscripts) и нажмите кнопку «Fork». После этого вы можете склонировать этот репозиторий, так как он теперь ваш, но сохраняет связь с репозиторием, по которому он был форкнут:

git clone https://github.com/YOUR_USERNAME/bashscripts.git
cd bashscripts

Issue в GitHub

В GitHub, issue (задача) представляет собой место для обсуждения, отслеживания и управления работой над конкретной задачей или проблемой в проекте.

Каждая задача (issue) обычно представляет собой определённое изменение, исправление ошибки, предложение новой функциональности или общую проблему, требующую внимания. Каждая задача имеет название и описание, которые помогают понять суть проблемы или предложенного изменения.

Категории задач (метки)

🐛
bug

Ошибка

✨
enhancement

Улучшение

📄
documentation

Документация

Важно: Если репозиторий был форкнут — вкладки Issues не будет! Оставить комментарий можно будет при открытии pull request. Вкладка Issues остаётся только в оригинальном (не форкнутом) репозитории.

Pull Requests в Git и GitHub

Pull Request — это механизм, предоставляемый некоторыми платформами совместной разработки, такими как GitHub, для предложения внесения изменений из одной ветки или форка в другую ветку или репозиторий.

Рабочий процесс pull request (6 шагов)

1. Получить последнюю версию

Вытащить изменения на ваш компьютер — получить самую последнюю версию изменений:

git pull

2. Создать ветку

Создаём новую ветку и называем её «feature_x» и переключаемся на неё:

git checkout -b feature_x

3. Зафиксировать изменения (закоммитить)

Сообщения коммитов важны — они описывают историю вашего кода:

git add <filename>
git add *
git commit -m "Commit message"

3а. Загрузить (запушить) изменения

Ветка не доступна другим пользователям, пока вы не загрузите её в ваш удалённый репозиторий:

git push origin <branch>

3б. Открыть Pull Request

Pull Request инициирует обсуждение ваших коммитов. Можно открыть PR в любой момент:

  • когда у вас мало или вообще нет кода, но вы хотите поделиться скриншотами или общими идеями
  • когда вы застряли и нуждаетесь в помощи или совете
  • когда вы готовы к тому, чтобы кто-то прорецензировал вашу работу

4. Обсудить и прорецензировать код

Как только Pull Request открыт, человек или команда, рецензирующая ваши изменения, может обсудить с автором предложенные изменения, указать на конкретные строки или файлы.

5. Ребейз и тестирование

Как только ваш pull request пройдёт рецензирование, а ветка пройдёт ваши тесты, вы можете перебазировать (rebase) вашу ветку на master. Чтобы воспроизвести все изменения и все коммиты на ветке master или main:

git rebase master
⚠️ Проверить по документации: В современных репозиториях основная ветка часто называется main, а не master. Используйте: 
git rebase main
Команда из лекции — git rebase master (исторически устоявшееся название, актуально для старых репозиториев).

6. Merge — слить ветку с основной

Теперь, когда ваши изменения были проверены, пришло время объединить ваш код с веткой master:

git checkout master
git merge <branch>

Обновление форкнутого репозитория через upstream

Если оригинальный репозиторий продолжает развиваться, ваш форк может отстать. Для синхронизации используется upstream — дополнительный remote, указывающий на оригинальный репозиторий.

Шаги синхронизации (из источника FeatureDevelopmentWithGit)

1. Проверить связи с начальным репозиторием:

git remote -v
# origin  https://github.com/YOUR_USERNAME/JavaCourse.git (fetch)
# origin  https://github.com/YOUR_USERNAME/JavaCourse.git (push)

2. Добавить новый источник (upstream):

git remote add upstream https://github.com/ORIGINAL_AUTHOR/JavaCourse

3. Обновить и получить новые ветки:

git fetch upstream

4. Перейти на ветку master:

git checkout master

5. Слить ветки (возможны конфликты):

git merge upstream/master

6. Залить в свой репозиторий на GitHub:

git push origin master