git入門（廖雪峰老師）
根據廖雪峰老師的git教程進行學習總結；
1、之前上班用的都是svn進行管理，那麽svn和git有什麽區別呢？
svn是集中式的版本控制系統，而git是分布式版本控制系統，那麽集中式和分布式版本控制系統有什麽區別呢？
集中式版本控制系統，版本庫是集中存放在中央服務器的，而幹活的時候，用的都是自己的電腦，所以要先從中央服務器取得最新版本，然後開始幹活，幹完活了，再把自己的活推送給中央服務器。（集中式版本控制系統最大的毛病就是必須聯網才能工作，如果在局域網內還好，寬帶夠大，速度夠快，可如果在互聯網上，遇到網速慢的話，可能提交一個10M的文件就需要5分鐘）
分布式版本控制系統根本沒有“中央服務器”，每個人的電腦上都是一個完整的版本庫，這樣，你工作得時候，就不需要聯網了，因為版本庫就在你自己的電腦上，既然每個人電腦上都有一個完整的版本庫，那多個人如何協作呢？比如說你在自己電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，你們倆只需把自己的修改推送個對方，就可以互相看到對方的修改了。（和集中式版本控制系統相比，分布式版本控制系統的安全性要高很多，因為每個人電腦裏都有完整的版本庫，某一個人的電腦壞掉了不要緊，隨便從其他人那裏復制一個就可以了。而集中式版本控制系統的中央服務器要是出了問題，所有人都沒法幹活了）
2、在Windows上安裝Git
在Windows上使用Git，可以從Git官網直接下載：https://git-scm.com/downloads，然後按默認選項安裝即可。
安裝完成後，在開始菜單裏找到“Git”=》“Git Bash”，蹦出一個類似命令行窗口的東西，就說明Git安裝成功！
安裝完成後，還需要最後一步設置，在命令行輸入：
$ git config --global user.name "Your Name" $ git config --global user.email "[email protected]"
註意git config命令的--global參數，用了這個參數，表示你這臺機器上所有的Git倉庫都會使用這個配置，當然也可以對某個倉庫指定不同的用戶名和Email地址。
3、創建版本庫
首先，選擇一個合適的地方，創建一個空目錄：
$ mkdir git
$ cd git
$ pwd
/e/git
pwd命令用於顯示當前目錄。我在e盤，倉庫位於/e/git
註意：windows系統中，為了避免遇到各種莫名其妙的問題，請確保目錄名（包括父目錄）不包含中文
第二步，通過git init命令把這個目錄變成Git可以管理的倉庫
$ git init Initialized empty Git repositoryin E:/git/.git/
這樣Git倉庫就創建好了，而且告訴你是一個空的（empty Git repository），當前目錄下多了一個.git的目錄，這個目錄是Git來跟蹤管理版本庫的，沒事千萬不要手動修改這個目錄裏面的文件，不然改亂了，就把Git倉庫給破壞了。
如果你沒有看到.git目錄，那是因為這個目錄默認是隱藏的，用ls -ah命令就可以看見
4、把文件添加到版本庫
首先，在目錄下編寫一個readme.txt文件，然後用命令git add告訴Git，把文件添加到倉庫
$ git add readme.txt
然後，用命令git commit告訴Git，把文件提交到倉庫：
$ git commit -m "wrote a readme file"
顯示如下：
簡單解釋一下git commit命令，-m後面輸入的是本次提交的說明，可以輸入任意內容，當然最好是有意義的，這樣你就能從歷史記錄裏方便的找到改動記錄。git commit命令行執行成功後會告訴你，1 file changed：一個文件被改動；2 insertions：插入了兩行內容（為什麽Git添加文件需要add，commit一共兩步呢？因為commit可以一次提交很多文件，所以你可以多次add不同的文件）
5、查看倉庫當前狀態和查看修改內容
git status命令可以讓我們時刻掌握倉庫當前的狀態；
如果不記得修改內容，可以使用git diff這個命令查看；
提交修改和提交新文件一樣分兩步，第一步是git add；第二步是git commit -m "explain"；
要隨時掌握工作區的狀態，使用git status命令；
如果git status告訴你有文件被修改過，用git diff可以查看修改內容
6、版本回退
可以使用git log命令查看歷史記錄，如果嫌輸出的信息太多，可以加上--pretty=oneline
前面一大串十六進制表示的是commit id（版本號）。
在git中，用HEAD表示當前版本，也就是最新的提交，上一個版本就是HEAD^，上上一個版本就是HEAD^^，一次類推100個，可以簡寫成HEAD~100，如果只是回退到上一個版本，可以使用git reset命令：
$ git reset --hard HEAD^
查看了一下內容，果然被回退了，那麽，再想來到剛剛提交最新的那個版本怎麽辦？
可以找到那個版本的commit id，就可以指定回到未來的某個版本
$ git reset --hard 39263
版本號沒必要寫全，前幾位就可以了，git會自動去找，
又回到剛剛最新版本了。
Git中，提供了一個命令git reflog用來記錄你的每一次命令：
小結：HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個版本（git log --pretty=oneline）
要重返未來，用git reflog 查看命令歷史，以便確定要回到哪個版本
7、工作區和暫存區
Git的版本庫裏存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動創建的第一個分支master，以及指向master的一個指針叫HEAD。
前面講了我們把文件往Git版本庫裏添加的時候，是分兩步執行的：
第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區；
第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。
因為我們創建Git版本庫時，Git自動為我們創建了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。
修改readme.txt文件，添加LICENSE文件，沒有git add，使用git status查看：
使用git add把兩個都添加後：
現在，暫存區的狀態就變成這樣了：
git add命令實際上就是把要提交的所有修改放到暫存區（Stage），然後，執行git commit就可以一次性把暫存區的所有修改提交到分支
8、管理修改
當你修改文件之後，如果git add進去了，可是沒有git commit，然後又修改了這個文件，然後再git commit進去，那麽其實提交的內容是第一次修改的內容，因為第二次修改沒有git add進去，也就是還停留在工作區，所以你git commit之後再git status還是會提示你有一個文件沒有add，可以使用git diff HEAD -- readme.txt命令查看工作區和版本庫裏面最新版本的區別。
小結：每次修改，如果不用git add到暫存區，就不會加入到commit中。
9、撤銷修改
當你修改了內容還沒有git add的時候，你可以發現git會告訴你，git checkout -- file可以丟棄工作區的修改：
$ git checkout -- readme.txt
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區的修改全部撤銷，這裏有兩種情況：
一種是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；
一種是readme.txt已經添加到暫存區後，又作了修改，現在，撤銷修改就回到添加到暫存區後的狀態。
總之，就是讓這個文件回到最近一次git commit或git add時的狀態。
註意：git checkout -- file命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令，我們在後面的分支管理中會再次遇到git checkout命令
如果你進行了修改，並且git add進去了暫存區：
Git同樣告訴我們，用命令git reset HEAD <file>可以把暫存區的修改撤銷掉（unstage），重新放回工作區：
然後再丟棄工作區的修改：
小結：
場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。
場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。
場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。
10、刪除文件
一般情況下，你通常直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：
$ rm test.txt
這個時候，Git知道你刪除了文件，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些文件被刪除了：
現在你有兩個選擇，一是確實要從版本庫中刪除該文件，那就用命令git rm刪掉，並且git commit：
現在，文件就從版本庫中被刪除了。（提示：先手動刪除文件，然後使用git rm <file>和git add <file>效果是一樣的）
另一種情況是刪錯了，因為版本庫裏還有呢，所以可以很輕松地把誤刪的文件恢復到最新版本：
$ git checkout -- test.txt
git checkout其實是用版本庫裏的版本替換工作區的版本，無論工作區是修改還是刪除，都可以“一鍵還原”。
小結：命令git rm用於刪除一個文件。如果一個文件已經被提交到版本庫，那麽你永遠不用擔心誤刪，但是要小心，你只能恢復文件到最新版本，你會丟失最近一次提交後你修改的內容。
11、遠程倉庫
使用GitHub來做Git倉庫托管服務。
第一步：需要創建一個GitHub賬號，由於本地Git倉庫和GitHub倉庫之間的傳輸是通過SSH加密的，所以需要一點設置：
①：創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，打開Shell（Windows下打開Git Bash），創建SSH Key：
$ssh-keygen -t rsa -C "[email protected]"
你需要把郵件地址換成你自己的郵件地址，然後一路回車，使用默認值即可，由於這個Key也不是用於軍事目的，所以也無需設置密碼。
如果一切順利的話，可以在用戶主目錄裏找到.ssh目錄，裏面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的秘鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。
②：登陸GitHub，打開“Account settings”，“SSH Keys”頁面：
然後，點“Add SSH Key”，填上任意Title，在Key文本框裏粘貼id_rsa.pub文件的內容：
點“Add Key”，你就應該看到已經添加的Key：
小結：可以把自己用到的每臺電腦的key都添加到GitHub上，就可以在每臺電腦上往GitHub推送了。GitHub上免費托管的Git倉庫一般是任何人都可以看到的。（除非交錢，把倉庫改為私有的）
12、添加遠程庫
現在的情景是，你已經在本地創建了一個Git倉庫後，又想在GitHub創建一個Git倉庫，並且讓這兩個倉庫進行遠程同步，這樣，GitHub上的倉庫既可以作為備份，又可以讓其他人通過該倉庫來協作，真是一舉多得。
首先，登陸GitHub，然後，在右上角找到“new repository”按鈕，創建一個新的倉庫：
在Repository name填入learngit，其他保持默認設置，點擊“Create repository”按鈕，就成功地創建了一個新的Git倉庫：
目前，在GitHub上的這個learngit倉庫還是空的，GitHub告訴我們，可以從這個倉庫克隆出新的倉庫，也可以把一個已有的本地倉庫與之關聯，然後，把本地倉庫的內容推送到GitHub倉庫。
現在，我們根據GitHub的提示，在本地的learngit倉庫下運行命令：
$ git remote add origina [email protected]:lsc202426/test.git
$ git push -u origina master
或者
$ git remote add origin https://github.com/lsc202426/learngit.git $ git push -u origin master
SSH警告：當你第一次使用Git的clone或者push命令連接GitHub時，會得到一個警告：這是因為Git使用SSH連接，而SSH連接在第一次驗證GitHub服務器的Key時，需要你確認GitHub的Key的指紋信息是否真的來自GitHub的服務器，輸入yes回車即可。
Git會輸出一個警告，告訴你已經把GitHub的Key添加到本機的一個信任列表裏了：warning
由於遠程庫是空的，我們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在以後的推送或者拉取時就可以簡化命令。
添加後，遠程庫的名字就是origin，這是Git默認的叫法，也可以改成別的，但是origin這個名字一看就知道是遠程庫。
看人家評論裏面是這樣解決的，後面再嘗試一下。
從現在起，只要本地作了提交，就可以通過命令：
$ git push origin master
小結：要關聯一個遠程庫，使用命令git remote add origin [email protected]:path/repo-name.git；
關聯後，使用命令git push -u origin master第一次推送master分支的所有內容；
此後，每次本地提交後，只要有必要，就可以使用命令git push origin master推送最新修改
13、從遠程庫克隆
首先，登陸GitHub，創建一個新的倉庫，名字叫gitskills：
我們勾選Initialize this repository with a README，這樣GitHub會自動為我們創建一個README.md文件。創建完畢後，可以看到README.md文件：
現在，遠程庫已經準備好了，下一步是用命令git clone克隆一個本地庫：
註意把Git庫的地址換成你自己的，然後進入gitskills目錄看看，已經有README.md文件了：
如果有多個人協作開發，那麽每個人各自從遠程克隆一份就可以了。GitHub給出的地址不止一個，還可以用https://github.com/michaelliao/gitskills.git這樣的地址。實際上，Git支持多種協議，默認的git://使用ssh，但也可以使用https等其他協議。使用https除了速度慢以外，還有個最大的麻煩是每次推送都必須輸入口令，但是在某些只開放http端口的公司內部就無法使用ssh協議而只能用https。
小結：要克隆一個倉庫，首先必須知道倉庫的地址，然後使用git clone命令克隆。Git支持多種協議，包括https，但通過ssh支持的原生git協議速度最快。
14、創建與合並分支
首先，我們創建dev分支，然後切換到dev分支：
git checkout命令加上-b參數表示創建並切換，相當於一下兩條命令：
$ git branch dev $git checkout dev Switched to branch ‘dev‘
然後，用git branch命令查看當前分支：
git branch命令會列出所有分支，當前分支前面會標一個*號。
然後，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行，然後提交：
現在，dev分支的工作完成，我們就可以切換回master分支：
切換回master分支後，再查看一個readme.txt文件，剛才添加的內容不見了，因為那個提交是在dev分支上，而master分支此刻的提交點並沒有變。
現在，我們把dev分支的工作成果合並到master分支上：
git merge命令用於合並指定分支到當前分支。合並後，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。
註意到上面的Fast-forward信息，Git告訴我們，這次合並是“快進模式”，也就是直接把master指向dev的當前提交，所以合並速度非常快。
當然，也不是每次合並都能Fast-forward，我們後面會講其他方式的合並。
合並完成後，就可以放心地刪除dev分支了：
刪除後，查看branch，就只剩下master分支了：
因為創建、合並和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合並後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。
小結：Git鼓勵大量使用分支：
查看分支：git branch
創建分支：git branch <name>
切換分支：git chcekout <name>
創建+切換分支：git checkout -b <name>
合並某分支到當前分支：git merge <name>
刪除分支：git branch -d <name>
15、解決沖突
準備新的feature1分支，繼續我們的新分支開發：
修改readme.txt最後一行，改為：Creating a new branch is quick AND simple.
在featurel分支上提交：
切換到master分支：
Git還會自動提示我們當前master分支比遠程的master分支要超前一個提交
在master分支上把readme.txt文件的最後一行改為：Creating a new branch is quick & simple.
現在，master分支和featurel分支個字都分別由新的提交變成了這樣：
這種情況下，Git無法執行“快速合並”，只能視圖把個字的修改合並起來，但這種合並就可能會有沖突，我們試試看：
果然沖突了！Git告訴我們，readme.txt文件存在沖突，必須手動解決沖突後再提交。git status也可以告訴我們沖突的文件：
我們可以直接查看readme.txt的內容：
Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下後保存：Creating a new branch is quick and simple.
用帶參數的git log也可以看到分支的合並情況：
最後，刪除feature1分支：
小結：當Git無法自動合並分支時，就必須首先解決沖突。解決沖突後，再提交，合並完成。
解決沖突就是把Git合並失敗的文件手動編輯為我們希望的內容，再提交。
用git log --graph命令可以看到分支合並圖。
16、分支管理策略
通常，合並分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。
如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
下面我們實戰一下--no-ff方式的git merge：
首先，創建並切換dev分支；修改readme.txt文件並提交一個新的commit；然後切換回master；準備合並dev分支，請註意--no-ff參數，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev Merge made by the ‘recursive‘ strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)
因為本次合並要創建一個新的commit，所以加上-m 參數，把commit描述寫進去合並後，我們用git log看看分支歷史：
$ git log --graph --pretty=oneline --abbrev-commit * e1e9c68 (HEAD -> master) merge with no-ff |\ | * f52c633 (dev) add merge |/ * cf810e4 conflict fixed ...
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；
那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合並到master上，在master分支發布1.0版本；
你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合並就可以了。
所以，團隊合作的分支看起來就像這樣：
小結：合並分支時，加上--no-ff參數就可以用普通模式合並，合並後的歷史有分支，能看出來曾經做過合並，而fast forward合並就看不出來曾經做過合並。
17、Bug分支
軟件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由於分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復後，合並分支，然後將臨時分支刪除。
當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：
$ git status On branch dev Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt
並不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎麽辦？
幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以後恢復現場後繼續工作：
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
現在，用git status查看工作區，就是幹凈的（除非有沒有被Git管理的文件），因此可以放心地創建分支來修復bug。
首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：
$ git checkout master Switched to branch ‘master‘ Your branch is ahead of ‘origin/master‘ by 6 commits. (use "git push" to publish your local commits) $ git checkout -b issue-101 Switched to a new branch ‘issue-101‘
現在修復bug，需要把“Git is free software ...”改為“Git is a free software ...”，然後提交：
$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
修復完成後，切換到master分支，並完成合並，最後刪除issue-101分支：
$ git checkout master Switched to branch ‘master‘ Your branch is ahead of ‘origin/master‘ by 6 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the ‘recursive‘ strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接著回到dev分支幹活了！
$ git checkout dev Switched to branch ‘dev‘ $ git status On branch dev nothing to commit, working tree clean
工作區是幹凈的，剛才的工作現場存到哪去了？用git stash list命令看看：
$ git stash list [email protected]{0}: WIP on dev: f52c633 add merge
工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：
一是用git stash apply恢復，但是恢復後，stash內容並不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復的同時把stash內容也刪了：
$ git stash pop On branch dev Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt Dropped refs/[email protected]{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash內容了：
$ git stash list
你可以多次stash，恢復的時候，先用git stash list查看，然後恢復指定的stash，用命令：
$ git stash apply [email protected]{0}
小結：修復bug時，我們會通過創建新的bug分支進行修復，然後合並，最後刪除；
當手頭工作沒有完成時，先把工作現場git stash一下，然後去修復bug，修復後，再git stash pop，回到工作現場。
18、Feature分支
添加一個新功能時，最好新建一個feature分支，在上面開發，完成後，合並，最後，刪除該feature分支。
如果該feature分支已經add並且commit；但是還沒有合並，如果想要刪除：
$ git branch -d feature-vulcan error: The branch ‘feature-vulcan‘ is not fully merged. If you are sure you want to delete it, run ‘git branch -D feature-vulcan‘.
銷毀失敗。Git友情提醒，feature-vulcan分支還沒有被合並，如果刪除，將丟失掉修改，如果要強行刪除，需要使用大寫的-D參數。。
現在我們強行刪除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).
小結：開發一個新feature，最好新建一個分支；
如果要丟棄一個沒有被合並過的分支，可以通過git branch -D <name>強行刪除。
19、多人協作
多人協作的工作模式通常是這樣：
-
首先，可以試圖用
git push origin <branch-name>推送自己的修改； -
如果推送失敗，則因為遠程分支比你的本地更新，需要先用
git pull試圖合並； -
如果合並有沖突，則解決沖突，並在本地提交；
-
沒有沖突或者解決掉沖突後，再用
git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
這就是多人協作的工作模式。
小結：
-
查看遠程庫信息，使用
git remote -v； -
本地新建的分支如果不推送到遠程，對其他人就是不可見的；
-
從本地推送分支，使用
git push origin branch-name，如果推送失敗，先用git pull抓取遠程的新提交； -
在本地創建和遠程分支對應的分支，使用
git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致； -
建立本地分支和遠程分支的關聯，使用
git branch --set-upstream branch-name origin/branch-name； -
從遠程抓取分支，使用
git pull，如果有沖突，要先處理沖突。
20、rebase（未完待續！）
git入門（廖雪峰老師）