git 用于在代码审查后更新拉取请求的首选 Github 工作流程

Preferred Github workflow for updating a pull request after code review

提问by Orion Edwards

I've submitted a change to an Open Source project on Github, and received code review comments from one of the core team members.

我已在 Github 上提交了对开源项目的更改，并收到了一位核心团队成员的代码意见。

I would like to update the code taking into account the review comments, and re-submit it. What is the best workflow for doing this? From my limited knowledge of git/github, I could do any of the following:

我想根据意见更新代码，然后重新提交。执行此操作的最佳工作流程是什么？根据我对 git/github 的有限了解，我可以执行以下任何操作：

1. Update the code as a new commit, and add both the initial and updated commit to my pull request.

2. Somehow (??) rollback the old commit from my repository, and create a single new commit containing everything, then raise a pull request for that?

3. git commithas an amend feature, but I've heard that you shouldn't use it after you've pushed the commit outside of your local repository? In this case I have made the change on my local PC and pushed to my github branch of the project. Would this be OK to use 'amend'?

4. Something else?

1. 将代码更新为新提交，并将初始提交和更新后的提交添加到我的拉取请求中。

2. 不知何故（??）从我的存储库中回滚旧提交，并创建一个包含所有内容的新提交，然后为此提出拉取请求？

3. git commit有一个修改功能，但我听说在将提交推送到本地存储库之外后不应该使用它？在这种情况下，我在我的本地 PC 上进行了更改并推送到我的项目的 github 分支。使用“修正”可以吗？

4. 还有什么？

It seems like option 2/3 would be nice, as the open source project would only have one commit in their history which would implement everything, but I'm not sure how to do this.

似乎选项 2/3 会很好，因为开源项目在其历史记录中只有一次提交可以实现所有内容，但我不确定如何执行此操作。

Note: I don't know if this affects the answer or not, but I didn't make the changes in a separate branch, I just did a commit on top of master

注意：我不知道这是否会影响答案，但我没有在单独的分支中进行更改，我只是在 master 之上进行了提交

采纳答案by Amber

Just add a new commit to the branch used in the pull request and push the branch to GitHub. The pull request will automatically be updated with the additional commit.

只需向拉取请求中使用的分支添加一个新提交并将该分支推送到 GitHub。拉取请求将使用额外的提交自动更新。

#2 and #3 are unnecessary. If people want to see only where your branch was merged in (and not the additional commits), they can use git log --first-parentto only view the merge commit in the log.

#2 和 #3 是不必要的。如果人们只想查看您的分支合并的位置（而不是其他提交），他们可以使用git log --first-parent仅查看日志中的合并提交。

回答by AD7six

To update a pull request

更新拉取请求

To update a pull request (point #1), the only thing you need to do is checkout the same branch the pull request is from and push to it again:

要更新拉取请求（第 1 点），您唯一需要做的就是检出拉取请求来自的同一分支并再次推送到它：

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

Optional - Cleaning commit history

可选 - 清理提交历史

You may be asked to squash your commits together so that the repository history is clean, or yourself want to remove intermediary commits which distract from "the message" in your pull request (point #2). For example if your commit history looks like this:

您可能会被要求将您的提交压缩在一起，以便存储库历史记录是干净的，或者您自己想要删除中间提交，这些提交会分散您的拉取请求中的“消息”（第 2 点）。例如，如果您的提交历史如下所示：

$ git remote add parent [email protected]:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

It's a good idea to squash things together so they appear as a single commit:

将东西压缩在一起是一个好主意，这样它们就显示为一次提交：

$ git rebase -i parent/master 

This will prompt you to choose how to rewrite the history of your pull request, the following will be in your editor:

这将提示您选择如何重写拉取请求的历史记录，以下内容将在您的编辑器中：

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

For any commit you want to be part of the previous commit - change pick to squash:

对于您希望成为上一次提交的一部分的任何提交 - 将选择更改为壁球：

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

And close your editor. Git will then rewrite the history and prompt you to provide a commit message for the one combined commit. Amend accordingly and your commit history will now be concise:

并关闭您的编辑器。然后，Git 将重写历史记录并提示您为一次合并提交提供提交消息。相应地修改，您的提交历史现在将变得简洁：

$ git log --oneline parent/master..master
9de3202 fixing actual problem

Push that to your fork:

把它推到你的叉子上：

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To [email protected]:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

and your pull request will contain a single commit, incorporating all changes previously split into several commits.

并且您的拉取请求将包含单个提交，将之前拆分为多个提交的所有更改合并。

Changing history on public repos is a bad thing

改变公共回购的历史是一件坏事

Rewriting history and using git push -fon a branch that, potentially, someone else has already cloned is a bad thing - it causes the repository's history and that of the checkout to diverge.

重写历史并git push -f在其他人可能已经克隆的分支上使用是一件坏事——它会导致存储库的历史和检出的历史发生分歧。

However, amending the history of your fork to correct the change you are proposingto be integrated into a repository - is a good thing. As such have no reservations squashing "noise" out of your pull requests.

但是，修改您的 fork 的历史记录以更正您提议集成到存储库中的更改- 是一件好事。因此，您可以毫无保留地消除拉取请求中的“噪音”。

A note on branches

分行注意事项

In the above I show the pull request as having come from the masterbranch of your fork, there's nothing wrong with that necessarily but it does create certain limitations such as, if this is your standard technique, only being able to have one PR open per repository. It's a better idea though to create a branch for each individual change you wish to propose:

在上面，我将拉取请求显示为来自master您的分支的分支，这必然没有错，但它确实产生了某些限制，例如，如果这是您的标准技术，则每个存储库只能打开一个 PR . 不过，为您希望提出的每个单独更改创建一个分支是一个更好的主意：

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets