《Git 教程》-- 廖雪峯 筆記

1. 設置用戶名和郵箱
   git config --global user.name "Your Name"
git config --global user.email "[email protected]"
   注意：git config命令的--global參數，用了這個參數，表示你這臺機器上所有的Git版本庫都會使用這個配置，當然也可以對某個版本庫指定不同的用戶名和Email地址

2. 創建空的版本庫（empty Git repository）
   git init

3. 添加文件到暫存區
   git add <file>

4. 推送到版本庫
   git commit -m <message>

5. 初始化一個Git版本庫，使用git init命令
   添加文件到Git版本庫，分兩步：
   使用命令git add <file>，注意，可反覆多次使用，添加多個文件，實際上就是把文件修改添加到暫存區
   使用命令git commit -m <message>完成，實際上就是把暫存區的所有內容提交到當前分支

6. 查看版本庫當前的狀態
   git status

7. 查看當前文件與版本庫記錄的文件的差異
   git diff <file>
   也可以寫成下面這樣
   git diff <commit id>/HEAD -- <file>
   這樣比較靈活

8. 查看日誌記錄
   git log
   注意：嫌輸出信息太多，看得眼花繚亂的，可以試試加上--pretty=oneline參數

9. 移動版本庫的版本
   git reset --hard HEAD^
   上述語句爲使版本庫回退到上一個版本，上兩個版本即HEAD^^
   也可以寫成下面這樣
   git reset --hard HEAD~1
   上兩個版本即HEAD~2
   也可以指定版本庫移動到某一個版本
   git reset --hard <commit id>
<commit id>不用全部輸入，只需要輸入前7位即可
   注意：在windows的cmd中，^是特殊符號，使用時需要用雙引號包住，如"^"

10. 查看版本庫的命令執行歷史
    git reflog

11. HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard <commit id>
    穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個版本
    要重返未來，用git reflog查看命令歷史，以便確定要回到未來的哪個版本

12. 爲什麼Git比其他版本控制系統設計得優秀，因爲Git跟蹤並管理的是修改，而非文件

13. 每次修改，如果不用git add到暫存區，那就不會加入到git commit中

14. 復原工作區的修改
    git checkout -- <file>
    這裏有兩種情況：
    一種是文件自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態
    一種是文件已經添加到暫存區後，又作了修改，現在撤銷修改就回到添加到暫存區後的狀態
    總之，就是讓這個文件回到最近一次git commit或git add時的狀態
    命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令

15. 把暫存區的修改回退到工作區，即將暫存區變回跟版本庫一樣，復原暫存區的修改
    git reset <commit id>/HEAD <file>

16. 場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- <file>
    場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作
    場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫

17. 刪除版本庫中的文件
    git rm <file>

18. 創建SSH Key（在windows下需要打開Git Bash）
    ssh-keygen -t rsa -C "[email protected]"
    你需要把郵件地址換成你自己的郵件地址，然後一路回車，使用默認值即可，由於這個Key也不是用於軍事目的，所以也無需設置密碼。如果一切順利的話，可以在用戶主目錄裏找到ssh目錄，裏面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的祕鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人
    爲什麼GitHub需要SSH Key呢？因爲GitHub需要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協議，所以，GitHub只要知道了你的公鑰，就可以確認只有你自己才能推送

19. 關聯一個遠程庫
    git remote add <origin name> git@server-name:path/repo-name.git

20. 把本地庫的內容推送到遠程
    git push <origin name> master
    實際上是把當前分支master推送到遠程，如果遠程庫是空的，我們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在以後的推送或者拉取時就可以簡化命令，例如
    git push -u <origin name> master

21. 克隆遠程庫到本地
    git clone <origin address>
    Git支持多種協議，包括https，但通過ssh支持的原生Git協議速度最快

22. 創建並切換分支
    git checkout -b <branch name>
    也可以分成兩步走
    創建分支
    git branch <branch name>
    切換分支
    git checkout <branch name>

23. 查看當前分支
    git branch
    git branch命令會列出所有分支，當前分支前面會標一個*號

24. 切換當前分支
    git checkout <branch name>

25. 合併指定分支到當前分支
    git merge <branch name>

26. 刪除指定分支
    git branch -d <branch name>
    若分支沒有被合併過，則
    git branch -D <branch name>

27. 當Git無法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成
    解決衝突就是把Git合併失敗的文件手動編輯爲我們希望的內容，再提交

28. 查看帶分支合併的日誌記錄圖
    git log --graph --pretty=oneline --abbrev-commit

29. 通常，合併分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息
    git merge --no-ff -m <message> <branch name>
    合併分支時，加上--no-ff參數就可以用普通模式合併，合併後的歷史有分支，能看出來曾經做過合併，而fast forward合併就看不出來曾經做過合併

30. 分支策略
    在實際開發中，我們應該按照幾個基本原則進行分支管理：
    首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活
    那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本
    你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了

