rebase命令

① 如何在svn系統中使用git

操作步驟:
你需要:

1.安裝 git 和 git-svn
2.創建工作目錄:mkdir strigi
3.初始化git工作目錄:

4.找到項目的某個提交 (你可以通過 cia版本控制 去獲得). 警告: 命令git-log 會從這個版本開始顯示項目的版本歷史。
5.執行命令git-svn fetch -rREVISION，REVISION 就是剛才獲得的那個版本號。
6.更新工作目錄:git-svn rebase，現在你就可以在這個項目中使用git作為版本控制了。
要保持工作目錄更新，可以執行:

git-svn rebase

你可以用下面的命令將更改提交到svn伺服器:

git-svn dcommit

通過這種方式，所有的git提交都會「轉換」成相應的svn命令。
解決git-svn rebase的問題
在加入新東西之前，你也許會在同步主開發樹的時候體驗到一些問題。實際上，你在執行git-svn
rebase之前還必須提交所有的本地修改(使用git-commit命令)。
有時候這並不合理，因為你的更改也許還沒有準備好提交（還沒有完成、測試或者驗證這寫代碼）。不過別擔心，git對此也有一個官方的解決方案，只需下面的步驟：
先把你的改動保存起來，使用命令：git-stash
更新工作副本，使用命令：git-svn rebase，這跟平時一樣
恢復保存起來的改動，使用命令：git-stash apply
清除「保存」，使用命令:git-stash
clear。第1步之後，所有未提交的改動在工作副本上都看不到了，因而你可以執行rebase命令，不會有任何問題。

② git命令之git merge 和 git rebase的區別

git merge是用來合並兩個分支的。
# 將b分支合並到當前分支
git merge b

git cherry-pick可以選擇某一個分支中的一個或幾個commit(s)來進行操作。例如，假設我 們有個穩定版本的分支，叫v2.0，另外還有個開發版本的分支v3.0，我們不能直接把兩個分支合並，這樣會導致穩定版本混亂，但是又想增加一個v3.0 中的功能到v2.0中，這里就可以使用cherry-pick了。

# 先在v3.0中查看要合並的commit的commit id
git log
# 假設是 commit

# 切到v2.0中
git check v2.0

# 合並commit
git cherry-pick

git rebase有點類似git merge，但是兩者又有不同，打個比方，你有兩個抽屜A和B，裡面都裝了衣服，現在想把B中的衣服放到A中，git merge是那種橫沖直撞型的，拿起B就倒入A裡面，如果滿了（沖突）再一並整理；而git rebase就很持家了，它會一件一件的從B往A中加，會根據一開始放入的時間順序的來加，如果滿了你可以處理這一件，你可以繼續加，或者跳過這一件，又 或者不加了，把A還原。所以merge適合那種比較瑣碎的，簡單的合並，系統級的合並還是用rebase吧。

專業的區別請移步到這里合並和衍合

# 合並b
git rebase b

# 處理完沖突繼續合並
git rebase –continue

# 跳過
git rebase –skip

# 取消合並
git rebase –abort

③ SourceTree 合並分支時幾個選項是什麼意思

SourceTree 是 Windows 和Mac OS X 下免費的 Git 和 Hg 客戶端，同時也是Mercurial和Subversion版本控制系統工具。支持創建、克壟提交、push、pull 和合並等操作。

git入門五（分支合並沖突和衍合）
分支合並沖突的處理

合並分支的沖突時在不同的分支中修改了同一個文件的同一部分，程序無法把兩份有差異的文件合並，這時候需要人為的干預解決沖突。當前處於master 分支，當dev 分支和master 分支對相當部分test1.txt 都做了修改，當合並dev 分支的時候，合並會出現分支沖突如下：查詢當前工作區的狀態可以顯示那些文件發生合並沖突，任何包含未解決沖突的文件都會以未合並（ummerged)的狀態列出，git 會加入標准沖突解決標記，可以通過手工定位來解決這些沖突。可以看大 =======隔開以上部分就是當前活動分支，也是合並的基準分支（head 指向的master分支），======分隔符以下的是dev分支中的內容。解決沖突的辦法無非是二者選其一或者由你親自整合到一起。比如你可以兩部分內容合並成 一部分內容。

