我在開發團隊工作,在git推送任何更改以避免合併衝突之前,首選使用方法git fetch
,然後git rebase
而不是git pull
的方法。除了由此產生的git樹結構,git pull與git fetch + git rebase之間是否有任何重要的區別?
除了視覺樹結構的差異之外,還有一個具體原因嗎?據http://mattsnider.com/git-rebase-versus-git-pull/fetch
& rebase
「會產生一個更清潔的歷史,沒有多餘的合併提交」
但兩種方法之間是否有任何其他理由選擇一個比其他?
您可以配置'git的pull'來運行'git rebase'代替作爲第二步'git merge'。最後,它對*操作*沒有太大的區別,但我認爲'git pull'通過隱藏實際涉及兩個步驟的事實來爲*人類*提供陡峭的解除服務:'git fetch',然後第二步。 'pull'命令在語法上也是危險的,因爲這種人爲失敗:運行'git pull origin b1 b2'並且最終做章魚合併是很容易的,因爲它看起來像'git pull'做了一些神奇的事情,但它確實沒有。 – torek
'git merge'在不是快進合併時創建合併提交。合併提交不會像'commit-msg'那樣調用一個鉤子。在某些情況下,當你需要'commit-msg'來對每個新提交進行操作時,合併提交會被忽略,除非你修改它。 – ElpieKay