Git是Linux之父Linus的第二個偉大的作品，它最早是在Linux上開發(fā)的，被用來管理Linux核心的源代碼。后來慢慢地有人將其移植到了Unix、Windows、Max OS等操作系統(tǒng)中。
Git是一個分布式的版本控制系統(tǒng)，與集中式的版本控制系統(tǒng)不同的是，每個人都工作在通過克隆建立的本地版本庫中。也就是說每個人都擁有一個完整的版本庫，查看提交日志、提交、創(chuàng)建里程碑和分支、合并分支、回退等所有操作都直接在本地完成而不需要網(wǎng)絡連接。
對于Git倉庫來說，每個人都有一個獨立完整的倉庫，所謂的遠程倉庫或是服務器倉庫其實也是一個倉庫，只不過這臺主機24小時運行，它是一個穩(wěn)定的倉庫，供他人克隆、推送，也從服務器倉庫中拉取別人的提交。
Git是目前世界上最先進的分布式版本控制系統(tǒng)，沒有之一，對，沒有之一!
工作區(qū)(working diretory) 用于修改文件
緩存區(qū)(stage) 是用來暫時存放工作區(qū)中修改的內(nèi)容
提交歷史（commit history） 提交代碼的歷史記錄
git add # 將工作區(qū)的修改提交到暫存區(qū)
git commit # 將暫存區(qū)的修改提交到當前分支
git reset # 回退到某一個版本
git stash # 保存某次修改
git pull # 從遠程更新代碼
git push # 將本地代碼更新到遠程分支上
git reflog # 查看歷史命令
git status # 查看當前倉庫的狀態(tài)
git diff # 查看修改
git log # 查看提交歷史
git revert # 回退某個修改
git commit –m “本次提交描述”
該命令會將git add .存入暫存區(qū)修改內(nèi)容提交至本地倉庫中，若文件未添加至暫存區(qū)，則提交時不會提交任何修改。
git commit -a
相當于運行 git add -u把所有當前目錄下的文件加入緩存區(qū)域再運行git commit.
注意！對于新增的文件，并沒有被commit
git commit –am “本次提交描述”
或者git commit –a –m“本次提交描述”
等同于上面的-a和-m
git commit --amend
修改最近一次提交。有時候如果提交注釋書寫有誤或者漏提文件，可以使用此命令。對于漏提交的文件，需要git add到緩存區(qū)之后，git commit --amend才能將修改追加到最近的一次提交上。
$ git stash
所有未提交的修改都保存起來，用于后續(xù)恢復當前工作目錄
$ git stash save “stash_name”
給每個stash加一個message，用于記錄版本
$ git stash pop / git stash apply
恢復最新緩存的工作目錄（第一個），并刪除緩存堆棧中的那一個stash刪除(pop), apply則只恢復不刪除
$ git stash list
查看現(xiàn)有所有stash
在使用git stash pop(apply)命令時可以通過名字指定使用哪個stash，默認使用最近的stash（即stash@{0}）
$ git stash drop
移除最新的stash，后面也可以跟指定stash的名字
git reset根據(jù)–soft –mixed –hard，會對working tree和index和HEAD進行重置
$ git reset HEAD^
回退版本，一個^表示一個版本，可以多個，另外也可以使用 git reset HEAD~n這種形式。
也可以回退到指定版本：
$ git reset commit-id
soft 參數(shù)：git reset --soft HEAD~1 意為將版本庫軟回退1個版本，所謂軟回退表示將本地版本庫的頭指針全部重置到指定版本，且將這次提交之后的所有變更都移動到暫存區(qū)
默認的mixed參數(shù)：git reset HEAD～1 意為將版本庫回退1個版本，將本地版本庫的頭指針全部重置到指定版本，且會重置暫存區(qū)，即這次提交之后的所有變更都移動到工作區(qū)
hard參數(shù)：git reset --hard HEAD～1 意為將版本庫回退1個版本，但是不僅僅是將本地版本庫的頭指針全部重置到指定版本，也會重置暫存區(qū)，并且會將工作區(qū)代碼清空（工作區(qū)是clean狀態(tài)）
注意，soft參數(shù)與默認參數(shù)都不會修改工作區(qū)代碼，只有hard參數(shù)才會修改工作區(qū)代碼。
另外，git reset HEAD filename
回退文件，將文件從暫存區(qū)回退到工作區(qū)（unstage），此時不能帶hard,soft參數(shù)
如果在回退以后又想再次回到之前的版本，git reflog 可以查看所有分支的所有操作記錄（包括commit和reset的操作），包括已經(jīng)被刪除的commit記錄，git log則不能察看已經(jīng)刪除了的commit記錄
615ce06 HEAD@{44}: rebase -i (finish): returning to refs/heads/my_test_branch615ce06 HEAD@{45}: rebase -i (fixup): zancun_new702356c HEAD@{46}: rebase -i (fixup): # This is a combination of 2 commits.c997622 HEAD@{47}: rebase -i (reword): zancun_newfb74ec2 (origin/master, origin/HEAD) HEAD@{48}: rebase -i (start): checkout FETCH_HEADf3ef592 HEAD@{49}: commit: zancun36b82c75 HEAD@{50}: commit: zancun2e900fa0 HEAD@{51}: commit: zancun比如說，回退到commit: zancun3，只需要：
git reset --hard f3ef592 (或者HEAD@{49}) 即可
這個命令對于找回丟失的代碼非常有用。
刪除文件后需要 git add -A, 光 git add. 不行，區(qū)別如下：
git add -A 保存所有的修改
git add . 保存新的添加和修改，但是不包括刪除
git add -u 保存修改和刪除，但是不包括新建文件。
所以默認使用git add -A就行
git checkout既可以操作分支，也可以操作文件
$ git checkout -b newBranchName
Switched to a new branch ‘newBranchName’
這相當于執(zhí)行下面這兩條命令：
git branch newBranchName
git checkout newBranchName(工作區(qū)一定要是clean的)
$ git checkout -b newBranchName remote_branch_name
拉取遠程分支remote_branch_name創(chuàng)建一個本地分支newBranchName，并切到本地分支newBranchName，采用此種方法建立的本地分支會和遠程分支建立映射關系。
git checkout – fileName
這條命令把fileName從當前HEAD中檢出，也就是回退當前工作區(qū)的這個文件的修改
–可以省略不寫
如果需要回退工作區(qū)的全部文件修改，可以使用：
git checkout --hard HEAD
而不需要對每個文件進行checkout，這樣太累
git revert,反轉(zhuǎn)提交, 撤銷一個提交的同時會創(chuàng)建一個新的提交，也就是用一個新提交來消除一個歷史提交所做的任何修改.
git revert commit-id revert指定的一個commit
git revert HEAD~3 revert指定倒數(shù)第四個commit
revert過程有可能遇到?jīng)_突，要么git revert --abort終止此次revert操作，代碼還原至revert命令前。要么手動消除沖突(同普通的沖突解決)，然后add commit
下面這個表格總結(jié)了這些命令最常用的使用場景。記得經(jīng)常對照這個表格，因為你使用Git時一定會經(jīng)常用到。
命令 | 作用域 | 常用情景
---- | —
git reset | 提交層面 | 在私有分支上舍棄一些沒有提交的更改
git reset| 文件層面 | 將文件從緩存區(qū)中移除
git checkout| 提交層面| 切換分支或查看舊版本
git checkout| 文件層面| 舍棄工作目錄中的更改
git revert| 提交層面| 在公共分支上回滾更改
git revert| 文件層面| （然而并沒有）
刪除分支： $ git branch -d branchName
或者， git branch -D branchName 刪除分支（不管它有沒有merge）
前提是先要切換到其他分支
$ git branch -d branch1
error: The branch ‘branch1’ is not fully merged.
If you are sure you want to delete it, run ‘git branch -D branch1’.
git push命令用于將本地分支的更新，推送到遠程主機。
$ git push <遠程主機名> <本地分支名>:<遠程分支名>$ git push origin master上面命令表示，將本地的master分支推送到origin主機的master分支。如果master不存在，則會被新建。
如果省略本地分支名，則表示刪除指定的遠程分支，因為這等同于推送一個空的本地分支到遠程分支。
$ git push origin :master# 等同于$ git push origin --delete master上面命令表示刪除origin主機的master分支。如果當前分支與遠程分支之間存在追蹤關系，則本地分支和遠程分支都可以省略。
$ git push origin上面命令表示，將當前分支推送到origin主機的對應分支。如果當前分支只有一個追蹤分支，那么主機名都可以省略。
$ git push如果當前分支與多個主機存在追蹤關系，則可以使用-u選項指定一個默認主機，這樣后面就可以不加任何參數(shù)使用git push
$ git push -u origin master上面命令將本地的master分支推送到origin主機，同時指定origin為默認主機，后面就可以不加任何參數(shù)使用git push了。
將當前分支推送到遠程的同名的簡單方法，如下:
$ git push origin HEAD將當前分支推送到源存儲庫中的遠程引用匹配主機。 這種形式方便推送當前分支，而不考慮其本地名稱。如下:
$ git push origin HEAD:master單獨使用git push時，沒有指定push的remote分支名，假如當前本地分支名稱與其對應的remote分支名稱不一樣，則會有一下提示：
fatal: The upstream branch of your current branch does not matchthe name of your current branch. To push to the upstream branchon the remote, use git push origin HEAD:my_new_test_branchTo push to the branch of the same name on the remote, use git push origin testTo choose either option permanently, see push.default in 'git help config'.當執(zhí)行git push origin test時，會在遠程重新創(chuàng)建一個新的分支，名稱就是test，然后把修改同步到test分支。
git pull命令用于從另一個存儲庫或本地分支獲取并集成(整合)。git pull命令的作用是：取回遠程主機某個分支的更新，再與本地的指定分支合并，
$ git pull <遠程主機名> <遠程分支名>:<本地分支名>比如，要取回origin主機的master分支，與本地的test分支合并，需要寫成下面這樣
$ git pull origin master:test如果遠程分支(master)要與當前分支合并，則冒號后面的部分可以省略。上面命令可以簡寫：
$ git pull origin master將遠程存儲庫中的更改合并到當前分支中。在默認模式下，git pull是git fetch后跟git merge FETCH_HEAD的縮寫。
更準確地說，git pull使用給定的參數(shù)運行git fetch，并調(diào)用git merge將檢索到的分支頭合并到當前分支中。 使用–rebase，它運行git rebase而不是git merge。也就是說
git pull = git fetch + git mergegit pull --rebase = git fetch + git rebasegit中都fetch命令是將遠程分支的最新內(nèi)容拉到了本地，但是fetch后是看不到變化的，此時本地多了一個FETCH_HEAD的指針，checkout到該指針后可以查看遠程分支的最新內(nèi)容。然后checkout到master分支，執(zhí)行metch,選中FETCH_HEAD指針,合并后如果出現(xiàn)沖突則解決沖突，最后commit。
pull的作用就相當于fetch和merge，自動合并
git fetch origin master
git merge FETCH_HEAD
git fetch origin isoda-android_1.3.0_feature :branch1
使用遠程isoda-android_1.3.0_feature分支在本地創(chuàng)建branch1分支（但不會切換到該分支）
將 origin 分支合并到 mywork 分支最簡單的辦法就是用下面這些命令
git checkout mywork
git merge origin
或者，你也可以把它們壓縮在一行里:
git merge origin mywork
假設遠程分支上有3次提交A,B,C:
在遠程分支origin的基礎上創(chuàng)建一個名為"mywork"的本地分支并提交了修改E，同時有其他人在"origin"上做了一些修改并提交了修改D。
用git merge命令把"origin"分支與本地提交合并（merge）成版本M，mywork 分支中新的合并提交（merge-commit）將兩個分支的歷史連在了一起，但這樣會形成圖中的菱形，讓人很困惑。
Merge 好在它是一個安全的操作，比較安全，現(xiàn)有的分支不會被更改，避免了 rebase 潛在的缺點（后面會說）。另一方面，這同樣意味著每次合并上游更改時 feature 分支都會引入一個外來的合并提交。如果 master非?；钴S的話，這或多或少會污染你的分支歷史。雖然高級的 git log 選項可以減輕這個問題，但對于開發(fā)者來說，還是會增加理解項目歷史的難度。
作為 merge 的替代選擇，你可以像下面這樣將 mywork 分支并入 origin 分支：
git checkout mywork
git rebase origin
它會把整個 mywork 分支移動到 origin 分支的后面，有效地把所有 master 分支上新的提交并入過來。但是，rebase為原分支上每一個提交創(chuàng)建一個新的提交，重寫了項目歷史，并且不會帶來合并提交。rebase的好處是避免了菱形的產(chǎn)生，保持提交曲線為直線，讓大家易于理解。
rebase最大的好處是你的項目歷史會非常整潔。首先，它不像 git merge 那樣引入不必要的合并提交。其次，如上圖所示，rebase 導致最后的項目歷史呈現(xiàn)出完美的線性——你可以從項目終點到起點瀏覽而不需要任何的 fork。這讓你更容易使用 git log、git reset 和 gitk 來查看項目歷史。
不過，這種簡單的提交歷史會帶來兩個后果：安全性和可跟蹤性。如果你違反了 rebase 黃金法則，重寫項目歷史可能會給你的協(xié)作工作流帶來災難性的影響。此外，rebase 不會有合并提交中附帶的信息——你看不到 mywork 分支中并入了上游的哪些更改。
在rebase的過程中，有時也會有conflict，這時Git會停止rebase并讓用戶去解決沖突，解決完沖突后，用git add命令去更新這些內(nèi)容，然后不用執(zhí)行git commit,直接執(zhí)行git rebase --continue,這樣git會繼續(xù)apply余下的補丁。
在任何時候，都可以用git rebase --abort參數(shù)來終止rebase的行動，并且mywork分支會回到rebase開始前的狀態(tài)。
官方的兩張merge和rebase對比圖：
merge示例圖：
rebase示例圖：
交互式的 rebase 允許你更改并入新分支的提交。這比自動的 rebase 更加強大，因為它提供了對分支上提交歷史完整的控制。一般來說，這被用于將 feature 分支并入 master 分支之前，清理混亂的歷史。
把 -i 傳入 git rebase 選項來開始一個交互式的rebase過程：
git checkout feature
git rebase -i master
它會打開一個文本編輯器，顯示所有將被移動的提交：
pick e900fa0 zancunpick 6b82c75 zancun2pick f3ef592 zancun3# Rebase fb74ec2..f3ef592 onto fb74ec2 (3 commands)## Commands:# p, pick = use commit# r, reword = use commit, but edit the commit message# e, edit = use commit, but stop for amending# s, squash = use commit, but meld into previous commit# f, fixup = like "squash", but discard this commit's log message# x, exec = run command (the rest of the line) using shell# d, drop = remove commit## These lines can be re-ordered; they are executed from top to bottom.## If you remove a line here THAT COMMIT WILL BE LOST.## However, if you remove everything, the rebase will be aborted.## Note that empty commits are commented out這個列表定義了 rebase 將被執(zhí)行后分支會是什么樣的。更改 pick 命令或者重新排序，這個分支的歷史就能如你所愿了。比如說，如果第二個和第三個提交只是修復了第一個提交中的小問題，你可以用 fixup 命令把它們合到第一個提交中，并修改第一個的日志：
r e900fa0 zancunf 6b82c75 zancun2f f3ef592 zancun3這樣三個提交合并成了一個提交，并可以重新修改提交日志，非常實用。
忽略不重要的提交會讓你的 feature 分支的歷史更清晰易讀。這是 git merge 做不到的。
當你理解rebase是什么的時候，最重要的就是什么時候不能用rebase。git rebase 的黃金法則便是，絕不要在公共的分支上使用它。
比如說，如果你把 master分支rebase到你的feature 分支上會發(fā)生什么：
這次 rebase 將 master 分支上的所有提交都移到了 feature 分支后面。問題是它只發(fā)生在你的代碼倉庫中，其他所有的開發(fā)者還在原來的 master 上工作。因為 rebase 引起了新的提交，Git 會認為你的 master 分支和其他人的 master 已經(jīng)分叉了。
同步兩個 master 分支的唯一辦法是把它們 merge 到一起，導致一個額外的合并提交和兩堆包含同樣更改的提交。不用說，這會讓人非常困惑。
所以，在你運行 git rebase 之前，一定要問問你自己「有沒有別人正在這個分支上工作？」。如果答案是肯定的，那么把你的爪子放回去，重新找到一個無害的方式（如 git merge）來提交你的更改。不然的話，你可以隨心所欲地重寫歷史。
在你工作流中使用 rebase 最好的用法之一就是清理本地正在開發(fā)的分支。隔一段時間執(zhí)行一次交互式 rebase，你可以保證你 feature 分支中的每一個提交都是專注和有意義的。
調(diào)用 git rebase 的時候，你有兩個基（base）可以選擇：上游分支（比如 master）或者你 feature 分支中早先的一個提交。我們在「交互式 rebase」一節(jié)看到了第一種的例子。后一種在當你只需要修改最新幾次提交時也很有用。比如說，下面的命令對最新的 3 次提交進行了交互式 rebase：
git checkout featuregit rebase -i HEAD~3(或者第四個commit-id)這樣，就可以對本地提交歷史中最新的三個提交進行重新整理了，包括提交合并，提交日志修改等等。
通過指定 HEAD~3 作為新的基提交，你實際上沒有移動分支——你只是將之后的 3 次提交重寫了。注意它不會把上游分支（master）的更改并入到 feature 分支中。
交互式 rebase 是在你工作流中引入 git rebase 的的好辦法，因為它只影響本地分支。其他開發(fā)者只能看到你已經(jīng)完成的結(jié)果，那就是一個非常整潔、易于追蹤的分支歷史。
建立test倉庫 并建立追蹤關系
$ git branck --track test origin/master修改追蹤關系
先切換到test
$ git checkout test修改追蹤倉庫（一定要先切換）
$ git branch --set-upstream-to origin/master建立追蹤關系之后，本地分支名稱和遠程一樣時，使用git push時不用帶上遠程名稱，git pull也不用帶上遠程分支名
使用git pull --rebase經(jīng)常會出現(xiàn)沖突
沖突產(chǎn)生后，文件系統(tǒng)中沖突了的文件里面的內(nèi)容會顯示為類似下面這樣：
<<<<<<< HEAD * test2 * test3======= * this is my modify, my be conflicked * test1000>>>>>>> my_modify其中：<<<<<<<（7個<）HEAD與=之間的內(nèi)容是remote上的修改，沖突標記=與>>>>>>>之間的內(nèi)容是我的修改內(nèi)容。
在這兩者之間選擇任何你需要的內(nèi)容保留下來，并刪除所有的===,<<<,>>>即可解決沖突，解決完成之后，git add -A, git rebase --continue就提交了代碼
當然我們也可以利用圖形工具解決沖突
如果要解決的沖突很多，且比較復雜，圖形界面的沖突解決工具就顯得很重要了。
執(zhí)行git mergetool用預先配置的Meld(Beyond Compare)解決沖突：
上面左右兩個窗口依次是“LOCAL”、“REMOTE”，它們只是提供解決沖突需要的信息，是無法編輯的。中間的窗口是合并后的結(jié)果，可以手動修改，也可以點擊相應顏色的箭頭選擇“LOCAL”或者“REMOTE”。
如果不向解決沖突，回到之前狀態(tài)，可執(zhí)行：
$ git rebase --abort步驟如下：
git add -A
git commit -m “message”
git pull --rebase (或者git fetch + git rebase）
解決沖突
git add 沖突文件
git rebase –continue
git push
其中，3、4、5點，如果沒遇到?jīng)_突就不用進行，直接push上去。
當遇到?jīng)_突時，git會提示patch failed，并要我們解決問題了再執(zhí)行git rebase --continue
聯(lián)系客服