$ git branch
dev
* master
testing

$ git merge dev
Auto-merging test1.txt
CONFLICT (content): Merge conflict in test1.txt
Automatic merge failed; fix conflicts and then commit the result.

$ git status
# On branch master
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: test1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

$ notepad test1.txt
<<<<<<< HEAD

now this is bug fix branch

=======

this is branch merge conflict problem

>>>>>>> dev

同時還可以用圖形化界面的工具來處理分支，git mergetool 命令會調用時當前系統配置的合並工具。合並完成後可以查詢狀態git status 來確認所有沖突都已經解決。如果沖突解決都已完成，可以把合並後的內容提交到暫存區，可以用git commit 完成這次合並提交。針對沖突合並，需要寫好注釋說明，後續查看會更加簡單方便。

$ git commit -m "master merge dev branch"
[master 05a2f29] master merge dev branch
1 files changed, 4 insertions(+), 1 deletions(-)

分支的管理

git branch 是查詢當前所有分支的清單，*號的表示當前的活動分支，也就是當前所在的分支。也就是說如果現在有提交更新，當前的工作分支master 分支或向前移動。若要看各個分支最後一個提交對象的新，可以通過git branch -v 來查看。

$ git branch
dev
* master
testing

$ git branch -v
dev be70ec8 dev
* master 05a2f29 master merge dev branch
testing 0c8f2de testing branch change

在所有分支清單中，可以篩選出那些與當前分支尚未合並，通過參數--merge 可以篩選出那些分支在當前分支的上游，這些分支只需要通過fast-forward 移動指正就可以移動當當前最後提交給對象。--no-merged 可以查看還位和當前分支合並的分支。如dev分支和當前分支還未合並。如果以前是無效的分支，可以通過git branch -d 刪除制定的分支。
$ git branch --merged
* master
testing

$ git branch --no-merged
dev

$ git branch -d testing
Deleted branch testing (was 0c8f2de).

長期分支

git只是簡單的三方合並分支的特性，所以在腳長的一段時間內，把多個分支合並到一個分支或者同時擁有多發分支進行開發。由於每個分支都有特定的任務，隨著開發的推進，隨時可以把某個特性分支合並到其它分支中。需求使用git 的開發者都喜歡用這種方式開發，一般來說僅僅在master 分支保留穩定的代碼，就是已經發布或者經過測試的代碼。與此同時，你可以同時擁有多個開發分支。每個開發分支都有特定的任務。如還有一個叫develop 的平行分支，專門擁有後續的開發，僅擁有穩定性的測試。一旦到達某種穩定的狀態就可以合並到master 分支。如果有其它特性的短缺分支能夠通過測試，並且不會引如更多錯誤後，就可以並到主幹master分支中。等待下一次發布。

隨著提交對象的不斷右移指針，穩定分支總是在提交歷史中落後一大截，而且前言分支總是比較靠前。穩定分支總是滯後，經過測試比較穩定的對象或者集合才被合並到穩定的分支上。這樣可以維護不同層次的穩定。

特性分支

在任何規模的項目中可以使用特性分支（topic).一個特性是指一個短期的，用來實現單一特性與其相關的工作分支，你可以在以前版本中從未做過類似的這樣事情，因為創建和合並分支的消耗太大。然而在git中，一天之內創建，刪除和合並多個分支是常見的事情。在創建特性分支後，你可以提交合並到主幹分支，然後刪除他，該技術讓你迅速且完全進行語境切換。因為你的工作分散在不同的流水性力，每個分支力改變都和他的目標特性相關。你可以把做出的改變保持在特性分支幾分鍾。幾天甚至幾個月。等他們成熟以後再合並。而不用在乎他們建立的順序和進度。

