Ответ уже опубликован, но чтобы не допустить повторения такой вещи:
GitHub - просто Git-Host для многих и работает как любой другой (GitLab, Gogs, ...).
Я рекомендую изучать Git (а не «изучать GitHub»). Git - действительно хороший SCM, но это не тривиально. Лично мне всегда нравится рекомендовать "Think Like A Git", imho, лучшее вступление.
Если вы клонируете репо, вы на самом деле делаете много вещей:
- Инициализировать новый локальный репозиторий git
- Добавьте удаленный (URL), с которого вы клонируете
- Получить данные (коммиты)
- Извлечь ветку (часто называемую master, но это просто соглашение) с той же историей фиксации, что и соответствующая ветка на удаленном компьютере.
Если вы разветвляете репо, все, что делает GitHub, - это копирует раздвоенный пульт в новое пространство имен под вашей учетной записью. Теперь вы можете клонировать репо, на которое у вас есть разрешение на запись.
Теперь вы хотите тянуть-запрос. Вытягивающий запрос на GitHub (это особенность, специфичная для GitHub, хотя другие серверы часто реализуют аналогичные функции) работает так, как вы указываете исходную комбинацию remote / branch и целевое remot / branch.
Из-за этого считается хорошим стилем создать новую ветку в вашем репо, которая будет ветвиться с фактической веткой, в которую вы хотите объединиться позже, и посвятить ее фиксации только для pull-запроса. Я часто использую схему именования, например "PRQ_myfeature".
С помощью этого метода вы все еще можете позволить своей основной ветви "отслеживать" основную ветку исходного пульта. Чтобы сделать это, используйте «$ git remote add some_fancy_name URL». Теперь вы можете выбрать и перетащить оригинального мастера в свой, чтобы отслеживать изменения.
Это также позволяет вам регулярно перебазировать ветку pull-запроса и проверять наличие конфликтов.
Это означает, что автор может просто без проблем объединить ваш pull-запрос, что делает его более вероятным, что они это сделают;)