git常用命令總結--廖雪峰老師Git教程命令總結
學習了廖雪峰老師的Git教程之後的命令總結，重點關於git和遠程倉庫的東西。
如果沒有學過，這是傳送門
下面這個圖很重要
一、git初始化本地倉庫和配置
echo "想輸入到文件的內容，一般為# 庫名字" >> README.md git init 初始化一個倉庫 如果沒有配置需要配置 git config --list git config --global user.email "[email protected]" git config --global user.name "zhoudu" git config --list 還可以配置git顯示顏色二、提交文件
git add file2.txt file3.txt 想添加所有的文件 > git add . git commit -m "提交記錄文字“git diff --<file> 這種是比較 工作區和暫存區
git diff --cached <file> 比較暫存區與最新本地版本庫
git diff HEAD --<file> 比較工作區和最新版本
小結
現在總結一下今天學的兩點內容：
初始化一個Git倉庫，使用git init命令。
添加文件到Git倉庫，分兩步：
- 使用命令
git add <file>，註意，可反復多次使用，添加多個文件； - 使用命令
git commit -m <message>，完成。 - 如果
git status告訴你有文件被修改過，用git diff可以查看修改內容。
三、回退
git log 命令顯示從最近到最遠的提交日誌 git log --pretty=oneline 簡化提交日誌的信息 git reset --head^ 可以把暫存區的修改撤銷掉（unstage） git reset --hard commit_id 可直接回溯到提交的ID的版本 git reflog Git提供了一個命令git reflog用來記錄你的每一次命令
小結
HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個版本。
要重返未來，用git reflog查看命令歷史，以便確定要回到未來的哪個版本。
四、切換暫存區、工作區
1.暫存區的概念
版本庫（Repository）
工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。
Git的版本庫裏存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動創建的第一個分支master，以及指向master的一個指針叫HEAD。
分支和HEAD的概念我們以後再講。
前面講了我們把文件往Git版本庫裏添加的時候，是分兩步執行的：
第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區；
第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。
因為我們創建Git版本庫時，Git自動為我們創建了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。
你可以簡單理解為，需要提交的文件修改通通放到暫存區，然後，一次性提交暫存區的所有修改。
2.撤銷修改
git checkout -- <file> 命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令 命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區的修改全部撤銷，這裏有兩種情況：
一種是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；
一種是readme.txt已經添加到暫存區後，又作了修改，現在，撤銷修改就回到添加到暫存區後的狀態。
總之，就是讓這個文件回到最近一次git commit或git add時的狀態。
git reset HEAD <file> 可以把暫存區的修改撤銷掉（unstage），重新放回工作區；
git reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。
小結
場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。
場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。
場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。
五、刪除文件
git rm <file> 與 rm<file> 的區別 在被 git 管理的目錄中刪除文件時，可以選擇如下兩種方式來記錄刪除動作：
一、rm <file> + git commit -am "刪除"
二、git rm + git commit -m "刪除"
另外，git add . 僅能記錄添加、改動的動作，刪除的動作需靠 git rm 來完成。
誤刪文件處理
git checkout --<file> 用版本庫裏的版本替換工作區的版本，無論工作區是修改還是刪除，都可以“一鍵還原”。 如果一個文件已經被提交到版本庫，那麽你永遠不用擔心誤刪，但是要小心，你只能恢復文件到最新版本，你會丟失最近一次提交後你修改的內容。
六、github遠程倉庫
由於你的本地Git倉庫和GitHub倉庫之間的傳輸是通過SSH加密的，所以，需要一點設置：
第1步：創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，打開Shell（Windows下打開Git Bash），創建SSH Key：
$ ssh-keygen -t rsa -C "[email protected]" 該命令用於 創建id_rsa文件和id_rsa.pub文件，id_rsa是私鑰，id_rsa.pub是公鑰用於添加到github的ssh key裏面。文件位於用戶目錄下的.ssh文件裏面
第一種情況：遠程只有倉庫沒有內容時，將本地已經寫好的代碼關聯到遠程：
git remote add origin [email protected]:JasonDu1993/learngit.git 關聯遠程庫 git push -u origin master -u只在第一次推送分支時使用 git push origin master 把本地倉庫 master主分支 推送到 origin的遠程倉庫小結
要關聯一個遠程庫，使用命令git remote add origin git@server-name:path/repo-name.git；
關聯後，使用命令git push -u origin master第一次推送master分支的所有內容；
此後，每次本地提交後，只要有必要，就可以使用命令git push origin master推送最新修改；
第二種情況：遠程倉庫有內容，直接克隆到本地
git clone [email protected]:JasonDu1993/gitskills.git 克隆遠程倉庫到本地小結
要克隆一個倉庫，首先必須知道倉庫的地址，然後使用git clone命令克隆。
Git支持多種協議，包括https，但通過ssh支持的原生git協議速度最快。
使用https除了速度慢以外，還有個最大的麻煩是每次推送都必須輸入口令，但是在某些只開放http端口的公司內部就無法使用ssh協議而只能用https。
六、分支管理
1.創建與合並分支
在版本回退裏，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git裏，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當前分支。
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：
小結
Git鼓勵大量使用分支：
查看分支：git branch
創建分支：git branch <name>
切換分支：git checkout <name>
創建+切換分支：git checkout -b <name>
合並某分支到當前分支：git merge <name>
刪除分支：git branch -d <name>
2.解決沖突
<<<<<<< HEAD
lalala
=======
hehehe
>>>>>>> xxxxxxxxxxxxxxxxxxxxxxx
分析：head 到 =======裏面的lalala是自己的commit的內容 ，而 =========到 >>>>>>裏面的hehehe是下拉的內容
根據需要刪除代碼就行了 完事把<<<<<<< ======= >>>>>>都刪掉沖突就解決了
git log --graph 看到分支合並圖
git log --graph --pretty=oneline --abbrev-commit小結
當Git無法自動合並分支時，就必須首先解決沖突。解決沖突後，再提交，合並完成。
解決沖突就是把Git合並失敗的文件手動編輯為我們希望的內容，再提交。
用git log --graph命令可以看到分支合並圖。
3.分支管理策略
分支策略
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；
那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合並到master上，在master分支發布1.0版本；
你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合並就可以了。
所以，團隊合作的分支看起來就像這樣：
小結
Git分支十分強大，在團隊開發中應該充分應用。
合並分支時，加上--no-ff參數就可以用普通模式合並，合並後的歷史有分支，能看出來曾經做過合並，而fast forward合並就看不出來曾經做過合並。
4.Bug分支（使用貯藏 git stash）
情景：
軟件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由於分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復後，合並分支，然後將臨時分支刪除。
當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：
註意：當你的當前工作區、暫存區若存在未commit的改動文件，創建新的分支是與主分支一起使用工作區、暫緩區；所以創建新的分支需要把主分支的文件貯藏起來，這樣新分支才是幹凈的工作區、暫存區；
當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：
並不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎麽辦？
解決步驟
- git stash 把當前工作現場“儲藏”起來，等以後恢復現場後繼續工作，git status 此時工作區是幹凈的；
- 從master創建新的分支修復bug,修復完bug合並到master，然後刪除分支；
- 切換到之前的dev分支繼續幹活，使用git stash list 查看之前貯藏的內容；
- 恢復貯藏:
一是用
git stash apply恢復，但是恢復後，stash內容並不刪除，你需要用git stash drop來刪除；另一種方式是用
git stash pop，恢復的同時把stash內容也刪了;
小結
1.修復bug時，我們會通過創建新的bug分支進行修復，然後合並，最後刪除；
2.當手頭工作沒有完成時，先把工作現場git stash一下，然後去修復bug，修復後，再git stash pop，回到工作現場。
3.stash 命令小結
- 使用 git stash save -a "messeag" 對貯藏填寫描述信息；
- $ git stash list
stash@{0}: On master: 測試貯藏2
stash@{1}: On master: 測試1
- git stash apply stash@{0} 恢復指定的貯藏
5.多人協作（推送、拉取遠程倉庫）
1. 推送分支
推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：$ git push origin dev
但是，並不是一定要把本地分支往遠程推送，那麽，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要時刻與遠程同步；
dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
bug分支只用於在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；
feature分支是否推到遠程，取決於你是否和你的小夥伴合作在上面開發。
2. 多人協作的工作模式通常是這樣：
-
首先，可以試圖用
git push origin <branch-name>推送自己的修改； -
如果推送失敗，則因為遠程分支比你的本地更新，需要先用
git pull試圖合並； -
如果合並有沖突，則解決沖突，並在本地提交；
-
沒有沖突或者解決掉沖突後，再用
git push 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，如果有沖突，要先處理沖突。
6. rebase
rebase使用詳解
小結
-
rebase操作可以把本地未push的分叉提交歷史整理成直線；
-
rebase的目的是使得我們在查看歷史提交的變化時更容易，因為分叉的提交需要三方對比。
七、版本標簽
使用情景
發布一個版本時，我們通常先在版本庫中打一個標簽（tag），這樣，就唯一確定了打標簽時刻的版本。將來無論什麽時候，取某個標簽的版本，就是把那個打標簽的時刻的歷史版本取出來。所以，標簽也是版本庫的一個快照。
Git的標簽雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？但是分支可以移動，標簽不能移動），所以，創建和刪除標簽都是瞬間完成的。
Git有commit，為什麽還要引入tag？
“請把上周一的那個版本打包發布，commit號是6a5819e...”
“一串亂七八糟的數字不好找！”
如果換一個辦法：
“請把上周一的那個版本打包發布，版本號是v1.2”
“好的，按照tag v1.2查找commit就行！”
所以，tag就是一個讓人容易記住的有意義的名字，它跟某個commit綁在一起。
標簽用於發布版本時使用，相當於給某次commit取個名字
1.添加標簽
使用步驟
1. 首先，切換到需要打標簽的分支上
2. 敲命令git tag <name>就可以打一個新標簽：
$ git tag v1.0
3. 可以用命令git tag查看所有標簽
$ git tag v1.0
有時候，如果忘了打標簽，比如，現在已經是周五了，但應該在周一打的標簽沒有打，怎麽辦？
方法是找到歷史提交的commit id，然後打上就可以了：
$ git tag v0.9 f52c633
再用命令git tag查看標簽：
$ git tag v0.9 v1.0
可以用git show <tagname>查看標簽信息：
$ git show v0.9 commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9) Author: Michael Liao <[email protected]> Date: Fri May 18 21:56:54 2018 +0800 add merge diff --git a/readme.txt b/readme.txt ...
小結
-
命令
git tag <tagname>用於新建一個標簽，默認為HEAD，也可以指定一個commit id； -
命令
git tag -a <tagname> -m "commit id"可以指定標簽信息； -
命令
git tag可以查看所有標簽。
2.操作標簽
如果標簽打錯了，也可以刪除：
$ git tag -d v0.1 Deleted tag ‘v0.1‘ (was f15b0dd)
因為創建的標簽都只存儲在本地，不會自動推送到遠程。所以，打錯的標簽可以在本地安全刪除。
如果要推送某個標簽到遠程，使用命令git push origin <tagname>：
$ git push origin v1.0 Total 0 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git * [new tag] v1.0 -> v1.0
或者，一次性推送全部尚未推送到遠程的本地標簽：
$ git push origin --tags Total 0 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git * [new tag] v0.9 -> v0.9
如果標簽已經推送到遠程，要刪除遠程標簽就麻煩一點，先從本地刪除：
$ git tag -d v0.9 Deleted tag ‘v0.9‘ (was f52c633)
然後，從遠程刪除。刪除命令也是push，但是格式如下：
$ git push origin :refs/tags/v0.9 To github.com:michaelliao/learngit.git - [deleted] v0.9
要看看是否真的從遠程庫刪除了標簽，可以登陸GitHub查看。
小結
-
命令
git push origin <tagname>可以推送一個本地標簽； -
命令
git push origin --tags可以推送全部未推送過的本地標簽； -
命令
git tag -d <tagname>可以刪除一個本地標簽； -
命令
git push origin :refs/tags/<tagname>可以刪除一個遠程標簽。
八，忽略特特殊文件
有些時候，你必須把某些文件放到Git工作目錄中，但又不能提交它們，比如保存了數據庫密碼的配置文件啦，等等，每次git status都會顯示Untracked files ...，有強迫癥的童鞋心裏肯定不爽。
好在Git考慮到了大家的感受，這個問題解決起來也很簡單，在Git工作區的根目錄下創建一個特殊的.gitignore文件，然後把要忽略的文件名填進去，Git就會自動忽略這些文件。
不需要從頭寫.gitignore文件，GitHub已經為我們準備了各種配置文件，只需要組合一下就可以使用了。所有配置文件可以直接在線瀏覽：https://github.com/github/gitignore
忽略文件的原則是：
- 忽略操作系統自動生成的文件，比如縮略圖等；
- 忽略編譯生成的中間文件、可執行文件等，也就是如果一個文件是通過另一個文件自動生成的，那自動生成的文件就沒必要放進版本庫，比如Java編譯產生的
.class文件； - 忽略你自己的帶有敏感信息的配置文件，比如存放口令的配置文件。
- 最後一步就是把.gitignore也提交到Git，就完成了！當然檢驗.gitignore的標準是git status命令是不是說working directory clean。
註意：有些時候，你想添加一個文件到Git，但發現添加不了，原因是這個文件被.gitignore忽略了：
$ git add App.class The following paths are ignored by one of your .gitignore files: App.class Use -f if you really want to add them.
如果你確實想添加該文件，可以用-f強制添加到Git：
$ git add -f App.class
或者你發現，可能是.gitignore寫得有問題，需要找出來到底哪個規則寫錯了，可以用git check-ignore命令檢查：
$ git check-ignore -v App.class .gitignore:3:*.class App.class
Git會告訴我們，.gitignore的第3行規則忽略了該文件，於是我們就可以知道應該修訂哪個規則。
小結
-
忽略某些文件時，需要編寫
.gitignore； -
.gitignore文件本身要放到版本庫裏，並且可以對.gitignore做版本管理！
git常用命令總結--廖雪峰老師Git教程命令總結