2012-04-13 84 views
67

我打開了一個拉請求rails回購github上使用叉&編輯此文件文件按鈕。github:添加提交到現有的拉請求

現在, 在獲得我的PR反饋後,我想添加更多的提交。所以這裏是我在做什麼

$ git clone [email protected]:gaurish/rails.git #my forked repo 
$ git rebase -i 785a2e5 #commit hash of my commit using which PR was opened 
$ git checkout patch-3 #branch name I had to send my commits under to be shown in that PR 
$ git commit -am "Changes done as per feedback" 
$ git push origin patch-3 

這工作得很好,但似乎相當複雜的工作流程。也許我在這裏錯了什麼錯?

我的問題是: 我在做這個正確的方法嗎?如果不是,那麼做到這一點的正確方法是什麼?

+3

有些來這裏可能會發現這更適合他們的情況:http://stackoverflow.com/questions/9790448/how-to-update-a-pull-request – AaronLS 2013-08-04 07:08:09

+3

我還發現這個問題/答案更清晰的版本: http://stackoverflow.com/questions/7947322/preferred-github-workflow-for-updating-a-pull-request-after-code-review?rq=1 – 2014-01-06 15:59:42

回答

45

由於您使用GitHub的工具,只是改變一個文件,你在GitHub上也browse to the file可以選擇從左上角適當的分支下的「樹:」(在你的情況patch-3)下拉菜單,然後選擇現在「編輯這個文件」。現在,您的更改將致力於這一分支,將在您的拉請求

+0

真棒,謝謝。 – Magne 2015-02-05 20:55:09

4

您也可以創建一個新的拉取請求,該請求綁定到master而不是特定的abc1234修訂版。

這樣,任何新的提交/推送到您的存儲庫將被添加到拉請求。

7

我剛剛在這個題目blogged顯示:

我們如何保持這種特性分支最新的嗎?合併最新的上游提交很容易,但是您希望避免創建合併提交,因爲推向上游時不會意識到:您然後有效地重新提交上游更改,並且那些上游提交將得到新的哈希(因爲他們得到一個新的父母)。這一點尤其重要,因爲當您將這些更新推送到您的個人github功能分支時(即使您在發出pull請求後這樣做),那些合併的提交將反映在您的Github提取請求中。

這就是爲什麼我們需要衍合,而不是合併:

git co devel #devel is ansible's HEAD aka "master" branch 
git pull --rebase upstream devel 
git co user-non-unique 
git rebase devel 

兩個底墊選項和變基命令git會保持你的樹的清潔,並避免合併的提交。 但請記住,這些是您的第一次提交(與您簽發了第一個請求的請求),這些提交已重新分配,並且現在有一個新的提交哈希,它與仍在遠程github repo分支中的原始哈希不同。

現在,將這些更新推送到您的個人Github功能分支將會失敗,因爲兩個分支都不相同:由於這些不同的提交散列,本地分支樹和遠程分支樹「不同步」。 Git會告訴你首先git pull --rebase,然後再次push,但這不會是一個簡單的快進推動,因爲你的歷史被重寫了。不要這樣做!

這裏的問題是,您將再次獲取您的第一個更改的提交,因爲它們原來是這樣的,這些將會合併到本地分支之上。由於不同步狀態,此拉不適用於乾淨。你會得到一個b0rken歷史,你的提交出現兩次。當你將所有這些都推送到你的github功能分支時,這些更改將反映在原始的pull請求上,這會變得非常非常難看。

AFAIK,實際上沒有完全乾淨的解決方案。我發現最好的解決辦法是強制把你的本地分行您的github分支(實際上迫使非快速orward更新):

按照git的推(1):

Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository. 

所以不要「T拉,正義的力量推這樣的:

git push svg +user-non-unique 

或:

git push svg user-non-unique --force 

這實際上說白了overwrit e您的遠程分支,以及您本地分支中的所有內容。在遠程流(並導致失敗)中的提交將保留在那裏,但將是懸而未決的提交,最終將被git-gc(1)刪除。沒什麼大不了。

正如我所說,這是AFAICS最乾淨的解決方案。不足之處在於,您的公關將會更新爲最新的提交,這將提供更晚的日期,並可能在公關的評論歷史記錄中顯示不同步。沒有大問題,但可能會令人困惑。