一般分支都是在本地。大部分都是本地分支。這一點很重要。當前使用合並分支的時候，一切都在你的git 倉庫中進行的，完全不與伺服器交互。只有當你有固定的分支或者分享需要和其它合作夥伴共享的時候，才需要推送到中心伺服器。

遠程分支：

remote branch 是對遠程倉庫中的分支的索引。他們是無法移動本地分支。只有在git進行網路交互時才會更新。遠程分支就是書簽，提醒著你上次鏈接遠程倉庫時上面各個分支的位置。 我們用倉庫名/分支名 這樣的形式表示遠程分支。比如我們想想上次同 origin 倉庫進行通訊時master 分支的樣子。就應該查看origin/master 分支。如果你和同伴一起修復某個問題。他們推送一個iss53分支到遠程倉庫。雖然你可能也有一個本地的iss53分支，但指向伺服器上最新的更新的英是origin/iss53分支。

假如團隊中心伺服器git地址：git.ourcompany.com.。如果你從這里克隆，git會自動在為你將次遠程倉庫嗎命名為origin。並下載其中的數據，建立一個指向它的master分支指針。在本地命名為Origin/master。但你無法再本地更改數據，接著git建立一個屬於你自己本地的master分支。始於origin上master分支相同的位置。如下圖

如果你在本地master 分支做了些改動。與此同時本地分支向前推進。只要本地沒有向遠程伺服器推送，origin/master 分支指針任然保持在原位不會移動。

在本地工作同時有人向遠程倉庫推送內容會讓歷史開始分流。可以允許git fethch origin 來同步遠程伺服器上的數據到本地。該命令首先找到origin 是哪個伺服器。從上面獲取你未擁有的數據。更新你本地的資料庫。然後把Origin/master的指針移動到他最新的位置上。

如果有多個遠程分支的項目是如果進行工作的。我們假設你還有另外一個內部使用的遠程伺服器。通過git remote add 命令吧它加為當前項目的遠程分支之一。我們把它命名為teamtone,以便代替完整的git url。

現在把另外一個遠程伺服器添加為遠程倉庫了，現在可以用git fetch teamtone 來獲取小組伺服器你還沒有的數據，由於當前伺服器的內容是origin伺服器上的子集，git不會下載任何數據。而只是簡答創建一個名為teamone/master 的遠程分支。指向teamone 伺服器上master 分支所有在的提交對象 31b3e 如下圖：現在你在本地就有了一個指向teamone 的索引。

推送本地分支

