本地有修改和提交，如果想放棄這些修改和提交 可以使用如下命令強制用遠端的庫更新：

git fetch --all
git reset --hard origin/master

git fetch --all  只是下載遠端的庫的內容，不做任何的合併

git reset --hard origin/master  把HEAD指向剛剛下載的最新的版本

幾乎所有的版本控制工具都有branch功能，branch主要用於以下幾個場景：

1，控制產品OEM。

基本上做產品，不同的客戶都會提出多種不同特性需求，最簡單的例子就是LOGO和標題完全不一樣。但是可能產品自身的大部分功能和模組的程式碼一樣的，這個時候如何管理多個客戶定製的功能特性，並且不會干擾其他OEM版本的功能呢？

如果你一開始就用if加N多變數定義的話，早晚會累死你，如果你把程式碼拷貝很多份，每多一個新的OEM就多拷貝一份程式碼，那如果發現公用模組裡面有個BUG，難道你要每個版本的原始碼都要修改？萬一改錯地方了，或者哪個版本的忘記改了，又是一件麻煩事。

這個時候我們就可以考慮使用branch功能，在第一個OEM的基礎上分支出第二個OEM，第三個OEM完全取決於和哪個版本更像，就在那個版本的基礎上做新的分支，有新的OEM特性需求，就切換到那個分支上修改，放心，所有的的單獨分支上的程式碼看起來都是獨立的，不會影響其他版本。

2，多人協作長時間開發功能模組

如果你在一個團隊中，那幾乎很難做到每天都能按期完成某個模組功能，並且

其實上面所說的就是rebase和merge的不同適用場景。

在場景1的情況下，如果修改了某個公用程式碼的BUG，這個時候就應該是把所有的OEM版本分支rebase到這個修復BUG的分支上來，在rebase過程中，Git會要你手動解決程式碼上的衝突，你需要做的就是把修復BUG的程式碼放到目標分支程式碼裡面去。rebase的結果是：所有的分支依然存在

在場景2的情況下，因為成員的程式碼開發工作已經完成了，也不需要再保留這個分支了，所以我們可以把這個成員分支merge到主分支上，當然衝突在所難免，手工解決的工作肯定逃不掉，但是利大於弊不是嗎。merge以後，分支就不存在了，但是在Git的所有分支歷史中還能看到身影。

根據適用場景不同，採用不同的分支合併策略，讓你團隊的程式碼保持生命力吧。