我試過谷歌,沒有幫助。Git - 需要關於rebase的一些解釋
我得到了一個有效的OS項目,保持與好東西,我在它上面開發更新,
因此,可以說我得到了這個項目的git倉庫(讓我們稱之爲當前狀態x)和目前的現狀是:
OS項目
x
我的項目(加時有些變化)
x -> y
現在OS項目更新:
x -> z
,我wan't我的項目包含Z和看起來像
x -> z -> y
或
z -> y
有人能解釋我如何使它發生?
我試過谷歌,沒有幫助。Git - 需要關於rebase的一些解釋
我得到了一個有效的OS項目,保持與好東西,我在它上面開發更新,
因此,可以說我得到了這個項目的git倉庫(讓我們稱之爲當前狀態x)和目前的現狀是:
OS項目
x
我的項目(加時有些變化)
x -> y
現在OS項目更新:
x -> z
,我wan't我的項目包含Z和看起來像
x -> z -> y
或
z -> y
有人能解釋我如何使它發生?
簡單的方法是使用下面的兩個命令(你迭加或承諾更改後):
$ git fetch origin master
$ git rebase FETCH_HEAD
第一個獲取從遠程命名爲「起源」原倉庫的變化。第二個將您的更改移動到新的遠程HEAD。
這裏需要注意的重要一點是,您使用git fetch
而不是git pull
。後者是fetch
,後面是自動merge
。你不想那樣。
如果您正在尋找替代方法,我總是在我的單獨分支上工作。然後,我可以讓主人等同於維護者的版本,並且我可以繼續重新綁定我的並行分支。如果我的分支有其他用戶,我會將主人合併到它中。
假設x,y和z是分支(X和Z軸實際上是同一個分支),你必須ÿ簽出,你可以這樣做:
git rebase z
這樣做是什麼重播所有你從y創建點開始的提交,在z之上,爲你產生一個新的y。請注意,當你這樣做時,你正在改變歷史。也就是說,在rebase之前你提交的所有SHA都被改變了。如果你是唯一一個在y上工作的人,這不是問題。如果你在一個團隊中工作,並且有多個人對y做出承諾,那麼重新定義可能是一個糟糕的主意。在這種情況下,您可以從z合併到y。在不改變歷史的情況下實現您的目標。
將M作爲_main_分支並將D作爲從M分支出來的分支,將D從M分出來是合理的,當你想將D合併到M中並保留一個「平坦」提交歷史時。當沒有合併衝突時,這是最乾淨的解決方案。相反,在將主分支合併到派生分支時,應避免重新分配。在[使用Git進行版本控制]中有一個很好的處理方法[http://www.amazon.co.uk/Version-Control-Git-collaborative-development/dp/0596520123/ref=sr_1_1?ie=UTF8&qid= 1316715248&SR = 8-1) –
我相信這相當於'git pull --rebase'。你也可以使用'git config branch.master.rebase true'設置一個分支來重新綁定。你也可以設置git來始終使用'git config branch.autosetuprebase always'使所有的遠程分支在拉動下拉動。 –
@Bill所有優秀的替代品。我傾向於只學習基本操作,並將它們結合起來。感謝您的快捷鍵。 – vhallac