要想和其它人分享某個本地的分支，你需要把它推送到一個擁有些許可權的遠程倉庫。你創建的本地分支部會因為你的寫入操作而被自動同步到你引入的遠程伺服器上，你需要明確的執行推送分支的操作。換句話說，對於無意分享的分支，你盡管保留私人分支好了。而只推送那些協同工作要用到的特性分支。如果有個交severfix 的分支需要和他人一起開發，可以運行git push (遠程倉庫名） 分支名。

$ git push origin serverfix
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:andy/test.git
* [new branch] serverfix -> serverfix

git 自動把serverfix 分支名擴展為refs/heads/serverfix:refs/heads/serverfix,意思是「取出我在本地的serverfix分支，推送到遠程倉庫的serverfix分支中區，一般在同一分支上可以省略， git push origin serverfix:serverfix，還可以把本地分支推送到遠程不同的分支。可以用已經存在的新遠程分支或新的遠程分支。
當你再次從遠程獲取伺服器上數據的時候，同伴會獲取到origin/serverfix 和 origin/newfix 的分支，並指向伺服器上serverfix 所指向的版本。在fetch操作下載好新的遠程分支之後。你任然無法再本地編輯遠程倉庫中的分支。換句話說你不會有一個新的serverfix 分支。有的只是一個你無法移動的Origin/serverfix指針。你如果需要把該遠程分支的內容合並到當前分支，可以運行git merge origin/serverfix ,如果想要一份自己的serverfix來開發。可以在遠程分支的基礎上分化一個新的分支來。這會切換到新的serverfix 的本地分支。其內容同遠程分支 origin/serverfix 一致。這樣可以繼續開發了。

$ git push origin serverfix:newfix
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:andyi/test.git
* [new branch] serverfix -> newfix

$ git fetch origin
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 17 (delta 6), reused 16 (delta 5)
Unpacking objects: 100% (17/17), done.
From github.com:andyi/test
* [new branch] dev -> origin/dev
894ed8b..37b40ce master -> origin/master

跟蹤遠程分支

從遠程分支checkout 出來的本地分支。稱為跟蹤（tracking branch）,跟蹤分支是一種和某個遠程分支有直接聯系的本地分支。在跟蹤分支里輸入git push,git 會自行推斷應該向那個伺服器的那個分支推送數據。同樣，在這些分支里運行git pull 會回去遠程索引，並把它們的數據合並到本地分支中。
在克隆倉庫時，git 通常會自創建一個名master 的分支來跟蹤，這正是git push 和 git pull 一開始就能正常工作的原因。當然，你可以隨心所欲設定其為跟蹤分支，比如在origin 上除了master 之外的其它分支。剛才我們已經開到了這樣的一個例子。 git checkout -b 分支名 遠程名/分支名， 還可以用 --track 選項。 如果本地分支和遠程分支的名稱不一樣，可以本地分支換個名稱。

$ git checkout -b serv origin/serverfix
Branch serv set up to track remote branch serverfix from origin.
Switched to a new branch 'serv'

$ git branch
master
* serv
serverfix

刪除遠程分支

如果不再需要摸個遠程分支了，比如搞定某個特性並合並進了遠程的master 分支（或任何其他存放穩定的代碼分支），可以用這個命令 git push 遠程名：分支名。如果運行這個命令，伺服器上的分支就沒了，git puhs 遠程名 本地分支：遠程分支 語法，如果省略本地分支。那就是等提前空白然後把它變成遠程分支。

分支的衍和

把一個分支中的修改整合到另一個分支的辦法由兩種：merge 和 rebase(翻譯為衍合）。

基本的衍合操作，當開發進程分叉到兩個不同的分支，有各自提交了更新。最簡單的整合方式是合並merege 命令。他會把兩者共同的祖先ac631f6進行三方合並。並合後產生一個結果就是兩條分的合並點。

其實除了合並以外，還有另外一個選擇，可以把7599941產生變化的補丁在4632de基礎上重新打一遍。在git 里著叫衍合（rebase),有了rebase命令，就可以在把在一個分只里提交的改變移動到另一個分支重方一遍。他們的原理是回到兩個分支最近共同的祖先。根據當前分支（也就是要進行衍合的分支）後續歷次提交的對象在這里分支只有一個提交。生產一系列文件補丁，然後基地分支（也就是主幹分支master 的最後一個提交對象為新的出發點，逐個應用之前准備好的補丁文件，最後會生產一個新的合並提交對象。從而改寫需要衍合分支的提交歷史。使他成為master 分支的直接下游。

④ git merge和rebase的區別

merge和rebase的區別
處理沖突的方式：
使用merge命令合並分支，解決完沖突，執行git add .和git commit -m'fix conflict'。這個時候會產生一個commit。
使用rebase命令合並分支，解決完沖突，執行git add .和git rebase --continue，不會產生額外的commit。這樣的好處是『干凈』，分支上不會有無意義的解決分支的commit。
git pull和git pull --rebase區別：git pull做了兩個操作分別是『獲取』和合並。所以加了rebase就是以rebase的方式進行合並分支，默認為merge。

⑤ git reset rebase和 revert的區別

git revert 放棄某次提交

git revert 之前的提交仍會保留在git log中，而此次撤銷會做為一次新的提交。

git reset 是回滾到某次提交

git reset --soft

此次提交之後的修改會被退回到暫存區

git reset --hard

此次提交之後的修改不做任何保留，git status干凈的工作區。

git rebase 當兩個分支不在一條直線上，需要執行merge操作時，使用該命令操作。

該命令執行時極有可能顯示merge失敗，如下圖1，使用git
diff命令查看沖突內容，手動

修改沖突，git add filename，表示沖突已解決，再執行git
rebase --continue，繼續rebase。

圖1

⑥ merge和rebase的區別

merge 是一個合並操作，會將兩個分支的修改合並在一起，默認操作的情況下會提交合並中修改的內容

merge 的提交歷史忠實地記錄了實際發生過什麼，關注點在真實的提交歷史上面

rebase 並沒有進行合並操作，只是提取了當前分支的修改，將其復制在了目標分支的最新提交後面

rebase 的提交歷史反映了項目過程中發生了什麼，關注點在開發過程上面

merge 與 rebase 都是非常強大的分支整合命令，沒有優劣之分，使用哪一個應由項目和團隊的開發需求決定

merge 和 rebase 還有很多強大的選項，可以使用 git help <command> 查看

使用 merge 時應考慮是採用 --no-ff 默認操作，生成一個對回顧提交歷史並不友好的合並記錄，還是採用 --ff-only 方式

rebase 操作會丟棄當前分支已提交的 commit，故不要在已經 push 到遠程，和其他人正在協作開發的分支上執行 rebase 操作

與遠程倉庫同步時，使用 pull 命令默認進行了 git fetch + git merge --no-ff 兩個操作，可以通過加上 --rebase 命令將 fetch 後的 merge 操作改為 rebase 操作，或者僅僅 'git fetch remoteName',然後才思考採取哪種整合策略 git merge(or rebase) origin/master

開發與 commit 時注意自己此時在哪個分支上

當有修改未 commit 時，不能進行 rebase 操作，此時可以考慮先用 git stash 命令暫存

⑦ git rebase 解決完沖突執行什麼命令

結果是from_branch的代碼更新到to_branch, 同時to_branch的commit log加到from_branch的最前方。例子：1. git rebase remotes/main/master MYBRANCH從遠程主fork的master分支到本地分支MYBRANCH進行rebase。

⑧ git rebase i怎麼返回

想像一下你正在開發一個激進的新功能。這將是很燦爛的但它需要一段時間。您這幾天也許是幾個星期一直在做這個。

你的功能分支已經超前master有6個提交了。你是一個優秀的開發人員並做了有意義的語義提交。但有一件事情：你開始慢慢意識到，這個瘋狂的東西仍需要更多的時間才能真的做好准備被合並回主分支。
m1-m2-m3-m4 (master) \ f1-f2-f3-f4-f5-f6(feature)

你也知道的是，一些地方實際上是交叉不大的新功能。它們可以更早地合並到主分支。不幸的是，你想將部分合並到主分支的內容存在於你六個提交中的某個地方。更糟糕的是，它也包含了依賴於你的功能分支的之前的提交。有人可能會說，你應該在第一處地方做兩次提交，但沒有人是完美的。
m1-m2-m3-m4 (master) \ f1-f2-f3-f4-f5-f6(feature) ^ | mixed commit

在你准備提交的時間，你沒有預見到，你可能要逐步把該功能合並入主分支。哎呀！你不會想到這件事會有這么久。
你需要的是一種方法可以回溯歷史，把它並分成兩次提交，這樣就可以把代碼都安全地分離出來，並可以移植到master分支。
用圖說話，就是我們需要這樣。
m1-m2-m3-m4 (master) \ f1-f2-f3a-f3b-f4-f5-f6(feature)

在將工作分成兩個提交後，我們就可以cherry-pick出前面的部分到主分支了。
原來Git自帶了一個功能強大的命令git rebase -i ，它可以讓我們這樣做。它可以讓我們改變歷史。改變歷史可能會產生問題，作為一個經驗，應盡快避免歷史與他人共享。不過在我們的例子中，我們只是改變我們的本地功能分支的歷史。沒有人會受到傷害。就這么做了！
好吧，讓我們來仔細看看f3提交究竟修改了什麼。原來我們共修改了兩個文件：userService.js和wishlistService.js。比方說，userService.js的更改可以直接合入主分支而wishlistService.js不能。因為wishlistService.js甚至不存在在主分支裡面。它是f1提交中引入的。
專家提示：即使是在一個文件中更改，git也可以搞定。但這篇博客中我們先簡化情況。
我們已經建立了一個公眾演示倉庫，我們將使用這個來練習。為了便於跟蹤，每一個提交信息的前綴是在上面的圖表中使用的假的SHA。以下是git在分開提交f3時的分支圖。

現在，我們要做的第一件事就是使用git的checkout功能checkout出我們的功能分支。用git rebase -i master開始做rebase。
現在接下來git會用所配置的編輯器打開（默認為Vim）一個臨時文件。

該文件為您提供一些rebase選擇，它帶有一個提示（藍色文字）。對於每一個提交，我們可以選擇的動作有pick、rwork、edit、squash、fixup和exec。每一個動作也可以通過它的縮寫形式p、r、e、s、f和e引用。描述每一個選項超出了本文范疇，所以讓我們專注於我們的具體任務。
我們要為f3提交選擇edit選項，因此我們把內容改變成這樣。

現在我們保存文件（在Vim中是按下後輸入:wq,最後是按下回車）。接下來我們注意到git在編輯選項中選擇的提交處停止了rebase。

這意味這git開始將f1、f2、f3生效彷彿它就是常規的rebase，但是在f3生效之後停止。事實上，我們可以看一眼停止的地方的日誌就可以證明這一點。

要將f3分成兩個提交，我們所要做的是重置git的指針到先前的提交（f2）而保持工作目錄和現在一樣。這就是git reset在混合模式在做的。由於混合模式是git reset的默認模式，我們可以直接用git reset head~1。就這么做並在運行後用git status看下發生了什麼。

git status告訴我們userService.js和wishlistService.js被修改了。如果我們運行 git diff 我們就可以看見在f3裡面確切地做了哪些更改。

如果我們看一眼日誌我們會發現f3已經消失了。

現在我們有了准備提交的先前的f3提交，而原先的f3提交已經消失了。記住雖然我們仍舊在rebase的中間過程。我們的f4、f5、f6提交還沒有缺失，它們會在接下來回來。
讓我們創建兩個新的提交：首先讓我們為可以提交到主分支的userService.js創建一個提交。運行git add userService.js 接著運行 git commit -m "f3a: add updateUser method"。
太棒了！讓我們為wishlistService.js的改變創建另外一個提交。運行git add wishlistService.js，接著運行git commit -m "f3b: add addItems method".
讓我們在看一眼日誌。

這就是我們想要的，除了f4、f5、f6仍舊缺失。這是因為我們仍在rebase交互的中間，我們需要告訴git繼續rebase。用下面的命令繼續：git rebase --continue。
讓我們再次檢查一下日誌。

就是這樣。我們現在已經得到我們想要的歷史了。先前的f3提交現在已經被分割成兩個提交f3a和f3b。剩下的最後一件事是cherry-pick出f3a提交到主分支上。
為了完成最後一步，我們首先切換到主分支。我們用git checkout master。現在我們就可以用cherry-pick命令來拾取f3a commit了。本例中我們可以用它的SHA值bd47ee1來引用它。

現在f3a這個提交就在主分支的最上面了。這就是我們需要的！

這篇文章的長度看起來需要花費很大的功夫，但實際上對於一個git高級用戶而言這只是一會會。

⑨ git rebase 之後可以回退嗎

git rebase 不會取回代碼 要用git fetch先取回， git rebase 是合並代碼。

（1）首先用git fetch返回伺服器上的代碼

（2）首先用git rebase origin/master 合並

（3）如果發生沖突了會提示， 然後可以使用git diff查看沖突， 在手工改掉沖突， 在用git add 『文件名』 添加修改後文件，最後用git rebase --continue繼續沒完成的合並

（4）最後就可以用git push 更新到伺服器上去。

轉自： http://blog.chinaunix.net/uid-26952464-id-3352144.html

Git Community Book 中文版書上，摘錄如下：

一、基本

git rebase用於把一個分支的修改合並到當前分支。

假設你現在基於遠程分支"origin"，創建一個叫"mywork"的分支。

$ git checkout -b mywork origin

假設遠程分支"origin"已經有了2個提交，如圖

現在我們在這個分支做一些修改，然後生成兩個提交(commit).

$ vi file.txt

$ git commit

$ vi otherfile.txt

$ git commit

...

但是與此同時，有些人也在"origin"分支上做了一些修改並且做了提交了. 這就意味著"origin"和"mywork"這兩個分支各自"前進"了，它們之間"分叉"了。

在這里，你可以用"pull"命令把"origin"分支上的修改拉下來並且和你的修改合並； 結果看起來就像一個新的"合並的提交"(merge commit):

但是，如果你想讓"mywork"分支歷史看起來像沒有經過任何合並一樣，你也許可以用 git rebase:

$ git checkout mywork

$ git rebase origin

這些命令會把你的"mywork"分支
里的每個提交(commit)取消掉，並且把它們臨時
保存為補丁(patch)(這些補丁放到".git/rebase"目錄中),然後把"mywork"分支更新
為最新的"origin"分支，最後把保存的這些補丁應用到"mywork"分支上。

當'mywork'分支更新之後，它會指向這些新創建的提交(commit),而那些老的提交會被丟棄。 如果運行垃圾收集命令(pruning garbage collection), 這些被丟棄的提交就會刪除. （請查看 git gc)

