爲什麼git pull會引入git fetch rebase不是的變化？

Question

我有一個遠程分支1.4

我與結果的git fetch origin：

13b1449..51618fe 1.4 -> origin/1.4

然後我做了git rebase 13b1449

混帳迴應Current branch 1.4 is up to date

然後我做了一個git pull origin 1.4它帶來了3個文件。

我在做什麼錯誤取&重新分配不更新我的分支與它從遠程服務器獲取什麼？

Answer 1

13b1449是當地的哈希提交。 「遠程」提交是51618fe - 您作爲origin/v1.4的頭部提交的提交。

您的rebase命令沒有任何影響（您要求git在當前提交時重定位），另一方面pull正確地將您的本地分支向前移動。

爲了避免混淆，而不是使用哈希值，你可以使用分支名稱：

git rebase origin/v1.4 

---

git有幾個選擇，當你拉應用的rebase而不是merge。

引用this link，通過this SO question發現：

拉與底墊，而不是合併

$ git pull --rebase 

# e.g. if on branch "master": performs a `git fetch origin`, 
# then `git rebase origin/master` 

由於分支合併在git的記錄與合併提交，他們應該是有意義的，例如，以指示何時功能已合併到發佈分支。然而，在常規的日常工作流程中，幾個團隊成員經常同步一個分支，時間軸會受到常規git pull的不必要的微合併污染。重新激活確保提交總是重新應用，以便歷史保持線性。

您可以配置一定分行始終做到這一點，而不--rebase標誌：

# make `git pull` on master always use rebase 
$ git config branch.master.rebase true 

您還可以設置一個全局選項來設置最後一個屬性爲每一個新的被跟蹤的分支：

# setup rebase for every tracking branch 
$ git config --global branch.autosetuprebase always 

Answer 2

A fetch只檢索「遠程」參考（即來自不同存儲庫的參考）。

A pull實際上是一個fetch後跟一個merge。

如果你想從origin/1.4這個命令你已經取出後的變化，問題： git merge origin/1.4