您可以簡化您的命令:
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 fetch
和git merge
組合。
通常你只是想要git pull --rebase
這本質上是git fetch
加git rebase
,並創建一個更清潔的歷史。
是否有任何理由讓你的「週期性推動」?如果沒有其他人在同一個分支上工作,那完全沒問題,只需要在完成所有工作後推動。
感謝您(和克里斯托弗)的回覆。爲了回答你的問題,沒有理由讓週期性推動,而不是作爲備份,以防我的盒子死亡。而且,如果有人希望我的代碼能夠完成他們自己的工作 - 不完全可能,直到我的代碼進入主服務器,再在公共分支上進行重新綁定可能會導致麻煩,所以我明白(但我不確定爲什麼確切) – larryq
rebases是一把雙刃劍。一方面它們往往導致更加清晰的歷史。另一方面他們創建了基本上是舊內容的全新提交。如果你推動你的提交,其他人可以(理論上)在這些提交上構建自己的更改。如果您稍後決定重新提交您提交的內容,則基本上會使舊提交無效並對其進行所有更改。 - 即使你刪除舊的分支,另一個可能會推動他的更改,因此也會推動舊的更改,這會導致重複的提交和解決混亂。 :) – michas
再次,非常感謝。我一直在閱讀關於'git pull --rebase',並不是100%,如果我在當前(比如說)'my_branch'中調用它會發生什麼。在這種情況下,命令從'my_branch'遙控器拉出來,然後重新綁定到......哪個分支?因爲我沒有在命令中的任何地方提及它,所以我不會假設主人。 所以它必須重新綁定'my_branch',這對我來說聽起來有點奇怪,因爲我總是重新設計了兩個獨立的分支。但我認爲這是可能的,現在我想起它,爲什麼不呢? – larryq