Запрос на извлечение без разветвления?


105

Вот шаги по добавлению кода из темы « Как мне внести свой вклад в чужой код в GitHub? »

  1. Форк проекта
  2. Сделайте один или несколько хорошо прокомментированных и чистых коммитов в репозиторий. Вы можете создать здесь новую ветку, если вы изменяете более одной детали или функции.
  3. Выполните пул-реквест в веб-интерфейсе github.

Можно ли сделать запрос на перенос без разветвления репо?

Очень грустно видеть в моем аккаунте более 20 репозиториев, которые были разветвлены для некоторых запросов на вытягивание. У них тогда нет активности и ноль звезд / подписчиков. Похоже, я просто копирую чей-то код на черный день.


Зачем тебе это нужно?

3
Хороший вопрос. Также неясно, обновлять эти 20 репозиториев оригиналом (или удалять их).
— Кори Аликс,

Ответы:


95

Если у вас нет доступа для создания веток в этом репозитории, невозможно создать запрос на перенос без разветвления .


8
Не могли бы вы объяснить, как можно создать запрос на перенос, если у вас ДЕЙСТВИТЕЛЬНО есть доступ к веткам в этом репозитории?
— bolinfest

13
На GitHub есть хорошее руководство по этому поводу: help.github.com/articles/creating-a-pull-request
— Райан

2
Просто напоминание о том, что может быть не так ясно для всех. Вам нужно создать вилку для каждого репозитория, в который вы вносите вклад ... но создание веток в вашей вилке позволяет вам работать с одним более чем одним PR одновременно для репозитория восходящего потока. Вам не нужно 20 форков из одного репо, чтобы внести 20 PR.
— JulioHM

24

Как только ваши запросы на вытягивание будут приняты, вы можете безопасно удалить репо .

После этого просто клонируйте прямо из исходного репозитория восходящего потока.

Если у вас есть другие запросы на вытягивание, вы должны сделать их в их собственной соответствующей ветке, что означает, что вы можете безопасно удалить ветку, созданную для управления принятым запросом на перенос (например, « Мой запрос на перенос был объединен, что делать следующий? ")


2
К вашему сведению, github недавно добавил кнопку в объединенные запросы на вытягивание, чтобы упростить (и интуитивно) удалить ветку запроса на вытягивание: github.com/blog/1335-tidying-up-after-pull-requests
— Дэвид М.

10

По определению, запрос на перенос включает вилку, если у вас нет доступа к целевому репозиторию для фиксации. Однако вы можете сделать пару вещей:

  1. Если же есть доступ для фиксации, создать ветку и сделать запрос тянуть против нового филиала.
  2. Опубликуйте свой патч в теле вопроса. На самом деле это не способ GitHub, но он определенно работает.
  3. Разветвите репозиторий, создайте запрос на перенос, а затем удалите вилку после объединения или отклонения запроса на перенос.

Если вы просто пытаетесь избегать хранения репозиториев, которые вы не используете активно, я лично предлагаю вариант №3. Он соответствует принятому рабочему процессу GitHub, не загромождая вашу панель инструментов.


Вероятно, лучше всего указать здесь: 4. Поддерживайте вторую учетную запись Github, чтобы иметь дело с этими сценариями запроса на вытягивание и забывания. Не имеет значения, есть ли в этой учетной записи 20 неактивных репозиториев, поскольку это не основная учетная запись.
— tanius 01

7

github поддерживает модель общего репозитория

Модель общего репозитория более распространена среди небольших команд и организаций, сотрудничающих над частными проектами. Всем предоставляется push-доступ к единому общему репозиторию, а ветки тем используются для изоляции изменений.

Запросы на вытягивание особенно полезны в модели Fork & Pull, потому что они предоставляют способ уведомить разработчиков проекта об изменениях в вашей вилке. Однако они также полезны в модели общего репозитория, где они используются для инициирования проверки кода и общего обсуждения набора изменений перед объединением в основную ветку.


5
Обратите внимание, как это не объясняет, как создать запрос на вытягивание в этой модели.
— bolinfest

0

Вам все еще нужен этот однострочник: hub fork;git push -u $GIT_USER HEAD;hub pull-request

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.