Отправьте запрос на перенос на GitHub только для последней фиксации

Я разветкил проект на github и успешно вношу изменения в свой локальный мастер и нажав на начало координат на github. Я хочу отправить запрос на перенос, но хочу включить только последнее коммит. Пользовательский интерфейс запроса на вывод на github.com показывает последние 9 коммитов, и я не знаю, как отфильтровать это.

Я пытался понять, должен ли я создать новую локальную ветвь, проверить это и как-то reset или переупаковать вверх по течению? Затем примените мой последний коммит от моего хозяина по id к новому локальному ветки и используйте его для запроса на растяжение?

Я пытаюсь правильно понять эти понятия и выяснять правильные командные строки, чтобы делать то, что мне нужно.

ОТВЕТЫ

Ответ 1

Вам нужно создать новую ветку и выбрать те коммиты, которые вы хотите добавить в нее.

Примечание: они могут понадобиться перед командами checkout/cherry-pick

git remote add upstream <git repository>

git remote update

git checkout -b <new-branch-name> upstream/master

git cherry-pick <SHA hash of commit>

git push origin <new-branch-name>

После этого вы увидите <new-branch-name> на github, переключитесь на нее и сможете отправить запрос на получение с нужными вам изменениями.

Ответ 2

Создайте новую ветку, начиная с последней фиксации, которая также находится в исходном репозитории:

git branch new-branch origin/master
git checkout new-branch

Затем используйте git cherry-pick, чтобы получить одиночную фиксацию, для которой требуется запрос на pull. Если ветвь с этой фиксацией называется feature, и фиксация, которую вы хотите, является последней фиксацией в этой ветке, это будет

git cherry-pick feature

Предполагая, что этот патч применяется без конфликтов, у вас есть ветка, для которой вы можете выполнить запрос на перенос.

На втором этапе вам нужно решить, что делать с веткой feature. Если вы еще не опубликовали свои изменения в этой ветке, лучшая процедура, вероятно, переустанавливает эту ветвь на новую ветвь (и удаляет последнюю фиксацию, если это не делается автоматически с помощью git rebase).

Ответ 3

Я оказался в ситуации, когда я разветкил вилку и хотел отправить запрос на возврат обратно в исходный проект.

У меня было:

  • orignal_project
  • forked_project (созданный из оригинального проекта на SHA: 9685770)
  • my_fork (создается из разветвленного проекта на SHA: 207e29b)
  • фиксация в моей вилке (SHA: b67627b), которую я хотел бы вернуть обратно к оригинальному проекту

Для этого I:

  • создал новую ветку из SHA, где исходный проект был разветвлен
  • вытащил все из исходного проекта
  • Вишня выбрала коммит, который я хотел отправить в качестве запроса на растяжение.
  • нажал все на github

Команды git были примерно такими:

Затем я выбрал my-feature-request в качестве ветки для моего запроса на перенос в исходный проект.

Ответ 4

Это почти сработало для меня:

git checkout -b upstream upstream/master

git cherry-pick <SHA hash of commit>

git push origin upstream

Единственное различие заключалось в следующем:

git push origin upstream:upstream

Мне нужно было изменить эту последнюю строку, чтобы git push сделал бы ветку вверх по моей репликации GitHub, чтобы я мог сделать PR из нее.

Ответ 5

Я уже сделал коммит, который я хотел бы выделить в качестве запроса на извлечение обратно в текущую ветку.

Итак, я проверил новую ветку

git checkout -b isolated-pull

И здесь, где мое решение отличается от @Kevin Hakanson, так как мне нужно reset эту ветвь на место в истории, которую я хочу отличать от

git reset --hard [sha-to-diff-by]

И вишня - выберите фиксацию, из которой я хочу создать отдельный запрос на растяжение

git cherry-pick [my-isolated-commit-sha]

Наконец, нажмите на пульте дистанционного управления

git push origin isolated-pull

И вытащите запрос, который ши.

Ответ 6

Решение создать новую (временную) ветвь, вишневый выбор и создание запроса на растяжение для этой ветки меня не удовлетворило. Я не хотел менять свой репозиторий, чтобы сделать набор коммитов доступным, поэтому я придумал следующую альтернативу:

Сначала создайте файлы патчей для всех интересующих объектов:

git format-patch -1 <sha>

Если фиксация интереса является последней, вы можете использовать HEAD вместо <sha>.

Теперь вы можете отправить исправления для хранителя исходного репозитория, который может их применять:

git branch new-branch <master or some older commit where the fork diverged>
git checkout new-branch

git am < <the patch>
...

git checkout master
git merge new-branch

Наконец, это должно выглядеть так же, как если бы временная ветвь была объединена по запросу pull, но без этой дополнительной ветки в fork-repository.

Ответ 7

Основываясь на ответе @kevin-hakanson, я написал этот небольшой скрипт bash, чтобы облегчить этот процесс. Он добавит репозиторий в восходящем потоке, если он еще не существует (запрашивая у вас URL), а затем запросит имя новой создаваемой ветки и тег /SHA для фиксации вишни, выбранной для этой ветки. Он проверяет, в какой ветке или коммите вы находитесь, а затем сохраняет все изменения, чтобы вы могли проверить новую ветку. Стратегия слияния сохраняет изменения от вишневого коммита. После отправки новой ветки в origin (предполагается, что это имя вашего удаленного репо), ветвь или фиксация, в которой вы находились до этого, снова извлекается, и ваши предыдущие изменения извлекаются из тайника.

if ! git remote | grep -q upstream; then
    read -p "Upstream git repo URL: " upstream
    git remote add upstream $upstream
    git remote update
fi

read -p "Feature branch name: " feature_branch
# note: giving "master" is the same as giving the SHA it points to
read -p "SHA of commit to put on branch: " sha

current_branch=$(git rev-parse --abbrev-ref HEAD)
if [ "$current_branch" == "HEAD" ]; then
    # detached HEAD; just get the commit SHA
    current_branch=$(git rev-parse --short HEAD)
fi
git stash
git checkout -b $feature_branch upstream/master
git cherry-pick --strategy=recursive -X theirs $sha
git push origin $feature_branch
git checkout $current_branch
git stash pop

(Это сработало для меня в нескольких простых тестах, но я не программист bash или git-эксперт, поэтому дайте мне знать, если есть пропущенные мной случаи, которые можно было бы автоматизировать лучше!)