二、解決沖突

在rebase的過程中，也許會出現沖突(conflict).
在這種情況，Git會停止rebase並會讓你去解決 沖突；在解決完沖突後，用"git-add"命令去更新這些內容的索引(index),
然後，你無需執行 git-commit,只要執行:

$ git rebase --continue

這樣git會繼續應用(apply)餘下的補丁。

在任何時候，你可以用--abort參數來終止rebase的行動，並且"mywork" 分支會回到rebase開始前的狀態。

$ git rebase --abort

三、git rebase和git
merge的區別

現在我們可以看一下用合並(merge)和用rebase所產生的歷史的區別：

當我們使用Git log來參看commit時，其commit的順序也有所不同。

假設C3提交於9:00AM,C5提交於10:00AM,C4提交於11:00AM，C6提交於12:00AM,

對於使用git merge來合並所看到的commit的順序（從新到舊）是：C7
,C6,C4,C5,C3,C2,C1

對於使用git rebase來合並所看到的commit的順序（從新到舊）是：C7
,C6『,C5',C4,C3,C2,C1

因為C6'提交只是C6提交的克隆，C5'提交只是C5提交的克隆，

從用戶的角度看使用git rebase來合並後所看到的commit的順序（從新到舊）是：C7
,C6,C5,C4,C3,C2,C1

