2015-11-19 159 views
4

我有一個my-feature分支被推送到原始代碼審查。這是沒有共享。最終它會合併到我的develop分支中,其中分享給我團隊中的。我想將我的develop分支重新分配爲my-feature以保持歷史更清晰,然後將我的特徵分支合併到開發中。這就是我一直在做:git rebase後,我的本地分支和遠程分支已經發生分歧

$ git checkout my-feature 
// do some work. make commits. 

$ git rebase develop 
// fix some conflicts 

$ git add . 

$ git rebase --continue 

我已經成功地重訂後,我檢查狀態:

$ git status 
On branch my-feature 
Your branch and 'origin/my-feature' have diverged, 
and have 155 and 1 different commit each, respectively. 
    (use "git pull" to merge the remote branch into yours) 

$ git what do I do here? 

我得想法在這裏做什麼。如果我git pull,那麼我注意到,我會得到一些沒有意義的衝突。有人說強迫推行,但我對此很緊張。 強迫我的主題分支來源是否正常?只要沒有其他人使用該分支?

回答

7

首先,你可以在這個階段做了git push --force無任何後顧之憂:你說你的分支不共享。
因此,在服務器端更改其歷史記錄不會影響任何其他用戶。

其次,當你變基一個分支,其共同的祖先從它的遠程跟蹤分支改變(origin/xxx

之前git rebase develop,你有

d--d--d (develop) 
    \ 
    x--x--x--x--x--X--y--y--y (my-feature) 
        | 
     (origin/my-feature) 

X爲原點之間/共同祖先功能和功能,這就意味着您在my-feature分支中添加了一些提交)。
一個Git地位將返回類似:

On branch my-feature 
Your branch is ahead of 'origin/my-feature' by 3 commit. 

但是,當你變基上的develop頂部分支,你重播所有上的頂部的my-feature提交開發HEAD

 X--X--X--X--X--X--Y--Y--Y (my-feature) 
    /
d--D--d (develop) 
    \ 
    x--x--x--x--x--X 
        | 
     (origin/my-feature) 

這時間,my-featureorigin/my-feature之間的共同祖先不再是幾個添加提交,但my-feature的完整歷史記錄,再加上一些提交! (D這裏)

因此狀態

Your branch and 'origin/my-feature' have diverged, 
and have 155 and 1 different commit each, respectively. 

由於您的分支不共享,同樣,一個簡單的git push --force origin my-feature將完成操作:

 X--X--X--X--X--X--Y--Y--Y (my-feature, origin/my-feature) 
    /
d--D--d (develop) 

(如果my-feature具有上游分支,git push --force就足夠了,只要default push policy push.default is set to simple,
Check thatgit rev-parse --abbrev-ref --symbolic-full-name @{u}

+0

很好的解釋。然後我可以將我的''feature''合併到''develop''中,而沒有任何後果? – Jeff

+0

@Jeff是合併將是一個微不足道的快速合併。 – VonC

+1

@VonC根據git的版本,有人使用git push --force有點危險。在git 1.9.5之前,推送的git默認行爲是從本地存儲庫中推送每個分支。 所以它仍然是更好地界定分支明確: 混帳推--force起源 Eruvanos

2

你看到的是,my-featureorigin/my-feature確實不同(我的什麼特徵看上去像原產你上次檢查),因爲你只是改變my-feature(你正在使用的我的功能),當您做了rebase。

當你做一個rebase時,你改變了一個分支的歷史,所以你幾乎總是需要--force之後的推送。如果是你的分支,並且沒有任何合作者使用該分支,那就好了。

如果此功能分支確實有合作者,那麼您不應該重新開始。一般的經驗法則是不改變共享分支的歷史。如果是這種情況,你需要撤消rebase,你可以參考this post尋求幫助。

+0

謝謝。這就說得通了。有時我不知道分支是否會有合作者,所以我想知道是否有共享已重新分配的功能分支的最佳做法。我想我可以開始一個新的分支,櫻桃選擇我想要到新分支的提交。 – Jeff

+1

如果它已被共享,則不要重新綁定。如果你在任何人接受之前進行重組,那麼你很好。一般來說,您應該知道重建是否安全與否。 – jready

1

假定你有以下的git提交結構:

A--B--C--D--E(origin/my-feature) 
\ 
    F--G--H--I(someotherbranch) 

,如果你現在變基上someotherbranchorigin/my-feature那麼你有以下情況:

A--B--C--D--E(origin/my-feature) 
\ 
    F--G--H--I(someotherbranch) 
      \ 
      B'--C'--D'--E'(my-feature) 

那就是diverging情況。 my-feature在另一個分支上,而不是origin/my-feature,並且您無法將fast-forward任何一個分支。現在如果origin/my-feature沒有被任何人拉你可以安全地push -f。但是如果有人拉了它,你可能會遇到問題,如果該人繼續在該分支上工作。檢查是否有人將您的錯誤origin/my-feature是否已將分支頭部更改爲新強制執行。

請務必遵守以下規則:請勿重置任何推送。

糟糕的情況:

   J--K--G(origin/otherperson) 
      /
A--B--C--D--E(origin/my-feature) 
\ 
    F--G--H--I(someotherbranch) 
      \ 
      B'--C'--D'--E'(my-feature) 

這應該然後改爲:

A--B--C--D--E(origin/my-feature) (orphaned if push-f) 
\ 
    F--G--H--I(someotherbranch) 
      \ 
      \    J'--K'--G'(origin/otherperson) 
       \   /
       B'--C'--D'--E'(my-feature) 
相關問題