2013-11-03 140 views
19

我有一個遠程存儲庫,我已經拉出並分支。我希望通過對主人所做的更改保持最新的分支。我正在考慮下面的工作流程,這是否有意義,還是有更好的方法來做到這一點?保持與主人的分支最新

  1. 初始分支和結帳:

    git checkout master 
    
    git pull 
    
    git checkout -b my_branch 
    
  2. 做一些工作my_branch,然後定期:

    git checkout master 
    
    git pull 
    
    git checkout my_branch 
    
    git merge master --no-ff 
    

重複步驟2,根據需要,定期推向遠程my_branch

然後,當準備好合並回:

git checkout master 

git merge my_branch --no-ff 

聲音好嗎?

回答

16

您可以簡化您的命令:

1.

git fetch 
git checkout -b my_branch origin/master 

2.

git fetch 
git merge origin/master 

git fetch更新遠程分支,通常沒有必要有當你沒有的時候,一個分支的本地副本計劃在這個分支上工作。

設置​​3210後可以省略--no-ff

git help config說:

merge.ff 
     By default, Git does not create an extra merge commit when merging 
     a commit that is a descendant of the current commit. Instead, the 
     tip of the current branch is fast-forwarded. When set to false, 
     this variable tells Git to create an extra merge commit in such a 
     case (equivalent to giving the --no-ff option from the command 
     line). When set to only, only such fast-forward merges are allowed 
     (equivalent to giving the --ff-only option from the command line). 

注意git pull只是一個git fetchgit merge組合。

通常你只是想要git pull --rebase這本質上是git fetchgit rebase,並創建一個更清潔的歷史。

是否有任何理由讓你的「週期性推動」?如果沒有其他人在同一個分支上工作,那完全沒問題,只需要在完成所有工作後推動。

+0

感謝您(和克里斯托弗)的回覆。爲了回答你的問題,沒有理由讓週期性推動,而不是作爲備份,以防我的盒子死亡。而且,如果有人希望我的代碼能夠完成他們自己的工作 - 不完全可能,直到我的代碼進入主服務器,再在公共分支上進行重新綁定可能會導致麻煩,所以我明白(但我不確定爲什麼確切) – larryq

+1

rebases是一把雙刃劍。一方面它們往往導致更加清晰的歷史。另一方面他們創建了基本上是舊內容的全新提交。如果你推動你的提交,其他人可以(理論上)在這些提交上構建自己的更改。如果您稍後決定重新提交您提交的內容,則基本上會使舊提交無效並對其進行所有更改。 - 即使你刪除舊的分支,另一個可能會推動他的更改,因此也會推動舊的更改,這會導致重複的提交和解決混亂。 :) – michas

+1

再次,非常感謝。我一直在閱讀關於'git pull --rebase',並不是100%,如果我在當前(比如說)'my_branch'中調用它會發生什麼。在這種情況下,命令從'my_branch'遙控器拉出來,然後重新綁定到......哪個分支?因爲我沒有在命令中的任何地方提及它,所以我不會假設主人。 所以它必須重新綁定'my_branch',這對我來說聽起來有點奇怪,因爲我總是重新設計了兩個獨立的分支。但我認爲這是可能的,現在我想起它,爲什麼不呢? – larryq

8

我會建議使用rebase工作流程。因此,而不是使用git pull您應該使用git pull --rebase

我會做同樣的功能分支。所以,而不是做一個git merge master --no-ff我會使用git rebase master。但是,如果功能分支旨在在開發過程中與同事共享,則最好將主分支定期合併到功能分支中。

但說實話,我在一個小團隊工作,如果我們需要一起工作在一個功能分支上,並且我們需要把它和主人一起更新,那麼我們暫停我們的工作一段時間(並且溝通這個過程很清楚),主人和力量的重新組合推動特徵分支。但是,對於更大的團隊來說,這並不成比例。但是,我發現使用在主服務器上重新綁定的功能部件而不必處理來自主服務器的合併更方便。

請務必閱讀。

Git workflow and rebase vs merge questions

相關問題