參考：
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001374385852170d9c7adf13c30429b9660d0eb689dd43a000
推送更新：
一、git的初次使用
2. 第一步，用命令git
add告訴Git，把文件添加到倉庫：
$ git add readme.txtgit
commit告訴Git，把文件提交到倉庫：
$ git commit -m "wrote a readme file"git commit命令，-m後面輸入的是本次提交的說明，可以輸入任意內容，當然最好是有意義的，這樣你就能從歷史記錄裏方便地找到改動記錄。爲什麼Git添加文件需要add，commit一共兩步呢？
因爲需要添加一個功能，而該功能的實現，在多個文件中，所以需要add多個文件，但是commit只需要一次，告訴git：“我添加這麼多個文件主要是實現了某個功能”。如：
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."4. 查看提交的版本信息
git
log命令顯示從最近到最遠的提交日誌，我們可以看到3次提交，最近的一次是append GPL，上一次是add
distributed，最早的一次是wrote a readme file。如果嫌輸出信息太多，看得眼花繚亂的，可以試試加上--pretty=oneline參數
$ git log
commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <[email protected]>
Date: Tue Aug 20 15:11:49 2013 +0800
append GPL
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <[email protected]>
Date: Tue Aug 20 14:53:12 2013 +0800
add distributed
commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <[email protected]>
Date: Mon Aug 19 17:51:55 2013 +0800
wrote a readme file3628164...882e1e0的是commit
id（版本號），和SVN不一樣，Git的commit
id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進制表示，5.回退到上一版本
首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交3628164...882e1e0（注意我的提交ID和你的肯定不
一樣），上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100
$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed如果回退到上一版本之後，又想重新返回到原來版本，只要當前的git bash窗口沒有關閉， 可以網上查看，之前版本的id，然後返回既可，如：
$ git reset --hard 3628164
HEAD is now at 3628164 append GPL
3628164：是需要回退到的版本id的前幾位，不需要將整個id全部寫出，只需要寫出前幾位，然後git會自動找出版本。‘
如果說關閉了電腦，也就是之前的git bash窗口關閉了，而你又想恢復到原來的窗口，則可以如下操作：
現在，你回退到了某個版本，關掉了電腦，第二天早上就後悔了，想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？
在Git中，總是有後悔藥可以喫的。當你用$ git reset --hard HEAD^回退到add
distributed版本時，再想恢復到append GPL，就必須找到append
GPL的commit id。Git提供了一個命令git reflog用來記錄你的每一次命令：
$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed
cb926e7 HEAD@{3}: commit (initial): wrote a readme file現在總結一下：
-
HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。 -
穿梭前，用
git log可以查看提交歷史，以便確定要回退到哪個版本。 -
要重返未來，用
git reflog查看命令歷史，以便確定要回到未來的哪個版本。
又到了小結時間。
場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。
場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD file，就回到了場景1，第二步按場景1操作。
場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。
二、使用github
第1步：創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，打開Shell（Windows下打開Git
Bash，windows下主目錄在：C:\Users\Administrator），創建SSH Key：
$ ssh-keygen -t rsa -C "[email protected]"
你需要把郵件地址換成你自己的郵件地址，然後一路回車，使用默認值即可，由於這個Key也不是用於軍事目的，所以也無需設置密碼。
如果一切順利的話，可以在用戶主目錄裏找到.ssh目錄，裏面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH
Key的祕鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。
第2步：登陸GitHub，打開“Account settings”，“SSH Keys”頁面：
然後，點“Add SSH Key”，填上任意Title，在Key文本框裏粘貼id_rsa.pub文件的內容：
點“Add Key”，你就應該看到已經添加的Key：
爲什麼GitHub需要SSH Key呢？因爲GitHub需要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協議，所以，GitHub只要知道了你的公鑰，就可以確認只有你自己才能推送。
當然，GitHub允許你添加多個Key。假定你有若干電腦，你一會兒在公司提交，一會兒在家裏提交，只要把每臺電腦的Key都添加到GitHub，就可以在每臺電腦上往GitHub推送了。
最後友情提示，在GitHub上免費託管的Git倉庫，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放進去。
如果你不想讓別人看到Git庫，有兩個辦法，一個是交點保護費，讓GitHub把公開的倉庫變成私有的，這樣別人就看不見了（不可讀更不可寫）。另一個辦法是自己動手，搭一個Git服務器，因爲是你自己的Git服務器，所以別人也是看不見的。這個方法我們後面會講到的，相當簡單，公司內部開發必備。
確保你擁有一個GitHub賬號後，我們就即將開始遠程倉庫的學習。
第二.從github中clone項目
找一個存放clone項目的本地地址，然後在該文件夾下，右鍵“git bash”，然後在bash裏面輸入：git clone git項目地址
假如git項目地址爲：https://github/user/learngit
那麼bash裏面輸入的 地址爲：git clonehttps://github/user/learngit
第三：
當Git無法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。
用git log --graph命令可以看到分支合併圖。
三、分支管理
1. 分支策略
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；
那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；
你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了。
所以，團隊合作的分支看起來就像這樣：
小結
Git分支十分強大，在團隊開發中應該充分應用。
合併分支時，加上--no-ff參數就可以用普通模式合併，合併後的歷史有分支，能看出來曾經做過合併，而fast
forward合併就看不出來曾經做過合併
修復bug時，我們會通過創建新的bug分支進行修復，然後合併，最後刪除；
當手頭工作沒有完成時，先把工作現場git stash一下，然後去修復bug，修復後，再git
stash pop，回到工作現場。
3. feature分支
軟件開發中，總有無窮無盡的新的功能要不斷添加進來。
添加一個新功能時，你肯定不希望因爲一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成後，合併，最後，刪除該feature分支。
開發一個新feature，最好新建一個分支；
如果要丟棄一個沒有被合併過的分支，可以通過git branch -D <name>強行刪除。
並不是一定要把本地分支往遠程推送，那麼，哪些分支需要推送，哪些不需要呢？
-
master分支是主分支，因此要時刻與遠程同步； -
dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步； -
bug分支只用於在本地修復bug，就沒必要推到遠程了，除非老闆要看看你每週到底修復了幾個bug；
-
feature分支是否推到遠程，取決於你是否和你的小夥伴合作在上面開發。
總之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，視你的心情而定！
因此，多人協作的工作模式通常是這樣：
-
首先，可以試圖用
git push origin branch-name推送自己的修改； -
如果推送失敗，則因爲遠程分支比你的本地更新，需要先用
git pull試圖合併； -
如果合併有衝突，則解決衝突，並在本地提交；
-
沒有衝突或者解決掉衝突後，再用
git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關係沒有創建，用命令git
branch --set-upstream 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，如果有衝突，要先處理衝突。
四、標籤管理
Git的標籤雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？但是分支可以移動，標籤不能移動），所以，創建和刪除標籤都是瞬間完成的。
2.創建標籤
-
命令
git tag <name>用於新建一個標籤，默認爲HEAD，也可以指定一個commit id； -
git tag -a <tagname> -m "blablabla..."可以指定標籤信息； -
git tag -s <tagname> -m "blablabla..."可以用PGP簽名標籤； -
命令
git tag可以查看所有標籤。
-
命令
git push origin <tagname>可以推送一個本地標籤； -
命令
git push origin --tags可以推送全部未推送過的本地標籤； -
命令
git tag -d <tagname>可以刪除一個本地標籤； -
命令
git push origin :refs/tags/<tagname>可以刪除一個遠程標籤。