31. 儲藏當前工作現場
    git stash

32. 查看儲藏工作現場列表
    git stash list

33. 恢復工作現場
    git stash apply <stash list name>

34. 刪除儲藏的工作現場列表
    git stash drop <stash list name>

35. 恢復並刪除儲藏的工作現場
    git stash pop <stash list name>

36. 查看遠程倉庫的信息
    git remote
    查看遠程倉庫的詳細信息
    git remote -v

37. 推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：
    git push <origin name> <branch name>

38. 抓取分支（創建遠程分支到本地）
    git checkout -b <branch name> <origin name>/<branch name>

39. 指定本地分支與遠程分支的鏈接
    git branch --set-upstream-to=<origin name>/<branch name> <branch name>

40. 多人協作的工作模式通常是這樣：
    首先，可以試圖用git push <origin name> <branch name>推送自己的修改
    如果推送失敗，則因爲遠程分支比你的本地更新，需要先用git pull試圖合併
    如果合併有衝突，則解決衝突，並在本地提交
    沒有衝突或者解決掉衝突後，再用git push <origin name> <branch name>推送就能成功
    如果git pull提示no tracking information，則說明本地分支和遠程分支的鏈接關係沒有創建，用命令git branch --set-upstream-to=<origin name>/<branch name> <branch name>
    這就是多人協作的工作模式，一旦熟悉了，就非常簡單

41. rebase操作可以把本地未push的分叉提交歷史整理成直線
    rebase的目的是使得我們在查看歷史提交的變化時更容易，因爲分叉的提交需要三方對比
    git rebase

42. 打標籤
    git tag <tag name>
    指定打標籤的commit id
    git tag <tag name> <commit id>
    創建帶有說明的標籤，用-a指定標籤名，-m指定說明文字
    git tab -a <tag name> -m <message> <commit id>
    注意：標籤總是和某個commit掛鉤。如果這個commit既出現在master分支，又出現在dev分支，那麼在這兩個分支上都可以看到這個標籤

43. 查看標籤
    git tag
    注意，標籤不是按時間順序列出，而是按字母排序的

44. 查看標籤信息
    git show <tag name>

45. 刪除標籤
    git tag -d <tag name>
    如果標籤已經推送到遠程，先從本地刪除
    git tag -d <tag name>
    再遠程刪除
    git push <origin name> :refs/tags/<tag name>

46. 推送標籤到遠程版本庫
    git push <origin name> <tag name>
    一次性推送全部尚未推送到遠程的本地標籤
    git push <origin name> --tags

47. 刪除已關聯的遠程庫：
    git remote rm <origin name>

48. 忽略特殊文件
    在Git工作區的根目錄下創建一個特殊的.gitignore文件，然後把要忽略的文件名或文件夾填進去，Git就會自動忽略這些文件或文件夾及其子文件
    不需要從頭寫.gitignore文件，GitHub已經爲我們準備了各種配置文件，只需要組合一下就可以使用了
    所有配置文件可以直接在線瀏覽：https://github.com/github/gitignore
    忽略文件的原則是：
    忽略操作系統自動生成的文件，比如縮略圖等
    忽略編譯生成的中間文件、可執行文件等，也就是如果一個文件是通過另一個文件自動生成的，那自動生成的文件就沒必要放進版本庫，比如Java編譯產生的.class文件
    忽略你自己的帶有敏感信息的配置文件，比如存放口令的配置文件

49. 添加已忽略的文件
    git add -f <file>

50. 檢查忽略規則
    git check-ignore -v <file>

51. 技巧，優化log顯示並簡短爲 git lg
    git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

52. 分支開發應用示例
    master分支，即主分支。任何項目都必須有個這個分支。對項目進行tag或發佈版本等操作，都必須在該分支上進行
    develop分支，即開發分支，從master分支上檢出。團隊成員一般不會直接更改該分支，而是分別從該分支檢出自己的feature分支，開發完成後將feature分支上的改動merge回develop分支。同時release分支由此分支檢出
    release分支，即發佈分支，從develop分支上檢出。該分支用作發版前的測試，可進行簡單的bug修復。如果bug修復比較複雜，可merge回develop分支後由其他分支進行bug修復。此分支測試完成後，需要同時merge到master和develop分支上
    feature分支，即功能分支，從develop分支上檢出。團隊成員中每個人都維護一個自己的feature分支，並進行開發工作，開發完成後將此分支merge回develop分支。此分支一般用來開發新功能或進行項目維護等
    fix分支，即補丁分支，由develop分支檢出，用作bug修復，bug修復完成需merge回develop分支，並將其刪除。所以該分支屬於臨時性分支
    hotfix分支，即熱補丁分支。和fix分支的區別在於，該分支由master分支檢出，進行線上版本的bug修復，修復完成後merge回master分支，並merge到develop分支上，merge完成後也可以將其刪除，也屬於臨時性分支