參考資料：http://www.cnblogs.com/kym/archive/2010/08/12/1797937.html

git
rebase小計(轉)

git rebase，顧名思義，就是重新定義（re）起點（base）的作用，即重新定義分支的版本庫狀態。要搞清楚這個東西，要先看看版本庫狀態切換的兩種情況：

我們知道，在某個分支上，我們可以通過git reset，實現將當前分支切換到本分支以前的任何一個版本狀態，即所謂的「回溯」。即實現了本分支的「後悔葯」。也即版本控制系統的初衷。
還有另一種情況，當我們的項目有多個分支的時
候。我們除了在本地開發的時候可能會「回溯」外，也常常會將和自己並行開發的別人的分支修改添加到自
己本地來。這種情況下很常見。作為項目管理員，肯定會不斷的合並各個子項目的補丁，並將最新版本推送到公共版本庫，而作為開發人員之一，提交自己的補丁之
後，往往需要將自己的工作更新到最新的版本庫，也就是說把別的分支的工作包含進來。

舉個例子來說吧！假設我們的項目初期只有一個master分支，然後分支上作過兩次提交。這個時候系統只有一個master分支，他的分支歷史如下：

master0（初始化後的版本）
||
v
master1（第一次提交後的版本）
||
v
master2（第二次提交後的版本）

