1、創建版本庫
cd E:
mkdir myRepository
pwd
ls -ah
======
git init2、添加文件到倉庫
添加
git add readme.txt
提交
git commit -m "i wrote a readme file"
【爲什麼Git添加文件需要add，commit一共兩步呢？因爲commit可以一次提交很多文件，所以你可以多次add不同的文件
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."】
$ git status
【git status命令可以讓我們時刻掌握倉庫當前的狀態，上面的命令輸出告訴我們，readme.txt被修改過了，但還沒有準備提交的修改。】
$ git diff readme.txt
【git diff顧名思義就是查看difference，顯示我們在第一行添加了一個distributed單詞。】
$ git add readme.txt
$ git commit -m "add distributed"3、回退版本
$ git log
【git log命令顯示從最近到最遠的提交日誌】
$ git log --pretty=oneline
【一行顯示，前邊的是提交的commit id版本號】
$git reset --hard HEAD^
【回退到上個版本號】
$git reset --hard 54897
【回退到某個版本】
【Git的版本回退速度非常快，因爲Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL：
然後順便把工作區的文件更新了。所以你讓HEAD指向哪個版本號，你就把當前版本定位在哪】
$ git reflog
【Git提供了一個命令git reflog用來記錄你的每一次命令】
4、工作區和暫存區
工作區
【工作區就是你在電腦裏能看到的目錄，比如我的myRepository文件夾就是一個工作區】
版本庫
【工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。】
Git的版本庫裏存了很多東西，其中最重要的就是稱爲stage（或者叫index）的暫存區，還有Git爲我們自動創建的第一個分支master，以及指向master的一個指針叫HEAD。
【第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區】
【第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。】
【因爲我們創建Git版本庫時，Git自動爲我們創建了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。】5、撤銷修改
git checkout -- readme.txt
【--後有空格】
【一種是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；】
【一種是readme.txt已經添加到暫存區後，又作了修改，現在，撤銷修改就回到添加到暫存區後的狀態。】
$ git reset HEAD readme.txt
【將暫存區的代碼撤銷掉，重新放回工作區，HEAD爲最新的分支中的版本】
場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。
場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。
場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。6、刪除
rm licence.txt
【本地先刪除】
git rm licence.txt
【從版本庫中刪除】
git commit
【提交刪除】
==============
沒提交之前想回退刪除：
$ git log --pretty=oneline
$ git reset --hard a2bd3a
7、注意
git status
Changes not staged for commit
【表示沒有提交到暫存區,想回退用git checkout --file】
Changes to be committed:
【表示提交到了暫存區,想回退先用git reset HEAD <file> 然後 git checkout --file】8、遠程推送
$ git remote add origin https://gitee.com/night_wish/myRepository.git
【添加到遠程倉庫】
【添加後，遠程庫的名字就是origin，這是Git默認的叫法，也可以改成別的，但是origin這個名字一看就知道是遠程庫。】
$ git push -u origin master
【第一次推送到遠程倉庫 master分支】
$ git push origin master
【以後推送遠程倉庫master分支】
$ git clone [email protected]:night_wish/myRepository.git
【克隆遠程倉庫】9、分支
分支在實際中有什麼用呢？假設你準備開發一個新功能，但是需要兩週才能完成，第一週你寫了50%的代碼，如果立刻提交，由於代碼還沒寫完，不完整的代碼庫會導致別人不能幹活了。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。
現在有了分支，就不用怕了。你創建了一個屬於你自己的分支，別人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上幹活，想提交就提交，直到開發完畢後，再一次性合併到原來的分支上，這樣，既安全，又不影響別人工作。
$ git checkout -b dev
【創建一個dev分支,並切換到dev -b表示創建並切換】
$git branch dev
【創建dev分支】
$git checkout dev
【切換到dev分支】
$git branch
【查看所有分支，當前分支前面會有*】
$ git merge dev
【合併dev分支到當前分支】
$ git branch -d dev
【刪除dev分支】
$ git branch -D feature-vulcan
【強行刪除分支】10、分支策略
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；
那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；
你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了。
所以，團隊合作的分支看起來就像這樣
11、修復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
stash@{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/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash內容了：
$ git stash list
你可以多次stash，恢復的時候，先用git stash list查看，然後恢復指定的stash，用命令：
$ git stash apply stash@{0}