代碼審查后更新拉取請求的首選 Github 工作流程

Question

我已經在 Github 上提交了對開源項目的更改，並收到了一位核心團隊成員的代碼審查意見。

我想考慮到評論意見更新代碼，然后重新提交。 執行此操作的最佳工作流程是什么？ 根據我對 git/github 的有限了解，我可以執行以下任何操作：

1. 將代碼更新為新提交，並將初始提交和更新后的提交添加到我的拉取請求中。

2. 不知何故（??）從我的存儲庫回滾舊提交，並創建一個包含所有內容的新提交，然后為此提出拉取請求？

3. git commit具有修改功能，但我聽說在將提交推送到本地存儲庫之外后不應該使用它？ 在這種情況下，我在我的本地 PC 上進行了更改，並推送到我的項目的 github 分支。 使用“修改”可以嗎？

4. 還有別的嗎？

選項 2/3 似乎不錯，因為開源項目在其歷史記錄中只有一次提交可以實現所有內容，但我不確定如何執行此操作。

注意：我不知道這是否會影響答案，但我沒有在單獨的分支中進行更改，我只是在 master 之上進行了提交

Answer 1

更新拉取請求

要更新拉取請求（第1點），您唯一需要做的就是檢查拉取請求來自的同一分支並再次推送到它：

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

可選 - 清除提交歷史記錄

可能會要求您將提交壓縮在一起，以便存儲庫歷史記錄清晰，或者您自己想要刪除中間提交，這些提交會分散拉動請求中的“消息”（第2點）。 例如，如果您的提交歷史記錄如下所示：

$ git remote add parent git@github.com: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

將事物壓縮在一起是個好主意，因此它們只顯示為一次提交：

$ git rebase -i parent/master 

這將提示您選擇如何重寫拉取請求的歷史記錄，以下內容將在您的編輯器中：

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

對於任何提交，您希望成為之前提交的一部分 - 更改選擇以進行壓縮：

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

並關閉你的編輯器。 然后，Git將重寫歷史記錄並提示您為一個組合提交提供提交消息。 相應修改，您的提交歷史現在將簡明扼要：

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

把它推到你的前叉：

$ 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 git@github.com:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

並且您的pull請求將包含一個提交，其中包含先前拆分為多個提交的所有更改。

改變公共回購的歷史是件壞事

重寫歷史記錄並在一個分支上使用git push -f ，這個分支可能已經克隆了其他人 - 這會導致存儲庫的歷史記錄和結帳的歷史記錄發生分歧。

但是，修改fork的歷史記錄以糾正您建議集成到存儲庫中的更改 - 這是一件好事。 因此，毫無保留地壓低你的拉動請求中的“噪音”。

關於分支的說明

在上面我展示拉請求來自你的fork的master分支，這沒有什么不妥，但它確實產生了某些限制，例如，如果這是你的標准技術，只能打開一個PR庫。 雖然為您希望提出的每個單獨的更改創建一個分支，但這是一個更好的主意：

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

Answer 2

只需向pull請求中使用的分支添加新提交，然后將分支推送到GitHub。 拉取請求將自動使用附加提交進行更新。

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

Answer 3

我對最佳實踐的看法：一旦你准備打包拉取請求，它應該在一開始就得到它自己獨特的主題分支，特別是為此目的。 首先將該分支推送到您的github存儲庫，例如

git push origin name-of-pull-request-branch

並將拉取請求基於該分支。 完成此操作后，您推送到該分支的任何提交都將自動附加到拉取請求中。 你只使用那個分支。

有些人更喜歡用你的github userid命名這樣的分支。 通過這種方式，他們可以在當地免費查看，以便嘗試一下

• 減少對分支名稱沖突的恐懼
• 更容易記住它是什么

我通常將我的拉請求分支命名為

claybridges-do-the-things