2017-07-25 60 views
2

我在開發團隊工作,在git推送任何更改以避免合併衝突之前,首選使用方法git fetch,然後git rebase而不是git pull的方法。除了由此產生的git樹結構,git pull與git fetch + git rebase之間是否有任何重要的區別?

除了視覺樹結構的差異之外,還有一個具體原因嗎?據http://mattsnider.com/git-rebase-versus-git-pull/fetch & rebase

「會產生一個更清潔的歷史,沒有多餘的合併提交」

但兩種方法之間是否有任何其他理由選擇一個比其他?

+0

您可以配置'git的pull'來運行'git rebase'代替作爲第二步'git merge'。最後,它對*操作*沒有太大的區別,但我認爲'git pull'通過隱藏實際涉及兩個步驟的事實來爲*人類*提供陡峭的解除服務:'git fetch',然後第二步。 'pull'命令在語法上也是危險的,因爲這種人爲失敗:運行'git pull origin b1 b2'並且最終做章魚合併是很容易的,因爲它看起來像'git pull'做了一些神奇的事情,但它確實沒有。 – torek

+0

'git merge'在不是快進合併時創建合併提交。合併提交不會像'commit-msg'那樣調用一個鉤子。在某些情況下,當你需要'commit-msg'來對每個新提交進行操作時,合併提交會被忽略,除非你修改它。 – ElpieKay

回答

1

git pull = git fetch + git merge

git pull --rebasegit pull -r = git fetch + git rebase

沒有更多的,不低於;-)沒有魔法。 所以你可以做第二個。

執行提取然後在兩個不同的步驟中進行重定位的主要優點是第一個不會修改您的本地分支(絕對沒有風險),因此您可以每次都執行該操作(甚至可以創建運行它的任務定期)。

而且一旦取出,你可以看看歷史,把它比作你的提交,並決定你想要做什麼和什麼時候...

相關問題