這個時候，我們可以通過git reset將master分支（工作目錄、工作緩存或者是版本庫）切換到master1或者master0版本，這就是前面所說的第一種情況。
假設我們這里把master分支通過git reset回溯到了master1狀態。那麼這個時候系統仍然只有一個master分支，分支的歷史如下：

master0（初始化後的版本）
||
v
master1（第一次提交後的版本）

然後，我們在這里以master1為起點，創建了另一個分支test。那麼對於test分支來說，他的第一個版本test0就和master1是同一個版本，此時項目的分支歷史如下：

master0（初始化後的版本）
||
v
master1（第一次提交後的版本）===test0（test分支，初始化自master分支master1狀態）

這個時候，我們分別對master分支、test分支作兩次提交，此時版本庫應該成了這個樣子：

master0（初始化後的版本）
||
v
master1===test0==>test1===>test2
||
v
master2===>master3

這個時候，通過第一種git
reset的方式，可以將master分支的當前狀態（master3）回溯到master分支的master0、master1、master2狀態。

也可已將test分支當前狀態（test2）回溯到test分支的test0、test1狀態，以及test分支的父分支master的master0、
master1狀態。
那麼。如果我要讓test分支從test0到test2之間所有的改變都添加到master分支來，使得master分支包含test分支的所有修改。這個時候就要用到git rebase了。

