git 在 GitHub 上发送拉取请求以获取最新提交

Send a pull request on GitHub for only latest commit

提问by Kevin Hakanson

I forked a project on github and am successfully making changes to my local master and pushing to origin on github. I want to send a pull request, but only want to include the last commit. The pull request UI on github.com shows the last 9 commits and I don't know how to filter that down.

我在 github 上创建了一个项目，并且成功地对我的本地 master 进行了更改并推送到 github 上的 origin。我想发送拉取请求，但只想包含最后一次提交。github.com 上的 pull request UI 显示了最近的 9 个提交，我不知道如何过滤它。

I was trying to understand if I should create a new local branch, check that out and somehow reset or rebase to upstream? Then apply my last commit from my master by id to the new local branch and use that for the pull request?

我试图了解我是否应该创建一个新的本地分支，检查它并以某种方式重置或重新设置到上游？然后将我的 master 通过 id 的最后一次提交应用到新的本地分支并将其用于拉取请求？

I'm trying to get the concepts right and figure out the right command lines to do what I need.

我正在努力使概念正确并找出正确的命令行来做我需要的事情。

回答by Kevin Hakanson

You need to basically create a new branch & cherry-pickthe commits you want to add to it.

您基本上需要创建一个新分支并挑选要添加到其中的提交。

Note: you might need these before the checkout/cherry-pick commands

git remote add upstream <git repository>

git remote update

注意：在 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>

Afterwards, you will see <new-branch-name>branch on github, switch to it and can submit the pull request with the changes you want.

之后，您将<new-branch-name>在 github 上看到分支，切换到它并可以提交带有您想要的更改的拉取请求。

回答by Lars Noschinski

Create a new branch starting from the latest commit, which is also in the origin repository:

从最新提交开始创建一个新分支，该分支也在源存储库中：

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

Then use git cherry-pickto get the single commit you want the pull request for. If the branch with this commit is called featureand the commit you want is the latest commit in this branch, this will be

然后用于git cherry-pick获取您想要拉取请求的单个提交。如果具有此提交的分支被调用feature并且您想要的提交是此分支中的最新提交，则这将是

git cherry-pick feature

Assuming this patch applies without conflict, you got now a branch for which you can do your pull request.

假设此补丁适用于没有冲突的情况，您现在有一个分支，您可以为其执行拉取请求。

In a second step, you now need to decide what to do with your featurebranch. If you haven't published your changes on this branch yet, the best procedure is probably rebasing this branch upon new-branch (and removing the last commit, if this is not done automatically by git rebase).

第二步，您现在需要决定如何处理您的feature分支。如果你还没有在这个分支上发布你的更改，最好的程序可能是在 new-branch 上重新建立这个分支（并删除最后一次提交，如果这不是由 自动完成的git rebase）。

回答by John Naegle

I ended up in a situation where I had forked a fork and wanted to submit a pull request back to the original project.

我最终遇到了一种情况，我已经分叉了一个分支，并希望将拉取请求提交回原始项目。

I had:

我有：

• orignal_project
• forked_project (created from original project at SHA: 9685770)
• my_fork (created from forked project at SHA: 207e29b)
• a commit in my fork (SHA: b67627b) that I wanted to submit back to original project

• 原始项目
• forked_project（从 SHA 的原始项目创建：9685770）
• my_fork（从 SHA 的分叉项目创建：207e29b）
• 我想提交回原始项目的 fork (SHA: b67627b) 中的提交

To do this, I:

为此，我：

1. created a new branch from the SHA where the original project was forked
2. pulled all from the original project
3. cherry picked the commit I wanted to submit as a pull request
4. pushed it all up to github

1. 从原始项目分叉的 SHA 创建了一个新分支
2. 从原始项目中提取所有内容
3. 樱桃选择了我想作为拉取请求提交的提交
4. 全部推送到 github

The git commands were something like:

git 命令类似于：

1. git branch my-feature-request 9685770
2. git checkout my-feature-request
3. git pull https://github.com/original_project/original_project.git
4. git cherry-pick b67627b
5. git push origin my-feature-request

1. git 分支我的功能请求 9685770
2. git checkout 我的功能请求
3. git pull https://github.com/original_project/original_project.git
4. git 樱桃挑选 b67627b
5. git push origin 我的功能请求

Then I picked my-feature-request as the branch for my pull request to the original project.

然后我选择了 my-feature-request 作为我对原始项目的拉取请求的分支。

回答by hi_tech_lowlife

This almost worked for me:

这几乎对我有用：

git checkout -b upstream upstream/master

git cherry-pick <SHA hash of commit>

git push origin upstream

The only difference was this:

唯一的区别是：

git push origin upstream:upstream

I needed to change that last line so that git push would make the upstream branch in my GitHub repo so that I could make PR from it.

我需要更改最后一行，以便 git push 在我的 GitHub 存储库中创建上游分支，以便我可以从中创建 PR。

回答by irbanana

I had already made the commit which I wanted to be able to isolate as a pull request back onto the current branch.

我已经提交了我希望能够将其作为拉取请求隔离到当前分支上的提交。

So I checked out a new branch

所以我检查了一个新的分支

git checkout -b isolated-pull

And here's where my solution differs from @Kevin Hakanson's, as I need to reset this branch to the place in the history I want to diff from

这就是我的解决方案与@Kevin Hakanson 的不同之处，因为我需要将此分支重置为我想要与之不同的历史记录中的位置

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

And cherry-pick the commit from which I want to create an isolated pull request

并挑选我想从中创建独立拉取请求的提交

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

Finally push it up to the remote

最后推送到遥控器

git push origin isolated-pull

And pull request dat shi.

并拉取请求数据。

回答by Johannes Jendersie

The solution to create a new (temporary) branch, cherry-pick and creating the pull request for that branch did not satisfy me. I did not want to change my repository to make a set of commits available, so I came up with the following alternative:

创建一个新的（临时）分支、cherry-pick 并为该分支创建拉取请求的解决方案并没有让我满意。我不想更改我的存储库以使一组提交可用，因此我想出了以下替代方案：

First create patch files for all commits of interest:

首先为所有感兴趣的提交创建补丁文件：

git format-patch -1 <sha>

If the commit of interest happens to be the last one you can use HEADinstead <sha>.

如果提交的兴趣恰好是最后一个，你可以使用HEAD代替<sha>。

Now, you can send the patches to the maintainer of the source repository, who can apply them:

现在，您可以将补丁发送给源存储库的维护者，他们可以应用它们：

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

Finally this should look the same as if a temporary branch was merged by a pull request, but without having that additional branch in the fork-repository.

最后，这应该看起来就像一个临时分支被拉取请求合并一样，但在 fork-repository 中没有那个额外的分支。

回答by Nathan

Based on @kevin-hakanson's answer, I wrote this little bash script to make this process easier. It will add the upstream repo if it doesn't already exist (prompting you for the URL) then prompt for both the name of the new branch to create and the tag / SHA of the commit to cherry pick onto that branch. It checks what branch or commit you're currently on then stashes any changes so you can checkout the new branch. The merge strategy keeps the changes from the cherry-picked commit. After pushing the new branch to origin(assumed to be the name of your remote repo), the branch or commit you were on before is checked out again and your previous changes popped from the stash.

根据@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

(This has worked for me in a couple of simple tests, but I'm not a bash programmer or git expert, so let me know if there are cases I've missed that could be automated better!)

（这在几个简单的测试中对我有用，但我不是 bash 程序员或 git 专家，所以如果我遗漏了一些可以更好地自动化的案例，请告诉我！）