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

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

Примечание: они могут понадобиться вам перед командами 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, переключитесь на нее и сможете отправить запрос на перенос с желаемыми изменениями.

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

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

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

git cherry-pick feature

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

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

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

Я имел:

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

Для этого я:

1. создал новую ветку из SHA, где был разветвлен исходный проект
2. вытащил все из оригинального проекта
3. вишня выбрала коммит, который я хотел отправить как запрос на перенос
4. отправил все это на github

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

1. git ветка my-feature-request 9685770
2. git checkout мой-запрос-функция
3. git pull https://github.com/original_project/original_project.git
4. git вишневый выбор b67627b
5. git push origin мой-запрос-функция

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

У меня это почти сработало:

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.

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

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

git checkout -b isolated-pull

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

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

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

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

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

git push origin isolated-pull

И запрос на вытягивание, что ши.

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

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

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

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

Основываясь на ответе @ 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, поэтому дайте мне знать, если есть случаи, которые я пропустил, которые можно было бы лучше автоматизировать!)