首先，我們切換到master分支，然後運行下面的命令，即可實現我們的要求：

git rebase test

這個時候，git做了些什麼呢？

先將test分支的代碼checkout出來，作為工作目錄
然後將master分支從test分支創建起的所有改變的補丁，依次打上。如果打補丁的過程沒問題，rebase就搞定了
如果打補丁的時候出現了問題，就會提示你處理沖突。處理好了，可以運行git rebase –continue繼續直到完成
如果你不想處理，你還是有兩個選擇，一個是放棄rebase過程（運行git rebase –abort），另一個是直接用test分支的取代當前分支的（git rebase –skip）。

⑩ Git push，merge，pull，fetch，rebase各自在什麼場景下使用

基本上順序是這樣的：

1. 你修改好了代碼，先要提交

   git commit -am 「commit message"

2. 然後有兩種方法來把你的代碼和遠程倉庫中的代碼合並

   a. git pull這樣就直接把你本地倉庫中的代碼進行更新但問題是可能會有沖突(conflicts)，個人不推薦

   b. 先git fetch origin（把遠程倉庫中origin最新代碼取回），再git merge origin/master（把本地代碼和已取得的遠程倉庫最新代碼合並），如果你的改動和遠程倉庫中最新代碼有沖突，會提示，再去一個一個解決沖突，最後再從1開始

3. 如果沒有沖突，git push origin master，把你的改動推送到遠程倉庫中

至於rebase很容易和merge混淆，因為就結果而言，兩條命令是類似的，具體請看

http://git-scm.com/book/zh/ch3-6.html